Introduksjon til Kafka Consumer Group
Kafka forbrukergruppe er i utgangspunktet en rekke Kafka-forbrukere som kan lese data parallelt fra et Kafka-tema. En Kafka Consumer Group har følgende egenskaper:
- Alle forbrukerne i en gruppe har den samme gruppen.
- Hver partisjon i emnet blir lest av bare en forbruker.
- Det maksimale antallet forbrukere er lik antall partisjoner i emnet. Hvis det er flere forbrukere enn partisjoner, vil noen av forbrukerne forbli inaktiv.
- En forbruker kan lese fra mer enn en partisjon.
Betydningen av Kafka Consumer Group
For en detaljhandelsorganisasjon vil det være et stort antall produsenter som genererer data til en enorm hastighet. Nå, for å lese et stort datamengde, trenger vi flere forbrukere som kjører parallelt. Det er relativt lettere på produsentens side der hver produsent genererer data uavhengig av de andre. Men på forbrukersiden, hvis vi har mer enn en forbruker som leser fra det samme emnet, er det stor sjanse for at hver melding blir lest mer enn en gang. Kafka løser dette problemet ved å bruke Consumer Group. I alle tilfeller er det bare en forbruker som har lov til å lese data fra en partisjon.
Partisjoner av Kafka Consumer Group
La oss anta at vi har et Kafka-emne, og det er 4 partisjoner i det. Da kan vi ha følgende scenarier:
1. Antall forbrukere = Antall partisjoner
I dette tilfellet vil hver forbruker lese data fra hver partisjon, og dette er det ideelle tilfellet.
2. Antall forbrukere> Antall partisjoner
I dette tilfellet vil en forbruker forbli inaktiv og føre til dårlig utnyttelse av ressursen.
3. Antall forbrukere <Antall partisjoner
I dette tilfellet vil en av forbrukerne lese data fra mer enn en partisjon.
4. Antall forbrukergruppe> 1
I dette tilfellet abonneres emnet av mer enn en forbrukergruppe som henvender seg til to forskjellige applikasjoner. De to applikasjonene kan kjøres uavhengig av hverandre.
Fordeler med Kafka Consumer Group
Forbrukergruppen legger til følgende fordeler:
- Skalerbarhet: En rekke forbrukere som leser data parallelt, øker definitivt dataforbruket og gjør systemet i stand til å lese et høyt datamengde.
- Feiltoleranse: Anta at vi bare hadde en forbruker (for å lese ikke så høyt datamengde), hva ville skje hvis forbrukeren mislykkes av en eller annen grunn? Hele rørledningen vil gå i stykker.
- Lastbalansering: Kafka deler partisjonene ganske enkelt til hver forbruker, og gjør dermed dataforbruksprosessen jevn og effektiv.
- Ombalansering: Hvis en ny forbruker legges til eller en eksisterende stopper, balanserer Kafka belastningen på de tilgjengelige forbrukerne.
Hvordan Kafka bygger bro mellom de to modellene?
La oss diskutere de to meldingsmodellene først.
1. Meldingskøer
I denne modellen sendes en strøm av meldinger fra en produsent til bare en forbruker. Dermed blir hver melding bare leset en gang og når en forbruker drar en melding, slettes meldingen fra køen. Et typisk eksempel kan være å utstede en lønnsslipp der hver lønnsslipp bare må utstedes en gang. Denne modellen sikrer heller ikke at meldinger blir levert i orden. Skalbarheten til å behandle meldinger er begrenset til et enkelt domene.
2. Publiser-abonner meldinger
I denne modellen kan meldingene publisert av en produsent abonneres av mer enn en forbruker. Produsenten og forbrukeren er i stor grad koblet fra. Denne modellen sikrer at hver forbruker vil motta meldinger i et emne i nøyaktig rekkefølge generert av produsenten. Et typisk eksempel kan være et parabol-TV som publiserer forskjellige kanaler som musikk, film, sport osv., Og forbrukerne kan abonnere på mer enn en kanal. Siden det er flere abonnenter på et emne, er det en utfordring å skalere prosessering av strømmer.
Kafka er så populær, selv om den er basert på modellen for publisere-abonnere, har den fordelene med et meldingskøsystem. Som diskutert tidligere, hvis vi har en forbrukergruppe, sørger Kafka for at hver melding i et emne leses bare en gang av en forbruker (som ligner på et Message Queue-system). De ekstra fordelene er at meldingene beholdes av meglerne (i noen tid og dermed gjør det feiltolerant), og hvis vi har mer enn en forbrukergruppe, kan de lese meldinger fra samme emne, men behandle dem annerledes.
Bruk sakimplikasjon
La oss anta at vi har en enkel Cloud Platform der vi tillater følgende operasjoner til brukere:
- Lagre filer på Cloud.
- Se filene deres i skyen.
- Last ned filene fra Cloud.
I begynnelsen hadde vi en veldig liten brukerbase. Vi ønsket å utlede forskjellige statistikker (på timebasis) som aktive brukere, antall opplastningsforespørsler, antall nedlastningsforespørsler og så videre. For å oppfylle kravene, setter vi opp en Kafka Cluster som produserer loggene (generert av applikasjonen vår) til et emne, og det er et program som forbruker emnet (ved å bruke en forbruker) og deretter behandler det for å generere den nødvendige statistikken og til slutt vise de på en webside.
Etter hvert som folk begynte å like tjenestene våre, begynte flere å bruke dem og genererte mye logger i timen. Vi fant ut at applikasjonen som konsumerer emnet, ble ekstremt treg, da vi bare brukte en forbruker. For å løse problemet la vi til noen forbrukere til gruppen og fant betydelig forbedring i ytelsen.
Vi kom over et annet krav, der vi måtte skrive loggene i en HDFS-klynge, og denne prosessen skulle kjøres uavhengig av den forrige applikasjonen (Dette fordi vi med ytterligere dataøkning planla å ta ut den første applikasjonen og hente all statistikk i HDFS-miljøet). For å oppfylle dette kravet utviklet vi en annen applikasjon som abonnerte på emnet ved hjelp av en annen forbrukergruppe og skrev dataene inn i HDFS-klyngen.
Anbefalte artikler
Dette er en guide til Kafka Consumer Group. Her diskuterer vi viktigheten av Kafka forbrukergruppe og hvordan Kafka bygger bro mellom to modeller sammen med bruken av saken. Du kan også se på følgende artikler for å lære mer-
- Kafka-applikasjoner
- Hvordan installere Kafka?
- Kafka intervjuspørsmål
- HDFS Arkitektur
- Ulike typer Kafka-verktøy