Kafka je vysoce výkonný distribuovaný systém pro zasílání zpráv vyvinutý společností LinkedIn, který je široce využíván v situacích jako je sběr logů, zpracování streamovaných dat, online i offline distribuce zpráv a další. Ačkoliv není navržen jako tradiční MQ, Kafaka může ve většině případů nahradit tradiční komunikační systémy, jako je ActiveMQ.
Kafka organizuje tok zpráv podle témat a server, který zprávy uchovává, se nazývá broker, a spotřebitelé se mohou přihlásit k odběru jednoho nebo více témat. Aby bylo vyrovnáno zátěž, lze zprávy tématu rozdělit do více oddílů, a čím více oddílů, tím vyšší paralelizm a propustnost Kafky.
Kafka clustery vyžadují podporu Zookeeperu pro implementaci clusterů a Zookeeper je již zahrnut v nejnovější distribuci Kafka, kterou lze nasadit pro spuštění serveru Zookeeper a serveru Kafka současně, nebo použít jiné existující clustery Zookeeper.
Na rozdíl od tradičního MQ musí spotřebitelé offset uchovávat sami a při přijímání zpráv z Kafky stahují zprávy až po aktuálním offsetu. Kafkův klient Scala/Java už tuto část logiky implementuje tím, že offset ukládá do zookeeperu. Každý spotřebitel si může zvolit ID a spotřebitelé se stejným ID obdrží stejnou zprávu pouze jednou.Pokud všichni uživatelé tématu používají stejné ID, jedná se o tradiční frontu. Pokud každý spotřebitel používá jiné ID, jedná se o tradiční pub-sub.
Přezkoumání:
Spotřeba Kafky
1. Spotřebitelé stejného group_id, pouze jeden spotřebitel může konzumovat zprávy (Režim fronty）
2. Spotřebitelé různých group_id dostávají stejné zprávy
Výhody Kafky
Distribuované a vysoce škálovatelné. Kafka clustery lze transparentně škálovat a přidávat nové servery do clusteru.
Vysoký výkon. Výkon Kafky výrazně převyšuje tradiční implementace MQ, jako jsou ActiveMQ a RabbitMQ, zejména Kafka, která také podporuje dávkové operace. Následující obrázek ukazuje výsledky zátěžového testu výkonu spotřebitelů LinkedIn:
Odolnost vůči chybám. Data z každé partition v Kafce jsou replikována na několik serverů. Když zprostředkovatel selže, služba ZooKeeper informuje producenta a spotřebitele, kteří přejdou k jinému makléři.
Nevýhody Kafky:
Opakujte zprávy. Kafka zaručuje, že každá zpráva bude doručena alespoň jednou, a i když je pravděpodobnost malá, existuje šance, že zpráva bude doručena vícekrát.
Zprávy jsou mimo pořadí. Ačkoliv zprávy uvnitř oddílu jsou zaručeně uspořádané, pokud má téma více oddílů, není zaručeno uspořádané doručení zpráv mezi oddíly.
Složitost. Kafka vyžaduje podporu clusterů Zookeeper a témata obvykle vyžadují manuální práci při vytváření, nasazení a údržbě, která jsou dražší než běžné fronty zpráv
.NET/C# fronta zpráv Kafka operace
Nejprve použijte .NET Core 3.1 k vytvoření dvou nových konzolových projektů, konkrétně Kafka-Consumer a Kafka-Producer
Použijte nuget k odkazování na balíček Confluent.Kafka takto, pomocí následujícího příkazu:
Adresa GitHubu:Přihlášení k hypertextovému odkazu je viditelné.
Nejprve spustíme program Producent, a pokud spustíme spotřebitele jako první, dostaneme následující chybu:
Došlo k chybě: Broker: Neznámé téma nebo oddíl
Tento článek vám pohltí prostředíEnableAutoOffsetStore je nepravdivý, tedy ručně nastavit offsetovou paměť (podobně jako u ruční potvrzovací zprávy)
Spotřebitelé si po konzumaci nenastavují OffsetStore
Zkuste použít producenta k vytvoření dvou zpráv, zapněte spotřebitelskou spotřebu, MaxPollIntervalMs = 10000 // 10 sekund bez manuálního nastavení, nechte ostatní klienty spotřebovat, samozřejmě to nebude spotřebováno jinými klienty do 10 sekund
MaxPollIntervalMs vysvětluje
Pro pokročilé uživatele maximální povolený čas na spotřebu zpráv mezi hovory (například rd_kafka_consumer_poll()). Pokud je tento interval překročen, spotřebitel je považován za neúspěšného a skupina je přebalancována tak, aby byla partition přiřazena jinému členovi spotřebitelské skupiny. Varování: Commity offsetu nemusí být v tuto chvíli možné. Poznámka: Doporučuje se nastavit "enable.auto.offset.store=false" pro aplikace, které zpracovávají dlouhou dobu, a poté explicitně uložit offset (pomocí offsets_store()) po zpracování zprávy*, aby se zajistilo, že offset nebude automaticky potvrzen před dokončením zpracování. Kontrolujte jednou za sekundu v intervalech po dvou. Pro více informací viz KIP-62.
Vizualizace jsou následující:
OffsetStore se nastavuje poté, co spotřebitel dokončí výdaje
kód
Po dokončení nastavení počkejte 10 sekund a stále to fungujeObdržel jsem poslední zprávu(Když se spotřebitel připojí k makléři,Začněte spotřebu z pozice offsetuPokud je nastaveno c.Commit(cr); Poslední zpráva nebude opakovaně přijímána.
Zobrazit zdrojový kód
commit offset + 1 commit a nakonec volat Librdkafka.topic_partition_list_destroy(cOffsets);
Přihlášení k hypertextovému odkazu je viditelné.
Přihlášení k hypertextovému odkazu je viditelné.
Nastavte jiný GroupId
Zkuste nastavit jiný GroupId pomocí parametru příkazové řádky a poté odesílejte zprávu přes producenta, jak je vidět na následujícím obrázku:
Jak clinet1, tak klient2Přijímejte historické zprávy, a poté, co producent odešle zprávu, oba téměř budouPřijímejte zprávy současně。
Noví spotřebitelé dostávají pouze nové zprávy
Jak donutit, aby nový klient dostával pouze nové zprávy a ignoroval historická data?
Prostředí je následující:
Jak je uvedeno níže:
Kód producenta
Následovně:
Spotřebitelský kodex
Následovně:
Stažení zdrojového kódu
Turisté, pokud chcete vidět skrytý obsah tohoto příspěvku, prosím Odpověď
|
Zveřejněno 13.04.2021 11:45:31
|
|
|
|
Pronajímatel|
Zveřejněno 15.04.2021 9:31:05
|
Zveřejněno 16.06.2021 12:41:09
|
