Apache Kafka er en datastrømmingsplattform som er ansvarlig for streaming av data fra en rekke kilder til mange mål. Kildene kalles også produsenter. Dataene som produseres er nødvendig av en helt annen gruppe som heter forbrukere for forskjellige formål. Kafka er laget som sitter mellom produsenter og forbrukere og samler dataene til en brukbar rørledning. Kafka er også en distribuert plattform, så Kafka -laget er sammensatt av forskjellige servere som kjører en kafka, disse serverne eller nodene er derav kjent som kafka Meglere.

Denne oversikten er litt i abstrakt, så la oss bakke den i et virkelig verdensscenario, forestill deg at du trenger å overvåke flere webservere. Hver som kjører sin egen webside, og nye logger genereres stadig i hvert av dem hvert sekund av dagen. På toppen av det er det en rekke e -postservere som du også trenger å overvåke.

Det kan hende du må lagre disse dataene for journalføring og faktureringsformål, som er en batchjobb som ikke krever øyeblikkelig oppmerksomhet. Det kan være lurt å kjøre analyser på dataene for å ta beslutninger i sanntid som krever nøyaktig og øyeblikkelig innspill av data. Plutselig befinner du deg i behovet for å effektivisere dataene på en fornuftig måte for alle de forskjellige behovene. Kafka fungerer som det laget av abstraksjon som flere kilder kan publisere forskjellige datastrømmer og en gitt forbruker kan abonnere på bekkene den finner relevant. Kafka vil sørge for at dataene er velordnet. Det er internene til Kafka som vi trenger å forstå før vi kommer til temaet partisjonering og nøkler.

Kafka emner, megler og partisjoner

Kafka Emner er som tabeller av en database. Hvert emne består av data fra en bestemt kilde av en bestemt type. For eksempel kan klyngens helse være et tema som består av CPU og informasjon om hukommelsesutnyttelse. Tilsvarende kan innkommende trafikk til over klyngen være et annet tema.

Kafka er designet for å være horisontalt skalerbar. Det vil si at en enkelt forekomst av Kafka består av flere Kafka meglere Kjører over flere noder, kan hver håndtere strømmer av data parallelt med den andre. Selv om noen få av nodene mislykkes, kan datarørledningen fortsette å fungere. Et bestemt emne kan deretter deles inn i et antall partisjoner. Denne partisjoneringen er en av de avgjørende faktorene bak den horisontale skalerbarheten til Kafka.

Flere produsenter, Datakilder for et gitt emne kan skrive til det emnet samtidig fordi hver enkelt skriver til en annen partisjon, til et gitt tidspunkt. Nå tildeles vanligvis data til en partisjon tilfeldig, med mindre vi gir den en nøkkel.

Partisjonering og bestilling

Bare for å gjenskape, skriver produsentene data til et gitt emne. Det emnet er faktisk delt inn i flere partisjoner. Og hver partisjon lever uavhengig av de andre, selv for et gitt tema. Dette kan føre til mye forvirring når bestillingen til data betyr noe. Kanskje du trenger dataene dine i en kronologisk rekkefølge, men å ha flere partisjoner for din Datastream garanterer ikke perfekt bestilling.

Du kan bare bruke en enkelt partisjon per emne, men som beseirer hele formålet med Kafkas distribuerte arkitektur. Så vi trenger en annen løsning.

Nøkler for partisjoner

Data fra en produsent blir sendt til partisjoner tilfeldig, som vi nevnte før. Meldinger er de faktiske biter av data. Det produsenter kan gjøre foruten å bare sende meldinger er å legge til en nøkkel som følger med den.

Alle meldingene som følger med den spesifikke tasten vil gå til samme partisjon. Så for eksempel kan en brukers aktivitet spores kronologisk hvis den brukerens data er merket med en nøkkel, og det havner alltid i en partisjon. La oss kalle denne partisjonen P0 og brukeren U0.

Partisjon P0 vil alltid hente U0 -relaterte meldinger fordi den nøkkelen binder dem sammen. Men det betyr ikke at P0 bare er bundet opp med det. Det kan også ta opp meldinger fra U1 og U2 hvis den har kapasitet til det. Tilsvarende kan andre partisjoner konsumere data fra andre brukere.

Poenget at en gitt brukers data ikke er spredt over forskjellige partisjoner som sikrer kronologisk bestilling for den brukeren. Imidlertid det overordnede emnet for brukerdata, kan fremdeles utnytte den distribuerte arkitekturen til Apache Kafka.

Konklusjon

Mens distribuerte systemer som Kafka løser noen eldre problemer som mangel på skalerbarhet eller å ha enkelt et feilpunkt. De har et sett med problemer som er unike for deres egen design. Å forutse disse problemene er en essensiell jobb for enhver systemarkitekt. Ikke bare det, noen ganger må du virkelig gjøre en kostnads-nytte-analyse for å avgjøre om de nye problemene er en verdig avveining for å bli kvitt de eldre. Bestilling og synkronisering er bare toppen av isfjellet.

Forhåpentligvis kan artikler som disse og den offisielle dokumentasjonen hjelpe deg underveis.