I dagens databehandlingsarkitekturer brukes Apache Kafka ofte på ingress-scenen. Vanligvis brukes dette trinnet til å berike og filtrere innkommende meldingsdata; det er imidlertid ikke mulig å lage interaktive spørringer før et senere stadium i databehandlingsrørledningen. Dette skyldes at selv om hver melding i Et Kafka-emne er vedvarende som standard, er det ikke tilgjengelig noen mekanisme som gir mulighet for raske oppslag av en bestemt melding i et emne.likevel, å være i stand til å spørre nye data på dette tidlige stadiet i rørledningen, ville unngå forsinkelser i tradisjonelle prosesseringsrørledninger som vanligvis inkluderer langvarige batchforprosesseringstrinn og ville gi sluttbrukere nesten umiddelbar tilgang til innkommende data.

For å bygge databehandlingsapplikasjoner med Kafka, brukes Kafka Streams library, som vedlikeholdes som en del av Kafka-prosjektet, ofte til å definere datatransformasjoner og analyser. Et viktig trekk Ved Kafka Streams er statlige butikker, og tilbyr en abstraksjon av en rask lokal Nøkkelverdibutikk som kan leses og skrives til når du behandler meldinger med Kafka Streams. Disse viktige butikkene kan kontinuerlig fylles med nye meldinger fra Et Kafka-emne ved å definere en passende strømprosessor, slik at det nå er mulig å raskt hente meldinger fra det underliggende emnet.På Toppen av Denne Kafka Streams-funksjonaliteten oppretter vi en enhetlig REST API som gir et enkelt spørringsendepunkt for et Gitt Kafka-emne.i sammendraget kan kombinere Kafka Streams-prosessorer med Statlige Butikker og EN HTTP-server effektivt gjøre Et Kafka-emne til en rask skrivebeskyttet nøkkelverdibutikk.Kafka Streams er bygget som et bibliotek som kan bygges inn I En selvstendig Java eller Scala program. Det tillater utviklere å definere strømprosessorer som utfører datatransformasjoner eller aggregeringer på Kafka-meldinger, slik at hver inngangsmelding behandles nøyaktig en gang. Ved Hjelp Av Kafka Bekker DSL, som er inspirert Av Java Stream API, stream prosessorer, og statlige butikker kan være fleksibelt lenket.videre, når du starter flere forekomster av En Kafka Streams-basert applikasjon, danner prosessene automatisk en lastbalansering, svært tilgjengelig prosesseringsklynge uten å være avhengig av andre eksterne systemer enn Kafka.

for å illustrere arkitekturen til Et Kafka Streams-program som bruker statlige butikker, tenk deg følgende scenario: som jernbaneoperatør, hver gang en kunde bestiller en tur på vår nettside, blir en ny melding bestående av kunde-id og et tidsstempel satt inn i Et Kafka-emne. Nærmere bestemt setter En Eller flere Kafka-produsenter inn disse meldingene i et emne med ni partisjoner. Fordi kunde-id er valgt som nøkkel for hver melding, vil data som tilhører en gitt kunde alltid settes inn i samme partisjon av emnet. Implisitt Bruker Kafka-produsenter DefaultPartitioner for å tilordne meldinger til partisjoner.Nå antar vi at Vi har Et Kafka Streams-program som leser meldinger fra dette emnet og fortsetter dem i en statsbutikk. Fordi nøkkelen til hver melding bare består av kunde-id, vil den tilsvarende verdien i statsbutikken alltid være tidsstempel for kundens siste bestilling. For å oppnå maksimal grad av parallell behandling, kan vi starte opptil ni forekomster av Kafka Streams-applikasjonen. I dette tilfellet vil hver applikasjonseksempel bli tildelt nøyaktig en av emnepartisjonene. For hver inngangspartisjon oppretter Kafka Streams en egen statslager, som igjen bare inneholder dataene til kundene som tilhører den partisjonen.

den resulterende applikasjonsarkitekturen er illustrert i diagrammet nedenfor.

kafka stream-prosessorer som er ansvarlige for partisjonene 4 til 9, er utelatt i denne illustrasjonen. De stiplede pilene indikerer at nye meldinger i en partisjon også forplantes til flere strømprosessorer og deres statslager, noe som gir en rask fail-over hvis den primært tildelte prosessoren skulle mislykkes.

det er mulig å enten bruke lagre i minnet eller vedvarende tilstand i applikasjonen. Operasjoner på in-memory state-butikker er enda raskere sammenlignet med den vedvarende varianten, som internt bruker En RocksDB-butikk. På den annen side kan vedvarende statlige butikker gjenopprettes raskere hvis En Kafka Streams-applikasjon har mislyktes og må starte på nytt. Videre er datavolumet per butikk ikke begrenset av mengden hovedminne ved bruk av vedvarende tilstandslagre.

i vårt scenario er det ikke nødvendig å ha et endringsemne som registrerer skriveoperasjoner til statsforretningene: Alle data som er nødvendige for å gjenopprette en statsforretning, kan hentes fra det opprinnelige inndataemnet.

Legge TIL ET REST-endepunkt for å streame prosessorer

med arkitekturen som er presentert så langt, har vi ni statlige butikker som kan brukes til å hente den siste bestillingsdatoen for kundene som tilhører den respektive inngangsemnepartisjonen.

Nå, For å gjøre denne informasjonen tilgjengelig fra utenfor Kafka Streams-prosessorene, må vi avsløre et serviceendepunkt på hver av stream processor – applikasjonsinstansene og svare på innkommende forespørsler fra den interne tilstandsbutikken som administreres av Kafka Streams.

som et tilleggskrav kan vi ikke forvente at den forespurte søknaden skal vite hvilken Kafka Streams-forekomst som for øyeblikket er ansvarlig for å behandle dataene til en gitt kunde. Derfor er hvert tjenesteendepunkt ansvarlig for å omdirigere spørringen til riktig programforekomst hvis kundedataene ikke er lokalt tilgjengelige.

vi valgte å implementere serviceendepunktet som EN REST API, som har fordelen av å være tilgjengelig fra enhver klient som støtter HTTP, og gjør det mulig å legge til i en gjennomsiktig lastbalanser veldig enkelt.

KafkaStreams – objektet, som er tilgjengelig i Alle Kafka Streams-applikasjoner, gir skrivebeskyttet tilgang til alle lokale statlige butikker og kan også bestemme applikasjonsinstansen som er ansvarlig for en gitt kunde-id. Når du bruker dette objektet til Å bygge VÅR REST-tjeneste, ser arkitekturen ut som følger:

Oppsummering, vår foreslåtte arkitektur gjør bruk Av Kafka emner å pålitelig lagre meldingsdata i ro og opprettholder en andre representasjon av data i statlige butikker for å støtte raske spørringer.

Sikre skalerbarhet av applikasjonen

for å få en skalerbar applikasjon, må vi sørge for at prosesseringsbelastningen er like balansert over alle forekomster av Kafka Streams-applikasjonen. Belastningen på en individuell strømprosessor avhenger av mengden data og spørringer den må håndtere.mer spesifikt er det viktig å velge et partisjoneringsskjema for Kafka-emnet slik at belastningen av innkommende meldinger og spørringer er godt balansert på tvers av alle partisjoner og dermed også alle strømprosessorer.

hvis in-memory state-butikker skal brukes, må antall partisjoner i emnet være stort nok til at hver stream-prosessor kan beholde datavolumet til en partisjon i hovedminnet. Merk at i tilfelle fail-overs, kan en strømprosessor til og med trenge å holde to partisjoner i hovedminnet.

for å ta hensyn til strømprosessorfeil kan antall standby-replikaer konfigureres ved hjelp av innstillingennum.standby.replicas i Kafka-Strømmer, som sikrer at flere strømprosessorer også abonnerer på meldinger fra en gitt prosessorpartisjon. I tilfelle en feil, kan disse prosessorene raskt ta over svare på spørsmål, i stedet for å begynne å rekonstruere staten butikken først etter en feil har allerede oppstått.

til slutt må ønsket antall strømprosessorer passe til den tilgjengelige maskinvaren. For hver strømprosessorprogramforekomst bør minst EN CPU-kjerne reserveres. På multicore-systemer er det mulig å øke antall strømtråder per applikasjonseksempel, noe som reduserer overhead pådratt ved å starte et eget Java-program per CPU-kjerne.