Kafka je zmogljiv, distribuiran sistem za sporočanje, ki ga je razvil LinkedIn in se široko uporablja v primerih, kot so zbiranje dnevnikov, pretočna obdelava podatkov, spletna in offline distribucija sporočil ter še več. Čeprav ni zasnovan kot tradicionalni MQ, lahko Kafaka v večini primerov nadomesti tradicionalne sisteme za sporočanje, kot je ActiveMQ.
Kafka organizira pretok sporočil po temah, strežnik, ki shranjuje sporočila, pa se imenuje posrednik, potrošniki pa se lahko naročijo na eno ali več tem. Da bi uravnotežili obremenitev, je mogoče sporočila teme razdeliti v več particij, in več kot jih je, višja je paralelizemnost in prepustnost Kafke.
Kafka grozdi zahtevajo podporo za Zookeeper za implementacijo grozdov, Zookeeper pa je že vključen v najnovejšo Kafka distribucijo, ki jo je mogoče namestiti za hkratni zagon strežnika Zookeeper in strežnika Kafka ali uporabiti druge obstoječe grozde.
Za razliko od tradicionalnega MQ morajo potrošniki sami hraniti offset, in ko prejemajo sporočila iz Kafke, vlečejo sporočila šele po trenutnem offsetu. Kafkin/java odjemalec že implementira ta del logike tako, da shrani premik na Zookeeperja. Vsak potrošnik lahko izbere osebni dokument, potrošniki z isto osebno številko pa bodo isto sporočilo prejeli le enkrat.Če vsi uporabniki teme uporabljajo isti ID, gre za tradicionalno čakalno vrsto. Če vsak uporabnik uporablja drugačen ID, gre za tradicionalni pub-sub.
Pregled:
Kafka potrošnja
1. Potrošniki istega group_id, le en potrošnik lahko porablja sporočila (Način čakalne vrste）
2. Potrošniki različnih group_id prejmejo enake novice
Prednosti Kafke
Distribuirano in zelo razširljivo. Kafka grozdi je mogoče transparentno skalirati za dodajanje novih strežnikov v grozd.
Visoka zmogljivost. Kafkina zmogljivost močno presega tradicionalne implementacije MQ, kot sta ActiveMQ in RabbitMQ, zlasti Kafka, ki prav tako podpira serijske operacije. Naslednja slika prikazuje rezultate LinkedInovega stresnega testa potrošniške uspešnosti:
Odpornost na napake. Podatki iz vsake particije v Kafki se replicirajo na več strežnikov. Ko posrednik odpove, storitev ZooKeeper obvesti proizvajalca in potrošnika, ki preklopita na drugega posrednika.
Slabosti Kafke:
Ponovite sporočila. Kafka zagotavlja le to, da bo vsako sporočilo dostavljeno vsaj enkrat, in čeprav so možnosti majhne, obstaja možnost, da bo sporočilo dostavljeno večkrat.
Novice so izven reda. Čeprav so sporočila znotraj particije zagotovljeno urejena, če ima tema več particij, dostava sporočil med particijami ni zagotovljeno urejena.
Kompleksnost. Kafka zahteva podporo grozdov Zookeeper, teme pa običajno zahtevajo ročno delo za ustvarjanje, nameščanje in vzdrževanje, dražje kot običajne vrste sporočil
.NET/C# čakalna vrsta sporočil Kafka operacije
Najprej uporabite .NET Core 3.1 za ustvarjanje dveh novih konzolnih projektov, in sicer Kafka-Consumer in Kafka-Producer
Uporabite nuget za referenco na paket Confluent.Kafka tako, z naslednjim ukazom:
GitHub naslov:Prijava do hiperpovezave je vidna.
Najprej začnemo program Producent, in če najprej zaženemo potrošnika, dobimo naslednjo napako:
Prišlo je do napake: Posrednik: Neznana tema ali particija
Ta članek bo zajemal okoljaEnableAutoOffsetStore je napačen, torej ročno nastaviti pomnilnik odmika (podobno kot ročno potrditveno sporočilo)
Potrošniki ne nastavijo OffsetStore po potrošnji
Poskusite uporabiti producent za ustvarjanje dveh sporočil, vklopite potrošniško porabo, MaxPollIntervalMs = 10000 // 10 sekund brez ročne nastavitve, dovolite drugim odjemalcem, da jih porabijo, seveda ga drugi odjemalci ne bodo porabili v 10 sekundah
MaxPollIntervalMs pojasnjuje
Za napredne uporabnike je to največji dovoljeni čas za porabo sporočil med klici (na primer rd_kafka_consumer_poll()). Če je ta interval presežen, se potrošnik šteje za neuspešnega in skupina se ponovno uravnoteži, tako da se particija dodeli drugemu članu potrošniške skupine. Opozorilo: Offset commiti trenutno morda niso mogoči. Opomba: Priporočljivo je nastaviti "enable.auto.offset.store=false" za aplikacije, ki obdelujejo dolgo časa, in nato eksplicitno shraniti premik (z uporabo offsets_store()) po obdelavi sporočila*, da se zagotovi, da premik ni samodejno potrjen, preden je obdelava dokončana. Preverjaj enkrat na sekundo v intervalih po dva. Za več informacij glejte KIP-62.
Upodobitve so naslednje:
OffsetStore se nastavi po tem, ko potrošnik konča s porabo
koda
Ko je nastavitev končana, počakaj 10 sekund in bo še vedno delovaloPrejel zadnje sporočilo(Ko se potrošnik poveže z posrednikom,Začni porabo iz offset položajaČe je c.Commit(cr) nastavljen; Zadnje sporočilo ne bo prejelo večkrat.
Oglejte si izvorno kodo
potrdi premik + 1 commit in na koncu pokliči Librdkafka.topic_partition_list_destroy(cOffsets);
Prijava do hiperpovezave je vidna.
Prijava do hiperpovezave je vidna.
Nastavi drugačen GroupId
Poskusite nastaviti drugačen GroupId preko parametra ukazne vrstice in nato pošljite sporočilo preko producenta, kot je prikazano na naslednji sliki:
Tako clinet1 kot client2Prejemanje zgodovinskih sporočil, in ko producent pošlje sporočilo, bosta skoraj obaPrejemajte sporočila hkrati。
Novi potrošniki prejemajo le nova sporočila
Kako narediti, da nova stranka prejema samo nova sporočila in ignorira zgodovinske podatke?
Nastavitve so naslednje:
Kot je prikazano spodaj:
Koda proizvajalca
Kot sledi:
Potrošniška koda
Kot sledi:
Prenos izvorne kode
Turisti, če želite videti skrito vsebino te objave, prosim Odgovoriti
|
Objavljeno na 13. 04. 2021 11:45:31
|
|
|
|
Najemodajalec|
Objavljeno na 15. 04. 2021 09:31:05
|
Objavljeno na 16. 06. 2021 12:41:09
|
