Úvod do spotrebiteľskej skupiny Kafka
Spotrebiteľská skupina Kafka je v podstate množstvo spotrebiteľov Kafka, ktorí dokážu čítať údaje paralelne z témy Kafka. Spotrebiteľská skupina Kafka má nasledujúce vlastnosti:
- Všetci zákazníci v skupine majú rovnakú skupinu group.id.
- Každý oddiel v téme číta iba jeden spotrebiteľ.
- Maximálny počet spotrebiteľov sa rovná počtu oddielov v téme. Ak existuje viac spotrebiteľov ako skupín, niektorí zákazníci zostanú nečinní.
- Spotrebiteľ môže čítať z viac ako jedného oddielu.
Dôležitosť spotrebiteľskej skupiny Kafka
Pre maloobchodnú organizáciu bude veľké množstvo výrobcov, ktorí generujú údaje, obrovskou rýchlosťou. Teraz, aby sme mohli čítať veľké množstvo údajov, potrebujeme paralelne bežať viacerých spotrebiteľov. Na strane výrobcu je relatívne jednoduchšie, keď každý výrobca vytvára údaje nezávisle od ostatných. Ale na strane spotrebiteľa, ak máme viac ako jedného spotrebiteľa, ktorý čítal tú istú tému, existuje veľká šanca, že každá správa bude prečítaná viackrát. Kafka rieši tento problém pomocou skupiny spotrebiteľov. V každom prípade iba jeden spotrebiteľ môže čítať údaje z oddielu.
Priečky skupiny Kafka Consumer Group
Predpokladajme, že máme tému Kafka a sú v nej 4 oddiely. Potom môžeme mať nasledujúce scenáre:
1. Počet spotrebiteľov = Počet oddielov
V takom prípade si každý Zákazník prečíta údaje z každého oddielu, čo je ideálny prípad.
2. Počet spotrebiteľov> Počet oddielov
V tomto prípade zostane jeden spotrebiteľ nečinný a vedie k zlému využitiu zdroja.
3. Počet spotrebiteľov <Počet priečok
V takom prípade bude jeden zo spotrebiteľov čítať údaje z viac ako jedného oddielu.
4. Číslo skupiny spotrebiteľov> 1
V tomto prípade je téma prihlásená na viac ako jednu skupinu spotrebiteľov, ktorá uspokojuje dve rôzne aplikácie. Tieto dve aplikácie môžu bežať nezávisle od seba.
Výhody spotrebiteľskej skupiny Kafka
Spotrebiteľská skupina prináša nasledujúce výhody:
- Škálovateľnosť: Niekoľko spotrebiteľov, ktorí súčasne čítajú údaje, určite zvyšuje mieru spotreby údajov a umožňuje systému čítať veľké množstvo údajov.
- Tolerancia porúch: Predpokladajme, že sme mali iba jedného spotrebiteľa (na čítanie nie tak veľkého objemu údajov), čo by sa stalo, ak by spotrebiteľ z nejakého dôvodu zlyhal? Celý plynovod sa zlomí.
- Load Balancing: Kafka delí oddiely spravodlivo s každým spotrebiteľom, čím sa proces spotreby údajov stáva plynulým a efektívnym.
- Opätovné vyváženie: Ak sa pridá nový spotrebiteľ alebo sa zastaví existujúci, Kafka znovu vyváži zaťaženie dostupných spotrebiteľov.
Ako Kafka premosťuje dva modely?
Poďme najprv diskutovať o dvoch modeloch zasielania správ.
1. Fronty správ
V tomto modeli sa prúd správ posiela od jedného výrobcu iba jednému spotrebiteľovi. Každá správa je teda iba na čítanie a keď spotrebiteľ správu stiahne, správa sa z frontu vymaže. Typickým príkladom môže byť vydanie výplaty, pri ktorej musí byť každá výplata vydaná iba raz. Tento model tiež nezaručuje, že správy sa budú doručovať v poriadku. Škálovateľnosť spracovania správ je obmedzená na jednu doménu.
2. Publikovanie - odber správ
V tomto modeli môžu správy uverejnené výrobcom predplatiť viac ako jeden spotrebiteľ. Výrobca a spotrebiteľ sú vo veľkej miere oddelení. Tento model zabezpečuje, že každý spotrebiteľ dostane správy v téme v presnom poradí vygenerovanom výrobcom. Typickým príkladom môže byť parabola, ktorá vydáva rôzne kanály, ako je hudba, film, šport atď., A zákazníci si môžu predplatiť viac ako jeden kanál. Pretože existuje niekoľko účastníkov danej témy, škálovanie spracovania tokov je výzvou.
Kafka je tak populárna, pretože hoci je založená na modeli publikovania a prihlásenia na odber, má výhody systému frontov na odosielanie správ. Ako už bolo uvedené vyššie, ak máme skupinu spotrebiteľov, spoločnosť Kafka zabezpečí, aby zákazník každú správu v téme prečítal iba raz (čo je podobné systému frontu správ). Ďalšou výhodou je, že sprostredkovatelia si správy uchovávajú (na určitú dobu, takže sú odolné voči chybám) a ak máme viac ako jednu skupinu spotrebiteľov, môžu čítať správy z rovnakej témy, ale spracovávať ich inak.
Použite prípadové implikácie
Predpokladajme, že máme jednoduchú cloudovú platformu, kde používateľom umožňujeme nasledujúce operácie:
- Uložte súbory do cloudu.
- Zobraziť ich súbory v cloude.
- Stiahnite si ich súbory z cloudu.
Na začiatku sme mali veľmi malú základňu používateľov. Chceli sme odvodiť rôzne štatistiky (na hodinovom základe), ako sú aktívni používatelia, počet žiadostí o odovzdanie, počet žiadostí o prevzatie atď. Aby sme splnili požiadavky, zriadili sme Kafka klaster, ktorý vytvára protokoly (generované našou aplikáciou) do témy a existuje aplikácia, ktorá túto tému spotrebuje (pomocou spotrebiteľa) a potom ju spracuje, aby vygenerovala požadované štatistiky a nakoniec zobrazila tie na webovej stránke.
Keď sa ľuďom začali páčiť naše služby, viac ľudí ich začalo používať, čím generovali veľa protokolov za hodinu. Zistili sme, že aplikácia, ktorá konzumuje túto tému, sa extrémne spomalila, pretože sme používali iba jedného spotrebiteľa. Aby sme problém vyriešili, do skupiny sme pridali niektorých spotrebiteľov a zistili sme výrazné zlepšenie výkonnosti.
Narazili sme na ďalšiu požiadavku, keď sme museli protokoly zapisovať do klastra HDFS a tento proces by mal prebiehať nezávisle od predchádzajúcej aplikácie (je to preto, že s ďalším nárastom údajov sme plánovali vyradiť prvú aplikáciu z prevádzky a odvodiť všetky štatistiky v prostredí HDFS). Na splnenie tejto požiadavky sme vyvinuli ďalšiu aplikáciu, ktorá sa prihlásila na odber témy pomocou inej skupiny spotrebiteľov a údaje zapísala do klastra HDFS.
Odporúčané články
Toto je sprievodca spotrebiteľskou skupinou Kafka. Tu diskutujeme o dôležitosti spotrebiteľskej skupiny Kafka a o tom, ako Kafka premosťuje dva modely spolu s dôsledkami prípadu použitia. Viac informácií nájdete aj v nasledujúcich článkoch
- Aplikácie Kafka
- Ako nainštalovať Kafka?
- Kafka Rozhovor Otázky
- Architektúra HDFS
- Rôzne typy nástrojov Kafka