Kafka er et højtydende, distribueret beskedsystem udviklet af LinkedIn, som er bredt anvendt i scenarier som logindsamling, streaming af data, online og offline beskeddistribution og mere. Selvom Kafaka ikke er designet som en traditionel MQ, kan den i de fleste tilfælde erstatte traditionelle beskedsystemer som ActiveMQ.
Kafka organiserer strømmen af beskeder efter emner, og serveren, der opbevarer beskederne, kaldes en mægler, og forbrugere kan abonnere på et eller flere emner. For at balancere belastningen kan emnernes beskeder opdeles i flere partitioner, og jo flere partitioner, desto højere er parallelismen og gennemstrømningen af Kafka.
Kafka-klynger kræver zookeeper-support for at implementere klynger, og zookeeper er allerede inkluderet i den nyeste Kafka-distribution, som kan implementeres til at starte både en zookeeper-server og en Kafka-server samtidig eller bruge andre eksisterende zookeeper-klynger.
I modsætning til traditionel MQ skal forbrugerne selv holde en offset, og når de modtager beskeder fra Kafka, skal de kun trække beskeder efter den aktuelle offset. Kafkas scala/java-klient implementerer allerede denne del af logikken ved at gemme offset til zookeeperen. Hver forbruger kan vælge et ID, og forbrugere med samme ID vil kun modtage den samme besked én gang.Hvis forbrugere af et emne alle bruger det samme id, er det en traditionel kø. Hvis hver forbruger bruger et forskelligt ID, er det en traditionel pub-sub.
Anmeldelse:
Kafka-forbrug
1. Forbrugere af samme group_id, kun én forbruger kan forbruge beskeder (kø-kø-tilstand）
2. Forbrugere af forskellige group_id modtager de samme nyheder
Fordele ved Kafka
Distribueret og meget skalerbar. Kafka-klynger kan skaleres transparent for at tilføje nye servere til klyngen.
Høj ydeevne. Kafkas ydeevne overgår langt traditionelle MQ-implementeringer som ActiveMQ og RabbitMQ, især Kafka, som også understøtter batchoperationer. Følgende billede viser resultaterne af LinkedIns forbrugerpræstations-stresstest:
Fejltolerance. Data fra hver partition i Kafka replikeres til flere servere. Når en mægler fejler, vil ZooKeeper-tjenesten underrette producenten og forbrugeren, som skifter til en anden mægler.
Ulemper ved Kafka:
Gentag beskeder. Kafka garanterer kun, at hver besked bliver leveret mindst én gang, og selvom chancerne er små, er der en chance for, at en besked bliver leveret flere gange.
Nyhederne er ude af rækkefølge. Selvom beskeder inde i en partition er garanteret at være ordnede, er det ikke garanteret, at beskedleveringen mellem partitionerne er ordnet, hvis et emne har flere partitioner.
Kompleksitet. Kafka kræver støtte fra zookeeper-klynger, og emner kræver som regel manuelt arbejde for at oprette, implementere og vedligeholde dyrere end almindelige beskedkøer
.NET/C# meddelelseskø Kafka-operationer
Først skal du bruge .NET Core 3.1 til at skabe to nye konsolprojekter, nemlig Kafka-Consumer og Kafka-Producer
Brug nuget til at referere til Confluent.Kafka-pakken på denne måde, med følgende kommando:
GitHub-adresse:Hyperlink-login er synlig.
Vi starter Producer-programmet først, og hvis vi starter forbrugeren først, får vi følgende fejl:
Fejl opstod: Broker: Ukendt emne eller partition
Denne artikel vil tage hensyn til indstillingerEnableAutoOffsetStore er falsk, det vil sige manuelt at indstille offset-lageret (svarende til en manuel bekræftelsesmeddelelse)
Forbrugere sætter ikke OffsetStore efter forbrug
Prøv at bruge produceren til at producere to beskeder, slå forbrugerforbrug til, MaxPollIntervalMs = 10000 // 10 sekunder uden manuel indstilling, lad andre klienter forbruge, selvfølgelig vil det ikke blive forbrugt af andre klienter inden for 10 sekunder
MaxPollIntervalMs forklarer
For avancerede forbrugere var den maksimale tilladte tid til at forbruge beskeder mellem opkald (for eksempel rd_kafka_consumer_poll()). Hvis dette interval overskrides, anses forbrugeren for at have fejlet, og gruppen rebalanceres, så partitionen tildeles et andet medlem af forbrugergruppen. Advarsel: Offset-commits er muligvis ikke mulige på nuværende tidspunkt. Bemærk: Det anbefales at sætte "enable.auto.offset.store=false" for applikationer, der behandler i lang tid, og derefter eksplicit gemme offset (ved at bruge offsets_store()) efter beskeden er behandlet* for at sikre, at offset ikke automatisk committes, før behandlingen er færdig. Tjek én gang i sekundet med to intervaller. For mere information, se KIP-62.
Renderingerne er som følger:
OffsetStore fastsættes efter, at forbrugeren har afsluttet sine udgifter
kodeks
Når opsætningen er færdig, vent 10 sekunder, så vil den stadig gøre detModtog den sidste besked(Når forbrugeren forbinder til mægleren,Start forbruget fra offset-positionenHvis c.Commit(cr) er sat; Den sidste besked vil ikke blive modtaget gentagne gange.
Se kildekode
commit offset + 1 commit, og kald til sidst Librdkafka.topic_partition_list_destroy(cOffsets);
Hyperlink-login er synlig.
Hyperlink-login er synlig.
Sæt et andet GroupId
Prøv at sætte et andet GroupId via kommandolinjeparameteren, og send derefter en besked gennem produceren, som vist i følgende billede:
Både clinet1 og client2Modtag historiske beskeder, og efter at producenten har sendt en besked ud, vil begge næsten væreModtag beskeder samtidig。
Nye forbrugere modtager kun nye beskeder
Hvordan får man en ny klient til kun at modtage nye beskeder og ignorere historiske data?
Indstillingerne er som følger:
Som vist nedenfor:
Producentkode
Som følger:
Forbrugerkode
Som følger:
Kildekode-download
Turister, hvis I vil se det skjulte indhold i dette indlæg, så vær venlig Svar
|
Opslået på 13/04/2021 11.45.31
|
|
|
|
Udlejer|
Opslået på 15/04/2021 09.31.05
|
Opslået på 16/06/2021 12.41.09
|
