A Kafka egy nagy teljesítményű, elosztott üzenetküldő rendszer, amelyet a LinkedIn fejlesztett ki, és széles körben használják olyan helyzetekben, mint a naplógyűjtés, adatfeldolgozás, online és offline üzenetterjesztés és még sok más. Bár nem hagyományos MQ-ként tervezték, a Kafaka a legtöbb esetben helyettesítheti a hagyományos üzenetküldő rendszereket, például az ActiveMQ-t.
A Kafka témák szerint szervezi az üzenetek áramlását, és az üzeneteket tároló szervert brókernek hívják, így a fogyasztók egy vagy több témára is előfizethetnek. A terhelés kiegyensúlyozásához egy téma üzenetei több partícióra oszthatók, és minél több partíció, annál nagyobb a párhuzamosság és a Kafka áteresztősége.
A Kafka klaszterekhez zookeeper támogatás szükséges a klaszterek megvalósításához, és a zookeeper már benne van a legújabb Kafka disztribúcióban, amely egyszerre telepíthető zookeeper szerver és Kafka szerver indítására, vagy más meglévő zookeeper klasztereket is használhat.
A hagyományos MQ-tól eltérően a fogyasztóknak önmaguknak kell megtartaniuk az offsetet, és amikor üzeneteket kapnak a kafka-tól, csak a jelenlegi eltolás után húzzák le az üzeneteket. A Kafka scala/java kliense már ezt a logikai részt valósítja meg azzal, hogy az offsetet elmenti az állatkerti őrzőnek. Minden fogyasztó választhat azonosítót, és ugyanazzal az azonosítóval rendelkező fogyasztók csak egyszer kapják ugyanazt az üzenetet.Ha egy téma fogyasztói mind ugyanazt az azonosítót használják, az hagyományos sor. Ha minden fogyasztó más azonosítót használ, az hagyományos pub-sub.
Szemle:
Kafka fogyasztása
1. Ugyanannak a group_id fogyasztói csak egy fogyasztó fogyaszthat üzeneteket (Sorban állás mód）
2. Különböző group_id fogyasztói ugyanazt a hírt kapják
A Kafka előnyei
Elosztott és nagyon skálázható. A Kafka klasztereket átláthatóan skálázhatók, hogy új szervereket adjanak a klaszterhez.
Magas teljesítmény. A Kafka teljesítménye messze meghaladja a hagyományos MQ megvalósításokat, mint az ActiveMQ és a RabbitMQ, különösen a Kafka, amely szintén csomagos műveleteket támogat. Az alábbi kép a LinkedIn fogyasztói teljesítmény stressztesztjének eredményeit mutatja:
Hibatűrés. A Kafka minden partíciójának adatai több szerverre replikálnak. Ha egy bróker meghibásodik, a ZooKeeper szolgáltatás értesíti a termelőt és a fogyasztót, akik átváltanak egy másik brókerre.
A Kafka hátrányai:
Ismételd meg az üzeneteket. Kafka csak garantálja, hogy minden üzenetet legalább egyszer kézbesítenek, és bár az esélyek kicsik, az is előfordulhat, hogy egy üzenetet többször is kézbesítenek.
A hírek nem rendezőek. Bár a partíción belüli üzenetek garantáltan rendezettek, ha egy témában több partíció van, az üzenetküldés partíciók között nem garantált rendezett.
Komplexitás. A Kafkának állatkerti klaszterek támogatására van szüksége, és a témák általában kézi munkát igényelnek a létrehozása, telepítése és fenntartása drágább, mint az általános üzenetsorok
.NET/C# üzenetsor: Kafka műveletek
Először is, használd a .NET Core 3.1-et két új konzolprojekt létrehozására, nevezetesen a Kafka-Consumer és a Kafka-Producer
Használd a nuget-et, hogy hivatkozz a Confluent.Kafka csomagra így, a következő parancsval:
GitHub cím:A hiperlink bejelentkezés látható.
Először a Producer programot indítjuk, és ha először a fogyasztót indítjuk, akkor a következő hibát kapjuk:
Hiba történt: Broker: Ismeretlen téma vagy partíció
Ez a cikk a beállításokat fogja használniAz EnableAutoOffsetStore hamis, vagyis az eloltási tároló kézi beállítása (hasonlóan egy kézi megerősítő üzenethez)
A fogyasztók nem állítják be az OffsetStore-t fogyasztás után
Próbáld meg a producerrel két üzenetet generálni, kapcsold be a fogyasztói fogyasztást, MaxPollIntervalMs = 10000 // 10 másodperc manuális beállítás nélkül, engedd meg, hogy más kliensek is felhasználhassa, természetesen nem fogják 10 másodpercen belül más kliensek fogyasztani
MaxPollIntervalMs magyarázza
A haladó fogyasztók számára a maximális idő lehetővé tette az üzenetek fogyasztására a hívások között (például rd_kafka_consumer_poll()). Ha ezt az intervallumot túllépik, a fogyasztót meghibásodottnak tekintik, és a csoportot újrakiegyensúlyozzák úgy, hogy a partíciót egy másik fogyasztói csoport taghoz rendeljék át. Figyelem: Jelenleg nem feltétlenül lehetséges az offset commit. Megjegyzés: Ajánlott beállítani az "enable.auto.offset.store=false" beállítást olyan alkalmazásoknál, amelyek hosszú ideje dolgoznak, majd az üzenet feldolgozása után explicit módon tároljuk az offsetet (offsets_store()) használatával, hogy biztosítsuk, hogy az offset ne legyen automatikusan elkötelezve, mielőtt a feldolgozás befejeződik. Másodpercenként egyszer ellenőrizd kétszer. További információért lásd a KIP-62-t.
A képek a következők:
Az OffsetStore akkor van beállítva, miután a fogyasztó befejezte a költegetést.
kód
A beállítás után várj 10 másodpercet, és még mindig működikMegkaptam az utolsó üzenetet(Amikor a fogyasztó kapcsolatba lép a brókerrel,Kezdjük a fogyasztást az offset pozícióbólHa c.Commit(cr) be van állítva; Az utolsó üzenet nem érkezik meg ismételten.
Forráskód megtekintése
commit az offset + 1 commit, és végül Librdkafka.topic_partition_list_destroy(cOffsets) hívja;
A hiperlink bejelentkezés látható.
A hiperlink bejelentkezés látható.
Állíts be egy másik GroupId
Próbálj meg egy másik GroupId-t beállítani a parancssori paraméteren keresztül, majd küldj üzenetet a produceren keresztül, ahogy az alábbi képen is látható:
Mind a clinet1, mind a client2Történelmi üzenetek fogadása, és miután a producer üzenetet küld, mindkettő majdnem így leszÜzenetek egyszerre fogadására。
Az új fogyasztók csak új üzeneteket kapnak
Hogyan lehet egy új kliensnek csak új üzeneteket kapni, és figyelmen kívül hagyni a történelmi adatokat?
A beállítások a következők:
Ahogy az alábbiakban látható:
Producer kód
Következőképpen:
Fogyasztói kódex
Következőképpen:
Forráskód letöltés
Turisták, ha szeretnétek megnézni ennek a bejegyzésnek a rejtett tartalmát, kérlek Válasz
|
Közzétéve 2021. 04. 13. 11:45:31
|
|
|
|
Háziúr|
Közzétéve 2021. 04. 15. 9:31:05
|
Közzétéve 2021. 06. 16. 12:41:09
|
