Phenquestions
Når vi ønsker å integrere meldingsmeglere i applikasjonen vår som lar oss enkelt skalere og koble systemet vårt på en asynkron måte, er det mange meldingsmeglere som kan lage listen du er laget for å velge en fra, som:
- RabbitMQ
- Apache Kafka
- ActiveMQ
- AWS SQS
- Redis
Hver av disse meldingsmeglerne har sin egen liste over fordeler og ulemper, men de mest utfordrende alternativene er de to første, RabbitMQ og Apache Kafka. I denne leksjonen vil vi liste opp punkter som kan bidra til å begrense beslutningen om å gå med hverandre. Til slutt er det verdt å påpeke at ingen av disse er bedre enn en annen i alle brukstilfeller, og det avhenger helt av hva du vil oppnå, så det er ingen rett svar!
Vi starter med en enkel introduksjon av disse verktøyene.
Apache Kafka
Som vi sa i denne leksjonen, er Apache Kafka en distribuert, feiltolerant, horisontalt skalerbar, forpliktelseslogg. Dette betyr at Kafka kan utføre en delings- og regelperiode veldig bra, den kan replikere dataene dine for å sikre tilgjengelighet og er svært skalerbar i den forstand at du kan inkludere nye servere i løpetid for å øke kapasiteten til å administrere flere meldinger.
Kafka produsent og forbruker
RabbitMQ
RabbitMQ er en mer generell og enklere å bruke meldingsmegler som i seg selv holder oversikt over hvilke meldinger som er konsumert av klienten og vedvarer den andre. Selv om RabbitMQ-serveren av en eller annen grunn går ned, kan du være sikker på at meldingene som er tilstede i køene er lagret på filsystemet, slik at når RabbitMQ kommer opp igjen, kan disse meldingene behandles av forbrukerne på en jevn måte.
RabbitMQ Working
Supermakt: Apache Kafka
Kafkas viktigste supermakt er at den kan brukes som køsystem, men det er ikke det som er begrenset til. Kafka er noe mer som en sirkulær buffer som kan skalere like mye som en disk på maskinen på klyngen, og dermed tillater oss å kunne lese meldinger på nytt. Dette kan gjøres av klienten uten å måtte være avhengig av Kafka-klyngen, da det er helt klientens ansvar å merke seg meldingens metadata den leser for øyeblikket, og det kan gå tilbake til Kafka senere i et spesifisert intervall for å lese den samme meldingen igjen.
Vær oppmerksom på at tiden denne meldingen kan leses på nytt er begrenset og kan konfigureres i Kafka-konfigurasjon. Så når tiden er over, er det ingen måte en klient kan lese en eldre melding noen gang igjen.
Supermakt: RabbitMQ
RabbitMQs viktigste supermakt er at den rett og slett er skalerbar, er et høytytende køsystem som har veldig veldefinerte konsistensregler og evne til å lage mange typer meldingsutvekslingsmodeller. For eksempel er det tre typer utveksling du kan opprette i RabbitMQ:
- Direkte utveksling: Én til en utveksling av emne
- Emneutveksling: A emne er definert som forskjellige produsenter kan publisere en melding og forskjellige forbrukere kan binde seg til å lytte til det emnet, slik at hver av dem mottar meldingen som sendes til dette emnet.
- Fanout-utveksling: Dette er strengere enn emneutveksling, da når en melding publiseres på en fanout-utveksling, vil alle forbrukere som er koblet til køer som binder seg til fanout-utvekslingen, motta meldingen.
Har allerede lagt merke til forskjellen mellom RabbitMQ og Kafka? Forskjellen er at hvis en forbruker ikke er koblet til en fanout-utveksling i RabbitMQ da en melding ble publisert, vil den gå tapt fordi andre forbrukere har konsumert meldingen, men dette skjer ikke i Apache Kafka da enhver forbruker kan lese hvilken som helst melding som de opprettholder sin egen markør.
RabbitMQ er meglersentrert
En god megler er noen som garanterer arbeidet det tar på seg selv, og det er det RabbitMQ er god for. Den er vippet mot leveringsgarantier mellom produsenter og forbrukere, med kortvarige preferanser fremfor holdbare meldinger.
RabbitMQ bruker megleren selv til å administrere tilstanden til en melding og sørge for at hver melding blir levert til hver berettiget forbruker.
RabbitMQ antar at forbrukerne stort sett er online.
Kafka er produsentsentrert
Apache Kafka er produsentsentrert ettersom den er helt basert på partisjonering og en strøm av hendelsespakker som inneholder data og forvandler dem til holdbare meldingsmeglere med markører, som støtter batchforbrukere som kan være frakoblet, eller online forbrukere som ønsker meldinger med lav ventetid.
Kafka sørger for at meldingen forblir trygg inntil en spesifisert tidsperiode ved å replikere meldingen på nodene i klyngen og opprettholde en konsistent tilstand.
Så, Kafka gjør ikke det antar at noen av forbrukerne for det meste er online og ikke bryr seg.
Melding bestilling
Med RabbitMQ, bestillingen for publisering administreres konsekvent og forbrukere vil motta meldingen i selve den publiserte bestillingen. På den andre siden gjør ikke Kafka det, ettersom det antas at publiserte meldinger er tunge i naturen, slik at forbrukerne er langsomme og kan sende meldinger i hvilken som helst rekkefølge, slik at den ikke administrerer bestillingen også. Selv om vi kan sette opp en lignende topologi for å administrere bestillingen i Kafka ved hjelp av jevn hasjutveksling eller skjæringsprogramtillegg., eller enda flere typer topologier.
Den komplette oppgaven som Apache Kafka administrerer, er å oppføre seg som en "støtdemper" mellom den kontinuerlige strømmen av hendelser og forbrukerne som noen er online på, og andre kan være offline - bare batchkonsumerer hver time eller til og med daglig.
Konklusjon
I denne leksjonen studerte vi de store forskjellene (og likheter også) mellom Apache Kafka og RabbitMQ. I noen miljøer har begge vist ekstraordinær ytelse, slik at RabbitMQ bruker millioner av meldinger per sekund, og Kafka har brukt flere millioner meldinger per sekund. Den viktigste arkitektoniske forskjellen er at RabbitMQ administrerer meldingene sine nesten i minnet og bruker så en stor klynge (30+ noder), mens Kafka faktisk bruker kraftene til sekvensielle disk I / O-operasjoner og krever mindre maskinvare.
Igjen, bruken av hver av dem avhenger fortsatt helt av brukssaken i en applikasjon. Gratulerer med meldinger !
