🥇 Að skilja skilaboðamiðlara. Að læra aflfræði skilaboða með ActiveMQ og Kafka. Kafli 3. Kafka

Framhald á þýðingu lítillar bókar:
Skilningur skilaboðamiðlara
Höfundur: Jakub Korab, útgefandi: O'Reilly Media, Inc., útgáfudagur: júní 2017, ISBN: 9781492049296.

Fyrri þýddur hluti: Að skilja skilaboðamiðlara. Að læra aflfræði skilaboða með ActiveMQ og Kafka. 1. kafli Inngangur

3. KAFLI

Kafka

Kafka var þróað af LinkedIn til að komast framhjá sumum takmörkunum hefðbundinna skilaboðamiðlara og forðast að þurfa að setja upp marga skilaboðamiðlara fyrir mismunandi samskipti milli punkta, sem lýst er í þessari bók undir „Skala upp og minnka“ á blaðsíðu 28 Notkunartilvik LinkedIn hefur að miklu leyti reitt sig á einhliða inntöku á mjög miklu magni af gögnum, svo sem smelli á síðu og aðgangsskrár, en samt sem áður leyft þessi gögn að vera notuð af mörgum kerfum án þess að hafa áhrif á framleiðni framleiðenda eða annarra neytenda. Reyndar er ástæðan fyrir því að Kafka er til að fá þá tegund skilaboðaarkitektúrs sem Universal Data Pipeline lýsir.

Í ljósi þessa lokamarkmiðs komu eðlilega aðrar kröfur. Kafka ætti að:

Vertu mjög fljótur
Veittu meiri bandbreidd þegar þú vinnur með skilaboð
Styðja útgefanda-áskrifandi og punkt-til-punkt módel
Ekki hægja á þér með að bæta við neytendum. Til dæmis minnkar frammistaða bæði biðröðarinnar og efnisins í ActiveMQ eftir því sem neytendum fjölgar á áfangastaðnum.
Vertu skalanlegt lárétt; ef einn miðlari sem heldur áfram skilaboðum getur aðeins gert það á hámarkshraða á disknum, þá er skynsamlegt að fara út fyrir eitt miðlaratilvik til að auka afköst
Takmarkaðu aðgang að því að geyma og endurheimta skilaboð

Til að ná þessu öllu, tók Kafka upp arkitektúr sem endurskilgreindi hlutverk og ábyrgð viðskiptavina og skilaboðamiðlara. JMS líkanið er mjög miðlaramiðað, þar sem miðlarinn ber ábyrgð á að dreifa skilaboðum og viðskiptavinir þurfa aðeins að hafa áhyggjur af því að senda og taka á móti skilaboðum. Kafka er aftur á móti viðskiptavinamiðaður, þar sem viðskiptavinurinn tekur á sig marga eiginleika hefðbundins miðlara, svo sem sanngjarna dreifingu viðeigandi skilaboða til neytenda, í skiptum fyrir mjög hraðvirkan og stigstærðan miðlara. Fyrir fólk sem hefur unnið með hefðbundin skilaboðakerfi þarf að vinna með Kafka grundvallar hugarfarsbreytingu.
Þessi verkfræðistefna hefur leitt til þess að búið er að búa til skilaboðainnviði sem getur aukið afköst um margar stærðargráður miðað við hefðbundna miðlara. Eins og við munum sjá kemur þessi nálgun með málamiðlun, sem þýðir að Kafka hentar ekki fyrir ákveðnar tegundir vinnuálags og uppsetts hugbúnaðar.

Sameinað áfangastaðalíkan

Til að uppfylla þær kröfur sem lýst er hér að ofan, hefur Kafka sameinað birtingar-áskrift og punkt-til-punkt skilaboð undir einni tegund áfangastað − umræðuefni. Þetta er ruglingslegt fyrir fólk sem hefur unnið með skilaboðakerfi, þar sem orðið „efni“ vísar til útsendingarkerfis sem (af efninu) lestur er óþolandi. Kafka efni ættu að teljast blending áfangastaða tegund, eins og skilgreint er í inngangi þessarar bókar.

Það sem eftir er af þessum kafla, nema við tökum sérstaklega fram annað, mun hugtakið "efni" vísa til Kafka efnis.

Til að skilja að fullu hvernig efni hegða sér og hvaða tryggingar þau veita þurfum við fyrst að skoða hvernig þau eru útfærð í Kafka.
Hvert efni í Kafka hefur sína eigin annál.
Framleiðendur sem senda skilaboð til Kafka skrifa í þennan annál og neytendur lesa úr skránni með því að nota ábendingar sem fara stöðugt áfram. Reglulega eyðir Kafka elstu hlutum skrárinnar, hvort sem skilaboðin í þeim hlutum hafa verið lesin eða ekki. Miðlægur hluti af hönnun Kafka er að miðlaranum er alveg sama hvort skilaboð eru lesin eða ekki - það er á ábyrgð viðskiptavinarins.

Hugtökin „log“ og „bendill“ koma ekki fyrir í Kafka skjöl. Þessi vel þekktu hugtök eru notuð hér til að auðvelda skilning.

Þetta líkan er gjörólíkt ActiveMQ, þar sem skilaboð úr öllum biðröðum eru geymd í sama log og miðlari merkir skilaboðin sem eytt eftir að þau hafa verið lesin.
Við skulum nú kafa aðeins dýpra og skoða efnisskrána nánar.
Kafka loginn samanstendur af nokkrum skiptingum (Mynd 3-1). Kafka ábyrgist stranga röðun í hverri skiptingu. Þetta þýðir að skilaboð sem eru skrifuð á skiptinguna í ákveðinni röð verða lesin í sömu röð. Hver skipting er útfærð sem rúllandi annálsskrá sem inniheldur undirmengi (undirmengi) allra skilaboða sem framleiðendur þess sendu til efnisins. Efnið sem búið var til inniheldur sjálfgefið eina skipting. Hugmyndin um skipting er aðalhugmynd Kafka fyrir lárétta mælikvarða.

Mynd 3-1. Kafka skipting

Þegar framleiðandi sendir skilaboð til Kafka efnis ákveður hann hvaða skipting á að senda skilaboðin á. Við munum skoða þetta nánar síðar.

Að lesa skilaboð

Viðskiptavinurinn sem vill lesa skilaboðin stjórnar nafngreindum bendi sem kallaður er neytendahópur, sem bendir til á móti skilaboð í skiptingunni. Offset er stigvaxandi staða sem byrjar á 0 við upphaf skiptingar. Þessi neytendahópur, sem vísað er til í API með notendaskilgreindu group_id, samsvarar einn rökréttur neytandi eða kerfi.

Flest skilaboðakerfi lesa gögn frá áfangastað með því að nota mörg tilvik og þræði til að vinna úr skilaboðum samhliða. Þannig verða yfirleitt mörg neytendatilvik sem deila sama neytendahópnum.

Vandamálið við lestur má tákna sem hér segir:

Efni hefur margar skiptingar
Margir hópar neytenda geta notað efni á sama tíma
Hópur neytenda getur haft mörg aðskilin tilvik

Þetta er ekki léttvægt marga-til-marga vandamál. Til að skilja hvernig Kafka meðhöndlar tengsl milli neytendahópa, neytendatilvika og skiptinga skulum við skoða röð sífellt flóknari lestraratburðarása.

Neytendur og neytendahópar

Tökum sem útgangspunkt efni með einni skipting (Mynd 3-2).

Mynd 3-2. Neytandi les af skilrúmi

Þegar neytendatilvik tengist sínu eigin group_id við þetta efni, er því úthlutað lessneiði og offset í þeirri skipting. Staða þessa offset er stillt í biðlaranum sem bendill á nýjustu stöðu (nýjasta skilaboð) eða elstu stöðu (elstu skilaboð). Neytandinn biður um (kannanir) skilaboð frá efninu, sem veldur því að þau eru lesin í röð úr skránni.
Offset staða er reglulega skuldbundin aftur til Kafka og geymd sem skilaboð í innra efni _neytendajöfnun. Lesnum skilaboðum er enn ekki eytt, ólíkt venjulegum miðlari, og viðskiptavinurinn getur spólað til baka til að endurvinna þegar skoðuð skilaboð.

Þegar annar rökréttur neytandi tengist með öðru group_id, stjórnar hann öðrum bendili sem er óháður þeim fyrsta (Mynd 3-3). Þannig virkar Kafka-efni eins og biðröð þar sem einn neytandi er og eins og venjulegt útgáfu-áskrift (pub-sub) efni sem margir neytendur gerast áskrifendur að, með þeim aukaávinningi að öll skilaboð eru geymd og hægt er að vinna úr þeim margoft.

Mynd 3-3. Tveir neytendur í mismunandi neytendahópum lesa af sama skiptingunni

Neytendur í neytendahópi

Þegar eitt neytendatilvik les gögn úr skipting, hefur það fulla stjórn á bendilinum og vinnur úr skilaboðum eins og lýst er í fyrri hlutanum.
Ef nokkur tilvik neytenda voru tengd með sama group_id við efni með einni skipting, þá mun tilvikið sem tengdist síðast fá stjórn yfir bendilinn og frá því augnabliki mun það fá öll skilaboð (Mynd 3-4).

Mynd 3-4. Tveir neytendur í sama neytendahópi lesa af sama skiptingunni

Líta má á þennan vinnslumáta, þar sem fjöldi neytendatilvika fer yfir fjölda skiptinga, sem eins konar einkaneytanda. Þetta getur verið gagnlegt ef þú þarft "virka-aðgerðalausa" (eða "heitt-heitt") þyrping á neytendatilvikum þínum, þó að keyra marga neytendur samhliða ("virkir-virkir" eða "heitir-heitir") sé mun dæmigerðara en neytendur Í biðstöðu.

Þessi skilaboðadreifingarhegðun sem lýst er hér að ofan getur komið á óvart miðað við hvernig venjuleg JMS biðröð hegðar sér. Í þessu líkani munu skilaboð sem send eru í biðröð dreifast jafnt á milli neytenda tveggja.

Oftast, þegar við búum til mörg dæmi um neytendur, gerum við þetta annað hvort til að vinna skilaboð samhliða, eða til að auka lestrarhraðann eða til að auka stöðugleika í lestrarferlinu. Þar sem aðeins eitt neytendatilvik getur lesið gögn frá skipting í einu, hvernig er þetta náð í Kafka?

Ein leið til að gera þetta er að nota eitt neytendatilvik til að lesa öll skilaboðin og senda þau í þráðasafnið. Þó að þessi nálgun auki vinnsluafköst, eykur hún flókið rökfræði neytenda og gerir ekkert til að auka styrkleika lestrarkerfisins. Ef eitt eintak af neytanda fer niður vegna rafmagnsleysis eða álíka atviks, þá hættir frádrátturinn.

Hin kanóníska leið til að leysa þetta vandamál í Kafka er að nota bОfleiri skipting.

Skipting

Skipting er aðalbúnaðurinn til að samhliða lestri og skala efni umfram bandbreidd eins miðlaratilviks. Til að skilja þetta betur skulum við íhuga aðstæður þar sem það er efni með tveimur skiptingum og einn neytandi gerist áskrifandi að þessu efni (Mynd 3-5).

Mynd 3-5. Einn neytandi les úr mörgum skiptingum

Í þessari atburðarás fær neytandinn stjórn yfir ábendingunum sem samsvara group_id hans í báðum skiptingum og byrjar að lesa skilaboð frá báðum skiptingunum.
Þegar viðbótarneytandi fyrir sama group_id er bætt við þetta efni, endurúthlutar Kafka einum af skiptingunum frá fyrsta til annars neytanda. Eftir það mun hvert tilvik neytenda lesa úr einni skiptingu efnisins (Mynd 3-6).

Til að tryggja að skilaboð séu unnin samhliða í 20 þræði þarftu að minnsta kosti 20 skipting. Ef skiptingarnar eru færri, situr þú eftir með neytendur sem hafa ekkert að vinna í, eins og lýst er fyrr í umfjöllun um einkaneytendur.

Mynd 3-6. Tveir neytendur í sama neytendahópnum lesa úr mismunandi skiptingum

Þetta kerfi dregur mjög úr flækjustigi Kafka miðlarans miðað við skilaboðadreifinguna sem þarf til að viðhalda JMS biðröðinni. Hér þarftu ekki að hafa áhyggjur af eftirfarandi atriðum:

Hvaða neytandi ætti að fá næstu skilaboð, byggt á round-robin úthlutun, núverandi getu forsækjenda biðminni eða fyrri skilaboð (eins og fyrir JMS skilaboðahópa).
Hvaða skilaboð eru send til hvaða neytenda og hvort afhenda eigi þau aftur ef bilun kemur upp.

Það eina sem Kafka miðlarinn þarf að gera er að senda skilaboð í röð til neytandans þegar sá síðarnefndi biður um þau.

Hins vegar hverfa ekki kröfurnar um samhliða prófarkalestur og endursendu misheppnuð skilaboð - ábyrgðin á þeim færist einfaldlega frá miðlara til viðskiptavinar. Þetta þýðir að það verður að taka tillit til þeirra í kóðanum þínum.

Sendi skilaboð

Það er á ábyrgð framleiðanda skilaboðanna að ákveða hvaða skipting á að senda skilaboð til. Til að skilja hvernig þetta er gert þurfum við fyrst að íhuga hvað nákvæmlega við erum að senda.

Þar sem við í JMS notum skilaboðauppbyggingu með lýsigögnum (hausum og eiginleikum) og meginmáli sem inniheldur hleðsluna (álag), í Kafka eru skilaboðin para "lykill-gildi". Skilaboðin eru send sem gildi. Lykillinn er aftur á móti aðallega notaður til skiptingar og verður að innihalda viðskiptarógík sérstakur lykilltil að setja tengd skilaboð í sama skipting.

Í kafla 2 ræddum við atburðarásina fyrir veðmál á netinu þar sem tengdir atburðir þarf að vinna úr í röð af einum neytanda:

Notendareikningurinn er stilltur.
Peningar eru lagðir inn á reikninginn.
Veðmál er gert sem tekur peninga af reikningnum.

Ef hver atburður er skilaboð sem send eru til efnis, þá væri náttúrulykillinn auðkenni reikningsins.
Þegar skilaboð eru send með Kafka Producer API eru þau send til skiptingaraðgerðar sem, miðað við skilaboðin og núverandi stöðu Kafka klasans, skilar auðkenni skiptingarinnar sem skilaboðin á að senda til. Þessi eiginleiki er útfærður í Java í gegnum Partitioner viðmótið.

Þetta viðmót lítur svona út:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

Partitioner útfærslan notar sjálfgefna algóritma fyrir almennan tilgang yfir lykilinn til að ákvarða skiptinguna, eða hringrás ef enginn lykill er tilgreindur. Þetta sjálfgefið gildi virkar vel í flestum tilfellum. Hins vegar í framtíðinni muntu vilja skrifa þitt eigið.

Að skrifa þína eigin skiptingarstefnu

Við skulum skoða dæmi þar sem þú vilt senda lýsigögn ásamt gagnaflutningi skilaboðanna. Álagið í dæminu okkar er leiðbeining um að leggja inn á leikreikninginn. Fyrirmæli er eitthvað sem við viljum að sé tryggt að verði ekki breytt við sendingu og viljum vera viss um að aðeins traust andstreymiskerfi geti hafið þá kennslu. Í þessu tilviki eru sendi- og móttökukerfi sammála um notkun á undirskrift til að auðkenna skilaboðin.
Í venjulegu JMS skilgreinum við einfaldlega „skilaboðundirskrift“ eiginleika og bætum því við skilaboðin. Hins vegar veitir Kafka okkur ekki kerfi til að senda lýsigögn, aðeins lykil og gildi.

Þar sem gildið er bankamillifærsla sem við viljum varðveita, höfum við ekkert val en að skilgreina gagnaskipulagið sem á að nota í lyklinum. Miðað við að við þurfum reikningsauðkenni fyrir skiptingu, þar sem öll skilaboð sem tengjast reikningi verða að vinna í röð, munum við koma með eftirfarandi JSON uppbyggingu:

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

Vegna þess að verðmæti undirskriftarinnar er breytilegt eftir hleðslu, mun sjálfgefin kjötkássaaðferð Partitioner viðmótsins ekki flokka tengd skilaboð á áreiðanlegan hátt. Þess vegna þurfum við að skrifa okkar eigin stefnu sem mun flokka þennan lykil og skipta accountId gildinu.

Kafka inniheldur eftirlitstölur til að greina spillingu skilaboða í versluninni og hefur fullt sett af öryggiseiginleikum. Þrátt fyrir það birtast stundum sérstakar kröfur eins og sú hér að ofan.

Skiptingastefna notandans verður að tryggja að öll tengd skilaboð lendi í sama skiptingunni. Þó að þetta virðist einfalt, getur krafan verið flókin vegna mikilvægis þess að panta tengd skilaboð og hversu fastur fjöldi skiptinga í efni er.

Fjöldi skiptinga í efni getur breyst með tímanum, þar sem þeim er hægt að bæta við ef umferð fer fram úr upphaflegum væntingum. Þannig er hægt að tengja skilaboðalykla við skiptinguna sem þeir voru upphaflega sendir á, sem gefur til kynna að ástandi sé deilt á milli framleiðanda.

Annar þáttur sem þarf að hafa í huga er jöfn dreifing skilaboða milli skiptinga. Venjulega er lyklunum ekki dreift jafnt yfir skilaboð og kjötkássaaðgerðir tryggja ekki sanngjarna dreifingu skilaboða fyrir lítið sett af lyklum.
Það er mikilvægt að hafa í huga að hvernig sem þú velur að skipta skilaboðum gæti þurft að endurnýta skiljuna sjálfa.

Íhugaðu kröfuna um að endurtaka gögn milli Kafka-þyrpinga á mismunandi landfræðilegum stöðum. Í þessu skyni kemur Kafka með skipanalínutól sem kallast MirrorMaker, sem er notað til að lesa skilaboð úr einum klasa og flytja þau yfir í annan.

MirrorMaker verður að skilja lykla afritaðs efnis til að viðhalda hlutfallslegri röð á milli skilaboða þegar endurtekið er á milli klasa, þar sem fjöldi skiptinga fyrir það efni gæti verið ekki sá sami í tveimur klasa.

Sérsniðnar skiptingaraðferðir eru tiltölulega sjaldgæfar, þar sem sjálfgefið hashing eða round robin virkar vel í flestum tilfellum. Hins vegar, ef þú þarfnast sterkrar pöntunarábyrgðar eða þarft að vinna lýsigögn úr hleðslu, þá er skipting eitthvað sem þú ættir að skoða nánar.

Ávinningurinn af sveigjanleika og frammistöðu Kafka kemur frá því að færa hluta af ábyrgð hefðbundins miðlara yfir á viðskiptavininn. Í þessu tilviki er tekin ákvörðun um að dreifa hugsanlegum tengdum skilaboðum meðal nokkurra neytenda sem vinna samhliða.

JMS miðlarar þurfa einnig að takast á við slíkar kröfur. Athyglisvert er að vélbúnaðurinn til að senda tengd skilaboð til sama neytanda, útfærð í gegnum JMS Message Groups (afbrigði af SLB) stefnunni, krefst þess einnig að sendandinn merki skilaboð sem tengd. Þegar um JMS er að ræða er miðlari ábyrgur fyrir því að senda þennan hóp tengdra skilaboða til eins neytanda af mörgum og flytja eignarhald á hópnum ef neytandinn fellur frá.

Framleiðendasamningar

Skipting er ekki það eina sem þarf að hafa í huga þegar þú sendir skilaboð. Við skulum skoða send() aðferðirnar í Producer bekknum í Java API:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

Það skal strax tekið fram að báðar aðferðir skila Future, sem gefur til kynna að sendingaraðgerðin sé ekki framkvæmd strax. Niðurstaðan er sú að skilaboð (ProducerRecord) eru skrifuð í sendingarbuffið fyrir hverja virka skipting og send til miðlarans sem bakgrunnsþráður í Kafka viðskiptavinasafninu. Þó að þetta geri hlutina ótrúlega hratt þýðir það að óreynt forrit getur tapað skilaboðum ef ferli þess er stöðvað.

Eins og alltaf er leið til að gera sendingaraðgerðina áreiðanlegri á kostnað af frammistöðu. Hægt er að stilla stærð þessa biðminni á 0 og umsóknarþráðurinn sem sendir neyðist til að bíða þar til skilaboðaflutningi til miðlara er lokið, eins og hér segir:

RecordMetadata metadata = producer.send(record).get();

Meira um að lesa skilaboð

Lestur skilaboða hefur fleiri margbreytileika sem þarf að velta fyrir sér. Ólíkt JMS API, sem getur keyrt skilaboðahlustara sem svar við skilaboðum Consumer Kafka aðeins skoðanakannanir. Við skulum skoða aðferðina nánar skoðanakönnun()notað í þessu skyni:

ConsumerRecords < K, V > poll(long timeout);

Skilagildi aðferðarinnar er gámabygging sem inniheldur marga hluti neytendaskrá frá hugsanlega nokkrum skiptingum. neytendaskrá er sjálft handhafahlutur fyrir lykilgilda par með tilheyrandi lýsigögnum, eins og skiptingunni sem það er dregið af.

Eins og fjallað er um í kafla 2, verðum við að hafa í huga hvað verður um skeyti eftir að þau hafa verið tekin eða árangurslaus vinnsla, til dæmis ef viðskiptavinurinn getur ekki unnið úr skilaboðunum eða ef það hættir við það. Í JMS var þetta meðhöndlað í gegnum viðurkenningarham. Miðlarinn mun annaðhvort eyða skilaboðunum sem tókst að vinna úr, eða afhenda hráu eða fölsuðu skilaboðin aftur (að því gefnu að viðskipti hafi verið notuð).
Kafka virkar allt öðruvísi. Skilaboðum er ekki eytt í miðlara eftir prófarkalestur og það sem gerist við bilun er á ábyrgð prófarkalesturskóðans sjálfs.

Eins og við höfum sagt er neytendahópurinn tengdur við mótvægið í skránni. Logstaðan sem tengist þessari frávik samsvarar næstu skilaboðum sem gefin verða út sem svar við skoðanakönnun(). Það er afgerandi fyrir lesturinn hvenær þessi frávik eykst.

Þegar farið er aftur að lestrarlíkaninu sem fjallað var um áðan samanstendur vinnsla skilaboða af þremur stigum:

Sæktu skilaboð til að lesa.
Vinndu skilaboðin.
Staðfestu skilaboð.

Kafka neytandinn kemur með stillingarmöguleika enable.auto.commit. Þetta er oft notuð sjálfgefin stilling, eins og algengt er með stillingar sem innihalda orðið „sjálfvirk“.

Fyrir Kafka 0.10 myndi viðskiptavinur sem notar þennan valmöguleika senda jöfnun síðustu skilaboða sem lesin voru í næsta símtali skoðanakönnun() eftir vinnslu. Þetta þýddi að hægt væri að endurvinna öll skilaboð sem þegar höfðu verið sótt ef viðskiptavinurinn hafði þegar unnið úr þeim en var óvænt eytt áður en hann hringdi skoðanakönnun(). Vegna þess að miðlarinn heldur ekki upp neinu ástandi um hversu oft skilaboð hafa verið lesin, mun næsti neytandi sem sækir þau skilaboð ekki vita að neitt slæmt gerðist. Þessi hegðun var gervi-viðskipti. Jöfnunin var aðeins framin ef tekist var að vinna úr skilaboðunum, en ef viðskiptavinurinn hætti við myndi miðlarinn senda sömu skilaboðin aftur til annars viðskiptavinar. Þessi hegðun var í samræmi við skilaboðasendingarábyrgð "að minnsta kosti einu sinni".

Í Kafka 0.10 hefur biðlarakóðanum verið breytt þannig að commit er ræst reglulega af biðlarasafninu, eins og það er stillt auto.commit.interval.ms. Þessi hegðun er einhvers staðar á milli JMS AUTO_ACKNOWLEDGE og DUPS_OK_ACKNOWLEDGE stillinganna. Þegar verið er að nota sjálfvirka skuldbindingu gætu skilaboð verið framkvæmd óháð því hvort þau voru raunverulega unnin - þetta gæti gerst ef um hægan neytanda er að ræða. Ef neytandi hættir við, myndu næsti neytandi sækja skilaboð, og byrja á þeim stað sem hann hefur ákveðið, sem gæti leitt til þess að skeyti gleymist. Í þessu tilfelli tapaði Kafka ekki skilaboðunum, leskóðinn vann þau bara ekki.

Þessi háttur hefur sama loforð og í útgáfu 0.9: hægt er að vinna úr skilaboðum, en ef það mistekst er hugsanlegt að ekki sé framkvæmt á móti, sem gæti valdið því að afhending verði tvöfölduð. Því fleiri skilaboð sem þú sækir þegar þú keyrir skoðanakönnun(), því meira sem þetta vandamál.

Eins og fjallað er um í „Lesa skilaboð úr biðröð“ á blaðsíðu 21, er ekkert til sem heitir einskiptisskilaboð í skilaboðakerfi þegar bilunarhamir eru teknir með í reikninginn.

Í Kafka eru tvær leiðir til að fremja (framkvæma) offset (offset): sjálfkrafa og handvirkt. Í báðum tilfellum er hægt að vinna skilaboð margsinnis ef skilaboðin voru unnin en mistókst fyrir framsetningu. Þú getur líka valið að vinna ekki úr skilaboðunum ef commitið átti sér stað í bakgrunni og kóðanum þínum var lokið áður en hægt var að vinna úr honum (kannski í Kafka 0.9 og eldri).

Þú getur stjórnað handvirku offset commit ferlinu í Kafka neytenda API með því að stilla færibreytuna enable.auto.commit að rangt og beinlínis kalla eina af eftirfarandi aðferðum:

void commitSync();
void commitAsync();

Ef þú vilt vinna úr skilaboðunum "að minnsta kosti einu sinni" verður þú að fremja offsetið handvirkt með commitSync()með því að framkvæma þessa skipun strax eftir vinnslu skilaboðanna.

Þessar aðferðir leyfa ekki að skilaboð séu samþykkt áður en þau eru unnin, en þær gera ekkert til að koma í veg fyrir hugsanlegar vinnslutafir á sama tíma og þær virðast vera viðskiptalegar. Það eru engin viðskipti í Kafka. Viðskiptavinurinn hefur ekki getu til að gera eftirfarandi:

Snúðu fölsuðum skilaboðum sjálfkrafa til baka. Neytendur verða sjálfir að sjá um undantekningar sem stafa af erfiðum hleðslu og stöðvunarstöðvun, þar sem þeir geta ekki reitt sig á miðlara til að koma skilaboðum aftur til skila.
Sendu skilaboð til margra viðfangsefna í einni atómaðgerð. Eins og við munum sjá fljótlega getur stjórn á mismunandi efni og skiptingum verið á mismunandi vélum í Kafka þyrpingunni sem samræma ekki viðskipti þegar þau eru send. Þegar þetta er skrifað hefur verið unnið að því að gera þetta mögulegt með KIP-98.
Tengdu það að lesa eitt skilaboð úr einu efni við að senda önnur skilaboð í annað efni. Aftur er Kafka arkitektúrinn háður því að margar sjálfstæðar vélar gangi sem ein rúta og engin tilraun er gerð til að fela þetta. Til dæmis eru engir API íhlutir sem gera þér kleift að tengja neytenda и Leikstjóri í viðskiptum. Í JMS er þetta veitt af hlutnum Sessionsem eru búnar til Skilaboðaframleiðendur и Skilaboð Neytendur.

Ef við getum ekki reitt okkur á viðskipti, hvernig getum við veitt merkingarfræði nær þeim sem hefðbundin skilaboðakerfi bjóða upp á?

Ef möguleiki er á að neytendajöfnun aukist áður en búið er að afgreiða skilaboðin, svo sem við neytendahrun, þá hefur neytandinn enga möguleika á að vita hvort neytendahópur hans hafi misst af skilaboðunum þegar honum er úthlutað skipting. Þannig að ein stefna er að spóla offsetinu til baka í fyrri stöðu. Kafka neytendaforritið býður upp á eftirfarandi aðferðir fyrir þetta:

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

Aðferð leita() hægt að nota með aðferð
offsetsForTimes(Map timestampsToSearch) að spóla til baka í ástand á einhverjum tilteknum tímapunkti í fortíðinni.

Óbeint þýðir það að nota þessa nálgun að það er mjög líklegt að sum skilaboð sem áður voru unnin verði lesin og unnin aftur. Til að forðast þetta, getum við notað vanmáttugan lestur, eins og lýst er í kafla 4, til að halda utan um áður skoðuð skilaboð og koma í veg fyrir tvítekningar.

Að öðrum kosti er hægt að halda neytendakóðanum þínum einföldum, svo framarlega sem skeyti tapast eða fjölföldun er ásættanleg. Þegar við íhugum notkunartilvik sem Kafka er almennt notaður fyrir, eins og meðhöndlun atburða í annálum, mæligildum, smellamælingu o.s.frv., skiljum við að tap einstakra skilaboða er ólíklegt að það hafi veruleg áhrif á nærliggjandi forrit. Í slíkum tilvikum eru sjálfgefin gildi fullkomlega ásættanleg. Hins vegar, ef umsókn þín þarf að senda greiðslur, verður þú að gæta vandlega að hverju einstöku skeyti. Þetta kemur allt niður á samhengi.

Persónulegar athuganir sýna að eftir því sem styrkleiki skilaboða eykst minnkar gildi hvers einstaks skilaboða. Stór skilaboð hafa tilhneigingu til að vera verðmæt þegar þau eru skoðuð í samanteknu formi.

Mikið framboð

Nálgun Kafka að miklu aðgengi er mjög frábrugðin nálgun ActiveMQ. Kafka er hannað í kringum stækkaða klasa þar sem öll miðlaratilvik taka á móti og dreifa skilaboðum á sama tíma.

Kafka þyrping samanstendur af mörgum miðlaratilvikum sem keyra á mismunandi netþjónum. Kafka var hannað til að keyra á venjulegum sjálfstæðum vélbúnaði, þar sem hver hnút hefur sína sérstaka geymslu. Ekki er mælt með notkun nettengingar geymslu (SAN) vegna þess að margir reiknihnútar geta keppt um tíma.Ыe geymslubil og skapa árekstra.

Kafka er alltaf á kerfi. Margir stórir Kafka notendur leggja aldrei niður klasana sína og hugbúnaðurinn uppfærist alltaf með endurræsingu í röð. Þetta er náð með því að tryggja samhæfni við fyrri útgáfu fyrir skilaboð og samskipti milli miðlara.

Miðlari tengdur við netþjónaklasa Dýragarðsvörður, sem virkar sem stillingargagnaskrá og er notuð til að samræma hlutverk hvers miðlara. ZooKeeper sjálft er dreifð kerfi sem veitir mikið aðgengi í gegnum afritun upplýsinga með því að koma á fót ályktun.

Í grunntilvikinu er efni búið til í Kafka klasa með eftirfarandi eiginleikum:

Fjöldi skiptinga. Eins og áður hefur komið fram fer nákvæmlega gildið sem er notað hér eftir því hvaða stigi samhliða lestrar er æskilegt.
Afritunarstuðullinn (stuðullinn) ákvarðar hversu mörg miðlaratilvik í klasanum ættu að innihalda annála fyrir þessa skiptingu.

Með því að nota ZooKeepers til samhæfingar reynir Kafka að dreifa nýjum skiptingum á sanngjarnan hátt meðal miðlara í klasanum. Þetta er gert af einu tilviki sem virkar sem stjórnandi.

Á keyrslutíma fyrir hverja umræðuþætti Stjórnandi úthluta hlutverkum til miðlara leiðtogi (leiðtogi, meistari, kynnir) og fylgjendur (fylgjendur, þrælar, undirmenn). Miðlarinn, sem er leiðtogi þessarar skiptingar, ber ábyrgð á að taka á móti öllum skilaboðum sem framleiðendur senda honum og dreifa skilaboðunum til neytenda. Þegar skilaboð eru send á efnishluti eru þau afrituð til allra miðlarahnúta sem starfa sem fylgjendur fyrir þá skiptingu. Hver hnútur sem inniheldur logs fyrir skipting er kallaður eftirmynd. Miðlari getur virkað sem leiðtogi fyrir sum skipting og sem fylgismaður fyrir aðra.

Hringt er í fylgismann sem inniheldur öll skilaboð í vörslu leiðtogans samstillt eftirmynd (eftirmynd sem er í samstilltu ástandi, in-sync eftirmynd). Ef miðlari sem starfar sem leiðtogi fyrir skipting fellur niður, getur hvaða miðlari sem er uppfærður eða samstilltur fyrir þá skiptingu tekið við leiðtogahlutverkinu. Það er ótrúlega sjálfbær hönnun.

Hluti af uppsetningu framleiðanda er færibreytan akks, sem ákvarðar hversu margar eftirmyndir verða að staðfesta (viðurkenna) móttöku skilaboða áður en forritaþráðurinn heldur áfram að senda: 0, 1 eða allt. Ef stillt er á allt, þegar skilaboð eru móttekin mun leiðtoginn senda staðfestingu til baka til framleiðandans um leið og hann fær staðfestingar (viðurkenningar) á færslunni frá nokkrum vísbendingum (þar á meðal honum sjálfum) sem eru skilgreindar af efnisstillingunni mín.insync.eftirmyndir (sjálfgefið 1). Ef ekki er hægt að endurtaka skilaboðin, mun framleiðandinn kasta undanþágu frá forriti (NotEnoughReplicas eða NotEnoughReplicasAfterAppend).

Dæmigerð uppsetning býr til umræðuefni með afritunarstuðlinum 3 (1 leiðtogi, 2 fylgjendur á hverja skiptingu) og færibreytu mín.insync.eftirmyndir er stillt á 2. Í þessu tilviki mun þyrpingin leyfa einum miðlara sem stjórnar umræðuþættinum að fara niður án þess að hafa áhrif á forrit viðskiptavina.

Þetta færir okkur aftur að þegar kunnuglega skiptingunni milli frammistöðu og áreiðanleika. Afritun á sér stað á kostnað viðbótarbiðtíma eftir staðfestingum (viðurkenningum) frá fylgjendum. Þó, vegna þess að það keyrir samhliða, hefur afritun á að minnsta kosti þrjá hnúta sömu afköst og tveir (að hunsað aukningu á netbandbreiddarnotkun).

Með því að nota þetta afritunarkerfi forðast Kafka snjall þörfina á að skrifa hvert skeyti líkamlega á diskinn með aðgerðinni samstilla(). Hvert skeyti sem framleiðandinn sendir verður skrifað í skiptingarskrána, en eins og fjallað er um í kafla 2 er ritun á skrá upphaflega gerð í biðminni stýrikerfisins. Ef þessi skilaboð eru afrituð í annað Kafka-tilvik og eru í minni þess þýðir tap leiðtogans ekki að skilaboðin sjálf hafi glatast - það getur verið yfirtekið af samstilltri eftirmynd.
Neitun um að framkvæma aðgerðina samstilla() þýðir að Kafka getur tekið á móti skilaboðum eins hratt og hann getur skrifað þau í minnið. Aftur á móti, því lengur sem þú getur forðast að skola minni yfir á disk, því betra. Af þessum sökum er ekki óalgengt að Kafka miðlari fái úthlutað 64 GB eða meira af minni. Þessi minnisnotkun þýðir að eitt Kafka tilvik getur auðveldlega keyrt á mörgum þúsundum sinnum hraðari hraða en hefðbundinn skilaboðamiðlari.

Kafka er einnig hægt að stilla til að beita aðgerðinni samstilla() til að senda skilaboð um pakka. Þar sem allt í Kafka er pakkamiðað, virkar það í raun nokkuð vel fyrir mörg notkunartilvik og er gagnlegt tæki fyrir notendur sem þurfa mjög sterkar tryggingar. Mikið af hreinni frammistöðu Kafka kemur frá skilaboðunum sem eru send til miðlarans sem pakkar og að þessi skilaboð eru lesin frá miðlaranum í röðum með því að nota núll eintak aðgerðir (aðgerðir þar sem það verkefni að afrita gögn frá einu minnissvæði til annars er ekki framkvæmt). Hið síðarnefnda er mikill árangur og auðlindaaukning og er aðeins möguleg með því að nota undirliggjandi loggagnaskipulag sem skilgreinir skiptingarkerfið.

Miklu betri árangur er mögulegur í Kafka-þyrpingum en með einum Kafka-miðlara, vegna þess að efnisskiptingar geta stækkað yfir margar aðskildar vélar.

Niðurstöður

Í þessum kafla skoðuðum við hvernig Kafka arkitektúrinn endurmyndar tengslin milli viðskiptavina og miðlara til að veita ótrúlega öfluga skilaboðaleiðslu, með afköst margfalt meiri en hefðbundins skilaboðamiðlara. Við höfum rætt virknina sem það notar til að ná þessu og skoðað stuttlega arkitektúr forrita sem veita þessa virkni. Í næsta kafla ætlum við að skoða algeng vandamál sem skilaboðamiðuð forrit þurfa að leysa og ræða aðferðir til að takast á við þau. Við endum kaflann með því að útlista hvernig á að tala um skilaboðatækni almennt svo þú getir metið hæfi þeirra fyrir notkunartilvikin þín.

Fyrri þýddur hluti: Að skilja skilaboðamiðlara. Að læra aflfræði skilaboða með ActiveMQ og Kafka. Kafli 1

Þýðing lokið: tele.gg/middle_java

Til að halda áfram ...

Aðeins skráðir notendur geta tekið þátt í könnuninni. Skráðu þig inn, takk.

Er Kafka notað í fyrirtækinu þínu?

Já
No
Áður notað, nú ekki
Við ætlum að nota

38 notendur kusu. 8 notendur sátu hjá.

Heimild: www.habr.com

Að skilja skilaboðamiðlara. Að læra aflfræði skilaboða með ActiveMQ og Kafka. Kafli 3. Kafka