Kafka tarbijarühm - Kafka tarbijarühma täielik juhend

Lang L: none (table-of-contents):

Anonim

Kafka tarbijarühma tutvustus

Kafka tarbijarühm on põhimõtteliselt hulk Kafka tarbijaid, kes saavad lugeda andmeid paralleelselt Kafka teemast. Kafka tarbijarühmal on järgmised omadused:

  • Kõigil rühma tarbijatel on sama group.id.
  • Igas teema jaotises loeb ainult üks tarbija.
  • Maksimaalne tarbijate arv võrdub teema partitsioonide arvuga. Kui tarbijaid on rohkem kui vaheseinu, jääb osa tarbijaid jõude.
  • Tarbija saab lugeda rohkem kui ühest sektsioonist.

Kafka tarbijarühma tähtsus

Jaekaubandusettevõtte jaoks on suur hulk tootjaid, kes koguvad andmeid tohutult kiiresti. Nüüd vajame suure hulga andmete lugemiseks mitut paralleelselt töötavat Tarbijat. Suhteliselt lihtsam on tootja poolel, kus iga tootja genereerib andmeid teistest sõltumatult. Kuid tarbija poolel, kui meil on rohkem kui üks sama teemaga seotud lugeja, on suur tõenäosus, et iga sõnumit loetakse mitu korda. Kafka lahendab selle probleemi Consumer Groupi abil. Igal juhul lubatakse partitsioonilt andmeid lugeda ainult ühel tarbijal.

Kafka tarbijarühma vaheseinad

Oletame, et meil on Kafka teema ja selles on 4 partitsiooni. Siis võivad meil olla järgmised stsenaariumid:

1. Tarbijate arv = vaheseinte arv

Sel juhul loeb iga tarbija andmeid iga sektsiooni kohta ja see on ideaalne juhtum.

2. Tarbijate arv> Vaheseinte arv

Sel juhul jääb üks tarbija jõude ja ressurssi kasutatakse halvasti.

3. Tarbijate arv <vaheseinte arv

Sel juhul loeb üks tarbija rohkem kui ühe partitsiooni andmeid.

4. Tarbijarühma arv> 1

Sel juhul on selle teema tellinud rohkem kui üks tarbijarühm, mis hõlmab kahte erinevat rakendust. Neid kahte rakendust saab kasutada üksteisest sõltumatult.

Kafka tarbijarühma eelised

Tarbijarühm lisab järgmised eelised:

  • Skaleeritavus: arv tarbijaid, kes loevad paralleelselt andmeid, suurendab kindlasti andmete tarbimise määra ja muudab süsteemi võimeliseks lugema suurt andmemahtu.
  • Veatolerants: kui oletame, et meil oli ainult üks tarbija (mitte nii suure andmemahu lugemiseks), mis juhtuks, kui tarbija mingil põhjusel ebaõnnestub? Kogu torujuhe puruneb.
  • Koormuse tasakaalustamine: Kafka jagab vaheseinad õiglaselt igale tarbijale, muutes seeläbi andmete tarbimise protsessi sujuvaks ja tõhusaks.
  • Tasakaalustamine: kui lisatakse uus tarbija või olemasolev peatub, tasakaalustab Kafka olemasolevate tarbijate koormust.

Kuidas Kafka neid kahte mudelit ühendab?

Kõigepealt arutame kahte sõnumsidemudelit.

1. Sõnumijärjekorrad

Selle mudeli korral saadetakse ühe tootja sõnumivoog ainult ühele tarbijale. Seega loetakse iga teade ainult lugemiseks üks kord ja kui tarbija tõmbab teate, kustutatakse see sõnum järjekorrast. Tüüpiline näide võib olla palgatšeki väljaandmine, kus iga palgatšekki tuleb välja anda ainult üks kord. Samuti ei taga see mudel sõnumite õiget kohaletoimetamist. Sõnumite töötlemise mastaapsus on piiratud ühe domeeniga.

2. Teadete avaldamine ja tellimine

Selle mudeli korral saavad tootja avaldatud sõnumeid tellida mitu tarbijat. Tootja ja tarbija on suurel määral lahutatud. See mudel tagab, et iga tarbija saab teemasõnumeid tootja loodud täpses järjekorras. Tüüpiliseks näiteks võib olla teler, mis avaldab erinevaid kanaleid, nagu muusika, filmid, sport jne, ja tarbijad saavad tellida mitu kanalit. Kuna teemat on mitu tellijat, on voogude töötlemise ulatuse muutmine väljakutse.

Kafka on nii populaarne, et kuigi see põhineb avaldamise-tellimise mudelil, on sellel teatesõnumite järjekordade süsteemi eeliseid. Nagu varem arutletud, tagab Kafka, kui meil on tarbijarühm, et iga teema kiri loetaks ainult ühe korra tarbija poolt (mis sarnaneb teatejärjekorra süsteemiga). Lisaeelisteks on see, et maaklerid säilitavad sõnumeid (muutes mõne aja jooksul seda tõrketaluvuseks) ja kui meil on rohkem kui üks tarbijarühm, saavad nad lugeda sama teema sõnumeid, kuid töödelda neid erinevalt.

Kasutage juhtumipõhist tähendust

Oletame, et meil on lihtne pilveplatvorm, kus lubame kasutajatele järgmisi toiminguid:

  • Salvestage failid pilve.
  • Vaadake nende faile pilves.
  • Laadige nende failid alla pilve.

Alguses oli meil väga väike kasutajaskond. Tahtsime saada mitmesugust statistikat (tunni kaupa), näiteks aktiivsed kasutajad, üleslaadimistaotluste arv, allalaadimistaotluste arv ja nii edasi. Nõuete täitmiseks moodustasime Kafka klastri, mis loob logid (meie rakenduse loodud) teemasse ja seal on rakendus, mis tarbib teema (kasutades Tarbijat) ja töötleb seda siis vajaliku statistika genereerimiseks ja lõpuks kuvamiseks need, mis on veebilehel.

Kuna inimesed hakkasid meie teenuseid meeldima, hakkasid üha enam inimesed seda kasutama, genereerides tunnis palju logisid. Leidsime, et seda teemat kasutav rakendus muutus äärmiselt aeglaseks, kuna kasutasime ainult ühte Tarbijat. Probleemi lahendamiseks lisasime rühma mõned tarbijad ja leidsime tulemuslikkuse olulist paranemist.

Me sattusime teise nõude juurde, kus pidime logisid HDFS-klastrisse kirjutama ja see protsess peaks toimuma varasema rakendusega sõltumatult (see on tingitud asjaolust, et andmete täiendava suurenemise tõttu plaanisime esimese rakenduse dekomisjoneerida ja kogu statistika tuletada) HDFS-i keskkonnas). Selle nõude täitmiseks töötasime välja teise rakenduse, mis tellis teema, kasutades teist tarbijarühma, ja kirjutas andmed HDFS-i klastrisse.

Soovitatavad artiklid

See on Kafka tarbijarühma juhend. Siin arutleme Kafka tarbijarühma tähtsuse üle ja kuidas Kafka ühendab kahte mudelit koos mõjuga sellele. Lisateabe saamiseks võite vaadata ka järgmisi artikleid -

  1. Kafka rakendused
  2. Kuidas Kafkat installida?
  3. Kafka intervjuu küsimused
  4. HDFS arhitektuur
  5. Kafka tööriistade erinevad tüübid