Introduktion til Kafka Consumer Group
Kafka-forbrugergruppe er dybest set et antal Kafka-forbrugere, der kan læse data parallelt fra et Kafka-emne. En Kafka Consumer Group har følgende egenskaber:
- Alle forbrugere i en gruppe har den samme gruppe.
- Hver partition i emnet læses kun af en forbruger.
- Det maksimale antal forbrugere er lig med antallet af partitioner i emnet. Hvis der er flere forbrugere end partitioner, forbliver nogle af forbrugerne inaktive.
- En forbruger kan læse fra mere end en partition.
Betydningen af Kafka Consumer Group
For en detailorganisation vil der være et stort antal producenter, der genererer data til en enorm hastighed. For at læse en stor mængde data har vi brug for flere forbrugere, der kører parallelt. Det er relativt lettere på Producer-siden, hvor hver Producent genererer data uafhængigt af de andre. Men på forbrugersiden, hvis vi har mere end en forbruger, der læser fra det samme emne, er der en stor chance for, at hver meddelelse læses mere end én gang. Kafka løser dette problem ved hjælp af Consumer Group. Under alle omstændigheder har kun én forbruger lov til at læse data fra en partition.
Skillevægge af Kafka Consumer Group
Lad os antage, at vi har et Kafka-emne, og at der er 4 partitioner i det. Så kan vi have følgende scenarier:
1. Antal forbrugere = Antal skillevægge
I dette tilfælde læser hver forbruger data fra hver partition, og det er det ideelle tilfælde.
2. Antal forbrugere> Antal skillevægge
I dette tilfælde forbliver en forbruger inaktiv og fører til dårlig udnyttelse af ressourcen.
3. Antal forbrugere <Antal skillevægge
I dette tilfælde vil en af forbrugerne læse data fra mere end en partition.
4. Antal forbrugergrupper> 1
I dette tilfælde abonneres emnet af mere end en forbrugergruppe, der henvender sig til to forskellige applikationer. De to applikationer kan køre uafhængigt af hinanden.
Fordele ved Kafka Consumer Group
Forbrugergruppen tilføjer følgende fordele:
- Skalerbarhed: Et antal forbrugere, der læser data parallelt, øger definitivt dataforbruget og gør systemet i stand til at læse en stor datamængde.
- Fejltolerance: Antag, at vi kun havde en forbruger (til at læse ikke så stor datamængde), hvad ville der ske, hvis forbrugeren mislykkes af en eller anden grund? Hele rørledningen går i stykker.
- Load Balancing: Kafka deler partitionerne retvisende til hver forbruger, hvilket gør processen med dataforbrug glat og effektiv.
- Genbalancering: Hvis en ny forbruger tilføjes, eller en eksisterende stopper, justeres Kafka for belastningen på de tilgængelige forbrugere.
Hvordan Kafka bygger bro mellem de to modeller?
Lad os diskutere de to meddelelsesmodeller først.
1. Meddelelseskø
I denne model sendes en strøm af meddelelser fra en producent til kun en forbruger. Hver meddelelse læses således kun én gang, og når en forbruger trækker en meddelelse, slettes meddelelsen fra køen. Et typisk eksempel kan være at udstede en lønseddel, hvor hver lønseddel kun skal udstedes en gang. Denne model sikrer heller ikke, at meddelelser bliver leveret i rækkefølge. Skalerbarheden ved behandling af meddelelser er begrænset til et enkelt domæne.
2. Udgiv-abonner beskeder
I denne model kan de meddelelser, der er offentliggjort af en producent, abonneres af mere end en forbruger. Producenten og forbrugeren frakobles i vid udstrækning. Denne model sikrer, at hver forbruger modtager meddelelser i et emne i den nøjagtige rækkefølge, der er genereret af producenten. Et typisk eksempel kan være et parabol-tv, der udgiver forskellige kanaler som musik, film, sport osv., Og forbrugerne kan abonnere på mere end en kanal. Da der er flere abonnenter på et emne, er det en udfordring at skalere behandlingen af strømme.
Kafka er så populær, fordi selv om den er baseret på udgivelses-abonnementsmodellen, har den fordelene ved et meddelelseskøsystem. Som diskuteret tidligere, hvis vi har en forbrugergruppe, sikrer Kafka, at hver meddelelse i et emne kun læses en gang af en forbruger (som ligner et meddelelseskøsystem). De ekstra fordele er, at meddelelserne bevares af mæglerne (i nogen tid og derved gør dem fejlagtolerante), og hvis vi har mere end en forbrugergruppe, kan de læse meddelelser fra det samme emne, men behandle dem anderledes.
Brug sagimplikation
Lad os antage, at vi har en enkel Cloud Platform, hvor vi tillader følgende operationer til brugerne:
- Gem filer på Cloud.
- Se deres filer i skyen.
- Download deres filer fra skyen.
I begyndelsen havde vi en meget lille brugerbase. Vi ønskede at udlede forskellige statistikker (på timesbasis) som aktive brugere, antal uploadanmodninger, antal downloadanmodninger og så videre. For at imødekomme kravene oprettede vi en Kafka Cluster, der producerer logfilerne (genereret af vores applikation) til et emne, og der er et program, der forbruger emnet (ved hjælp af en forbruger) og derefter behandler det til at generere den krævede statistik og til sidst vise dem på en webside.
Da folk begyndte at kunne lide vores tjenester, begyndte flere at bruge dem, hvilket genererede en masse logfiler i timen. Vi fandt, at applikationen, der forbruger emnet, blev ekstremt langsom, da vi kun brugte én forbruger. For at løse problemet tilføjede vi nogle forbrugere til gruppen og fandt betydelig forbedring i ydelsen.
Vi stødte på et andet krav, hvor vi måtte skrive logfilerne ind i en HDFS-klynge, og denne proces skulle køre uafhængigt af den forrige ansøgning (Dette skyldes, at med en yderligere stigning i data planlagde vi at nedlægge den første ansøgning og udlede alle statistikker i HDFS-miljøet). For at imødekomme dette krav udviklede vi en anden applikation, der abonnerede på emnet ved hjælp af en anden forbrugergruppe og skrev dataene ind i HDFS-klyngen.
Anbefalede artikler
Dette er en guide til Kafka Consumer Group. Her drøfter vi vigtigheden af Kafka-forbrugergruppen, og hvordan Kafka bygger bro mellem to modeller sammen med dens anvendelse af sagens implikationer. Du kan også se på de følgende artikler for at lære mere-
- Kafka-applikationer
- Sådan installeres Kafka?
- Kafka Interview Spørgsmål
- HDFS Arkitektur
- Forskellige typer Kafka-værktøjer