Kafka je vysoko výkonný, distribuovaný systém správ vyvinutý spoločnosťou LinkedIn, ktorý sa široko používa v situáciách ako zber logov, spracovanie streamovaných dát, online a offline distribúcia správ a ďalšie. Hoci nie je navrhnutý ako tradičný MQ, Kafaka môže vo väčšine prípadov nahradiť tradičné komunikačné systémy, ako je ActiveMQ.
Kafka organizuje tok správ podľa tém a server, ktorý správy uchováva, sa nazýva broker, pričom spotrebitelia sa môžu prihlásiť na odber jednej alebo viacerých tém. Na vyváženie záťaže je možné správy témy rozdeliť do viacerých častíc, pričom čím viac oddielov, tým väčší paralelizmus a priepustnosť Kafku.
Kafka klastre vyžadujú podporu zookeeperu na implementáciu klastrov a zookeeper je už zahrnutý v najnovšej Kafka distribúcii, ktorú možno nasadiť na súčasné spustenie zookeeper servera a Kafka servera, alebo použiť iné existujúce zookeeper klastre.
Na rozdiel od tradičného MQ si spotrebitelia potrebujú offset ponechať sami a pri prijímaní správ z Kafky sťahujú správy až po aktuálnom offsete. Kafka scala/java klient už túto časť logiky implementuje tým, že offset ukladá do zookeepera. Každý spotrebiteľ si môže vybrať ID a spotrebitelia s rovnakým ID dostanú rovnakú správu len raz.Ak všetci spotrebitelia témy používajú rovnaké ID, ide o tradičnú frontu. Ak každý spotrebiteľ používa iné ID, ide o tradičný pub-sub.
Revízia:
Kafka spotreba
1. Spotrebitelia tej istej group_id, iba jeden spotrebiteľ môže konzumovať správy (Režim fronty）
2. Spotrebitelia rôznych group_id dostávajú rovnaké správy
Výhody Kafku
Distribuované a vysoko škálovateľné. Kafka klastre je možné transparentne škálovať tak, aby pridávali nové servery do klastra.
Vysoký výkon. Výkon Kafky výrazne prevyšuje tradičné implementácie MQ, ako sú ActiveMQ a RabbitMQ, najmä Kafka, ktorá tiež podporuje dávkové operácie. Nasledujúci obrázok ukazuje výsledky záťažového testu spotrebiteľskej výkonnosti LinkedIn:
Odolnosť voči chybám. Dáta z každej partície v Kafka sa replikujú na niekoľko serverov. Keď sprostredkovateľ zlyhá, služba ZooKeeper informuje producenta a spotrebiteľa, ktorí prejdú na iného sprostredkovateľa.
Nevýhody Kafku:
Opakované správy. Kafka zaručuje, že každá správa bude doručená aspoň raz, a hoci sú šance malé, existuje šanca, že správa bude doručená viackrát.
Správy sú mimo poriadku. Hoci správy v rámci partície sú zaručene usporiadané, ak má téma viacero partícií, doručenie správ medzi partiérami nie je zaručene usporiadané.
Komplexnosť. Kafka vyžaduje podporu zookeeper klastroch a témy zvyčajne vyžadujú manuálnu prácu na vytvorenie, nasadenie a údržbu, ktorá je drahšia než bežné fronty správ
.NET/C# fronta správ Kafka operácie
Najprv použiť .NET Core 3.1 na vytvorenie dvoch nových konzolových projektov, konkrétne Kafka-Consumer a Kafka-Producer
Použite nuget na odkazovanie na balík Confluent.Kafka takto, pomocou nasledujúceho príkazu:
GitHub adresa:Prihlásenie na hypertextový odkaz je viditeľné.
Najskôr spustíme program Producer a ak spustíme najskôr spotrebiteľa, dostaneme nasledujúcu chybu:
Vyskytla sa chyba: Broker: Neznáma téma alebo partícia
Tento článok sa zaoberá nastaveniamiEnableAutoOffsetStore je nepravdivý, teda manuálne nastavenie offsetovej pamäte (podobne ako manuálna potvrdzovacia správa)
Spotrebitelia nenastavujú OffsetStore po spotrebe
Skúste použiť generátor na vytvorenie dvoch správ, zapnite spotrebiteľskú spotrebu, MaxPollIntervalMs = 10000 // 10 sekúnd bez manuálneho nastavenia, umožniť iným klientom spotrebovať, samozrejme, do 10 sekúnd to nebudú spotrebovať iní klienti
MaxPollIntervalMs vysvetľuje
Pre pokročilých spotrebiteľov je to maximálny povolený čas na spotrebu správ medzi hovormi (napríklad rd_kafka_consumer_poll()). Ak je tento interval prekročený, spotrebiteľ sa považuje za neúspešného a skupina sa prebalansuje tak, že partícia je priradená inému členovi spotrebiteľskej skupiny. Upozornenie: Offsetové commity momentálne nemusia byť možné. Poznámka: Odporúča sa nastaviť "enable.auto.offset.store=false" pre aplikácie, ktoré spracovávajú dlhý čas, a potom explicitne uložiť offset (pomocou offsets_store()) po spracovaní správy*, aby sa zabezpečilo, že offset nebude automaticky potvrdený pred dokončením spracovania. Kontroluj raz za sekundu v intervaloch po dvech. Pre viac informácií pozri KIP-62.
Vizualizácie sú nasledovné:
OffsetStore sa nastavuje po tom, čo spotrebiteľ skončí s výdavkami
kód
Po dokončení nastavenia počkajte 10 sekúnd a stále to fungujeDostal som poslednú správu(Keď sa spotrebiteľ pripojí k maklérovi,Začnite spotrebu z offsetovej pozícieAk je c.Commit(cr) nastavený; Posledná správa nebude prijatá opakovane.
Zobraziť zdrojový kód
commit offset + 1 commit a nakoniec volajte Librdkafka.topic_partition_list_destroy(cOffsets);
Prihlásenie na hypertextový odkaz je viditeľné.
Prihlásenie na hypertextový odkaz je viditeľné.
Nastavte iný GroupId
Skúste nastaviť iný GroupId pomocou parametra príkazového riadku a potom pošlite správu cez producenta, ako je znázornené na nasledujúcom obrázku:
Clinet1 aj client2Prijímajte historické správy, a po tom, čo producent pošle správu, obaja budú takmerPrijímať správy súčasne。
Noví spotrebitelia dostávajú len nové správy
Ako dosiahnuť, aby nový klient dostával len nové správy a ignoroval historické údaje?
Nastavenia sú nasledovné:
Ako je uvedené nižšie:
Kód producenta
Takto:
Spotrebiteľský kód
Takto:
Stiahnutie zdrojového kódu
Turisti, ak chcete vidieť skrytý obsah tohto príspevku, prosím. Odpoveď
|
Zverejnené 13. 4. 2021 11:45:31
|
|
|
|
Prenajímateľ|
Zverejnené 15. 4. 2021 9:31:05
|
Zverejnené 16. 6. 2021 12:41:09
|
