Kafka er et høytytende, distribuert meldingssystem utviklet av LinkedIn som er mye brukt i scenarier som logginnsamling, strømming av data, online og offline meldingsdistribusjon, og mer. Selv om det ikke er designet som en tradisjonell MQ, kan Kafaka i de fleste tilfeller erstatte tradisjonelle meldingssystemer som ActiveMQ.
Kafka organiserer flyten av meldinger etter temaer, og serveren som holder meldingene kalles en megler, og forbrukere kan abonnere på ett eller flere temaer. For å balansere belastningen kan meldingene i et tema deles inn i flere partisjoner, og jo flere partisjoner, desto høyere parallellisme og gjennomstrømning i Kafka.
Kafka-klynger krever Zookeeper-støtte for å implementere klynger, og Zookeeper er allerede inkludert i den nyeste Kafka-distribusjonen, som kan distribueres for å starte en Zookeeper-server og en Kafka-server samtidig, eller bruke andre eksisterende Zookeeper-klynger.
I motsetning til tradisjonell MQ må forbrukerne beholde en offset alene, og når de mottar meldinger fra Kafka, henter de kun meldinger etter gjeldende offset. Kafkas scala/java-klient implementerer allerede denne delen av logikken ved å lagre offset til zookeeperen. Hver forbruker kan velge en ID, og forbrukere med samme ID vil bare motta den samme meldingen én gang.Hvis alle brukere av et tema bruker samme id, er det en tradisjonell kø. Hvis hver forbruker bruker en forskjellig ID, er det en tradisjonell pub-sub.
Anmeldelse:
Kafka-forbruk
1. Forbrukere av samme group_id, kun én forbruker kan konsumere meldinger (kø-kø-modus）
2. Forbrukere av ulike group_id mottar de samme nyhetene
Fordeler med Kafka
Distribuert og svært skalerbart. Kafka-klynger kan skaleres transparent for å legge til nye servere i klyngen.
Høy ytelse. Kafkas ytelse overgår langt tradisjonelle MQ-implementasjoner som ActiveMQ og RabbitMQ, spesielt Kafka, som også støtter batchoperasjoner. Følgende bilde viser resultatene fra LinkedIns stresstest for forbrukerytelse:
Feiltoleranse. Data fra hver partisjon i Kafka replikeres til flere servere. Når en megler mislykkes, vil ZooKeeper-tjenesten varsle produsenten og forbrukeren, som deretter bytter til en annen megler.
Ulemper med Kafka:
Gjenta meldinger. Kafka garanterer bare at hver melding vil bli levert minst én gang, og selv om sjansene er små, er det en sjanse for at en melding blir levert flere ganger.
Nyhetene er ute av rekkefølge. Selv om meldinger inne i en partisjon er garantert å være ordnede, er det ikke garantert at meldingsleveransen mellom partisjonene er ordnet hvis et emne har flere partisjoner.
Kompleksitet. Kafka krever støtte fra dyrepasserklynger, og emner krever vanligvis manuelt arbeid for å opprette, distribuere og vedlikeholde dyrere enn vanlige meldingskøer
.NET/C# meldingskø Kafka-operasjoner
Først, bruk .NET Core 3.1 for å lage to nye konsollprosjekter, nemlig Kafka-Consumer og Kafka-Producer
Bruk nuget for å referere til Confluent.Kafka-pakken slik, med følgende kommando:
GitHub-adresse:Innloggingen med hyperkoblingen er synlig.
Vi starter Producer-programmet først, og hvis vi starter forbrukeren først, får vi følgende feil:
Feil oppstod: Megler: Ukjent emne eller partisjon
Denne artikkelen vil ta for seg innstillingerEnableAutoOffsetStore er feil, det vil si å manuelt sette offset-lagringen (lignende en manuell bekreftelsesmelding)
Forbrukere setter ikke OffsetStore etter forbruk
Prøv å bruke produsenten til å lage to meldinger, slå på forbrukerforbruk, MaxPollIntervalMs = 10000 // 10 sekunder uten manuell innstilling, la andre klienter konsumere, selvfølgelig vil det ikke bli konsumert av andre klienter innen 10 sekunder
MaxPollIntervalMs forklarer
For avanserte forbrukere er maksimal tillatt tid til å konsumere meldinger mellom samtaler (for eksempel rd_kafka_consumer_poll()). Hvis dette intervallet overskrides, anses forbrukeren som feilet, og gruppen rebalanseres slik at partisjonen tildeles et annet medlem av forbrukergruppen. Advarsel: Offset-commits er kanskje ikke mulig på nåværende tidspunkt. Merk: Det anbefales å sette "enable.auto.offset.store=false" for applikasjoner som behandler lenge, og deretter eksplisitt lagre offset (ved å bruke offsets_store()) etter at meldingen er behandlet* for å sikre at offset ikke automatisk committeres før behandlingen er fullført. Sjekk én gang i sekundet med to intervaller. For mer informasjon, se KIP-62.
Gjengivelsene er som følger:
OffsetStore settes etter at forbrukeren er ferdig med å bruke penger.
kode
Etter at oppsettet er fullført, vent 10 sekunder, så vil det fortsatt fungereMottok siste melding(Når forbrukeren kobler seg til megleren,Start forbruket fra offsetposisjonenHvis c.Commit(cr) er satt; Den siste meldingen vil ikke bli mottatt gjentatte ganger.
Se kildekode
commit offset + 1 commit, og til slutt kall Librdkafka.topic_partition_list_destroy(cOffsets);
Innloggingen med hyperkoblingen er synlig.
Innloggingen med hyperkoblingen er synlig.
Sett en annen GroupId
Prøv å sette en annen GroupId via kommandolinjeparameteren, og send deretter en melding gjennom produsenten, som vist i bildet nedenfor:
Både clinet1 og client2Motta historiske meldinger, og etter at produsenten sender ut en melding, vil begge nesten væreMotta meldinger samtidig。
Nye forbrukere mottar bare nye meldinger
Hvordan får du en ny klient til å motta kun nye meldinger og ignorere historiske data?
Innstillingene er som følger:
Som vist nedenfor:
Produsentkode
Som følger:
Forbrukerkode
Som følger:
Nedlasting av kildekode
Turister, hvis dere vil se det skjulte innholdet i dette innlegget, vær så snill Svare
|
Publisert på 13.04.2021 11:45:31
|
|
|
|
Vert|
Publisert på 15.04.2021 09:31:05
|
Publisert på 16.06.2021 12:41:09
|
