В síðasta greinin við skoðuðum RabbitMQ þyrpinguna fyrir bilanaþol og mikið framboð. Nú skulum við kafa djúpt í Apache Kafka.

Hér er afritunareiningin skiptingin. Hvert efni hefur einn eða fleiri kafla. Hver hluti hefur leiðtoga með eða án fylgjenda. Þegar efni er búið til tilgreinirðu fjölda skiptinga og afritunarstuðul. Venjulegt gildi er 3, sem þýðir þrjár eftirmyndir: einn leiðtogi og tveir fylgjendur.

Hrísgrjón. 1. Fjórum hlutum er dreift á þrjá miðlara

Allar lestrar- og skrifbeiðnir fara til leiðtogans. Fylgjendur senda reglulega beiðnir til leiðtogans um að fá nýjustu skilaboðin. Neytendur snúa sér aldrei til fylgjenda; þeir síðarnefndu eru aðeins til vegna offramboðs og bilanaþols.

Skipting bilun

Þegar miðlari mistakast, mistakast leiðtogar nokkurra hluta oft. Í hverju þeirra verður fylgjendur frá öðrum hnút leiðtogi. Reyndar er þetta ekki alltaf raunin, þar sem samstillingarþátturinn hefur einnig áhrif: hvort það eru samstilltir fylgjendur, og ef ekki, þá hvort skipta yfir í ósamstillta eftirmynd sé leyfilegt. En við skulum ekki flækja málin í bili.

Miðlari 3 yfirgefur netið og nýr leiðtogi er kjörinn fyrir hluta 2 hjá miðlara 2.

Hrísgrjón. 2. Miðlari 3 deyr og fylgismaður hans á miðlara 2 er kjörinn nýr leiðtogi 2.

Þá fer miðlari 1 og hluti 1 missir einnig leiðtoga sinn, en hlutverk hans fer yfir til miðlara 2.

Hrísgrjón. 3. Það er einn miðlari eftir. Allir leiðtogar eru á einum miðlara með núll offramboð

Þegar miðlari 1 kemur aftur á netið bætir hann við fjórum fylgjendum, sem veitir einhverja offramboð á hverja skiptingu. En allir leiðtogarnir voru samt áfram á miðlara 2.

Hrísgrjón. 4. Leiðtogar eru áfram í miðlara 2

Þegar miðlari 3 kemur upp erum við aftur komin í þrjár eftirmyndir á hverri skiptingu. En allir leiðtogarnir eru enn á miðlara 2.

Hrísgrjón. 5. Ójafnvægi staðsetning leiðtoga eftir endurreisn miðlara 1 og 3

Kafka er með tæki til að ná betri jafnvægi á leiðtoga en RabbitMQ. Þar þurftir þú að nota þriðja aðila viðbót eða skriftu sem breytti reglunum fyrir flutning aðalhnútsins með því að draga úr offramboði við flutning. Þar að auki, fyrir stórar biðraðir, þurftum við að sætta okkur við óaðgengi meðan á samstillingu stóð.

Kafka hefur hugmyndina um „valin eftirmynd“ fyrir leiðtogahlutverkið. Þegar efnisskiptingar eru búnar til reynir Kafka að dreifa leiðtogum jafnt yfir hnúta og merkir þá fyrstu leiðtoga sem ákjósanlegasta. Með tímanum, vegna endurræsingar á netþjóni, bilana og bilana í tengingum, geta leiðtogar endað á öðrum hnútum, eins og í öfgatilvikinu sem lýst er hér að ofan.

Til að laga þetta býður Kafka upp á tvo valkosti:

• Valkostur auto.leader.rebalance.enable=true gerir stjórnandahnútnum kleift að endurúthluta leiðtogum sjálfkrafa aftur í æskilegar eftirmyndir og endurheimta þar með samræmda dreifingu.
• Kerfisstjórinn getur keyrt skriftuna kafka-preferred-replica-election.sh til handvirkrar endurúthlutunar.

Hrísgrjón. 6. Eftirlíkingar eftir endurjafnvægi

Þetta var einfölduð útgáfa af biluninni, en raunveruleikinn er flóknari, þó ekkert sé of flókið hér. Það kemur allt niður á samstilltum eftirmyndum (In-Sync eftirlíkingar, ISR).

Samstilltar eftirmyndir (ISR)

ISR er sett af eftirlíkingum af skipting sem er talin „samstillt“ (samstillt). Það er leiðtogi, en það eru kannski ekki fylgjendur. Fylgismaður telst samstilltur ef hann hefur gert nákvæmar afrit af öllum skilaboðum leiðtogans áður en tímabilið rennur út eftirmynd.töf.tími.max.ms.

Fylgismaður er fjarlægður úr ISR settinu ef það:

• bað ekki um að velja fyrir tímabilið eftirmynd.töf.tími.max.ms (talið er látinn)
• náði ekki að uppfæra á tímabilinu eftirmynd.töf.tími.max.ms (talið hægt)

Fylgjendur gera úrtaksbeiðnir á millibili eftirmynd.fetch.wait.max.ms, sem sjálfgefið er 500ms.

Til að skýra tilgang ISR skýrt þurfum við að skoða staðfestingar frá framleiðanda og nokkrar bilunaratburðarásir. Framleiðendur geta valið hvenær miðlari sendir staðfestingu:

• acks=0, staðfesting er ekki send
• acks=1, staðfesting er send eftir að leiðtogi hefur skrifað skilaboð í staðbundinn dagbók sína
• acks=all, staðfesting er send eftir að allar eftirmyndir í ISR hafa skrifað skilaboðin í staðbundna logga

Í Kafka hugtökum, ef ISR hefur vistað skilaboð, er það „skuldbundið“. Acks=all er öruggasti kosturinn, en bætir einnig við viðbótartöf. Við skulum skoða tvö dæmi um bilun og hvernig hinir mismunandi „acks“ valkostir hafa samskipti við ISR hugtakið.

Acks=1 og ISR

Í þessu dæmi munum við sjá að ef leiðtoginn bíður ekki eftir að öll skilaboð frá öllum fylgjendum séu vistuð, þá er gagnatap mögulegt ef leiðtoginn mistekst. Hægt er að virkja eða slökkva á því að fletta að ósamstilltum fylgjenda með því að stilla óhreinn.leiðtogi.kosningar.

Í þessu dæmi hefur framleiðandinn gildið acks=1. Hlutinn er dreift á alla þrjá miðlarana. Miðlari 3 er á eftir, hann samstilltist við leiðtogann fyrir átta sekúndum og er nú 7456 skilaboðum á eftir. Miðlari 1 var aðeins einni sekúndu á eftir. Framleiðandinn okkar sendir skilaboð og fær fljótt viðtökur til baka, án kostnaðar af hægum eða dauðum fylgjendum sem leiðtoginn bíður ekki eftir.

Hrísgrjón. 7. ISR með þremur eftirmyndum

Miðlari 2 mistekst og framleiðandinn fær tengingarvillu. Eftir að forysta fer til miðlara 1, töpum við 123 skilaboðum. Fylgismaðurinn á miðlara 1 var hluti af ISR, en var ekki fullkomlega samstilltur við leiðtogann þegar hann féll.

Hrísgrjón. 8. Skilaboð glatast þegar það hrynur

Í stillingu bootstrap.servers Framleiðandinn hefur nokkra miðlara skráða og getur spurt annan miðlara hver er nýr leiðtogi deildarinnar. Það kemur síðan á tengingu við miðlara 1 og heldur áfram að senda skilaboð.

Hrísgrjón. 9. Sending skilaboða hefst aftur eftir stutt hlé

Miðlari 3 er enn lengra á eftir. Það gerir niðurhalsbeiðnir en getur ekki samstillt. Þetta getur verið vegna hægrar nettengingar milli miðlara, geymsluvandamála osfrv. Það er fjarlægt úr ISR. Nú samanstendur ISR af einni eftirmynd - leiðtoganum! Framleiðandinn heldur áfram að senda skilaboð og fá staðfestingar.

Hrísgrjón. 10. Fylgismaður á miðlara 3 er fjarlægður úr ISR

Miðlari 1 fer niður og leiðtogahlutverkið fer til miðlara 3 með tap á 15286 skilaboðum! Framleiðandinn fær villuboð um tengingu. Umskiptin í leiðtoga utan ISR var aðeins möguleg vegna umgjörðarinnar unclean.leader.election.enable=sannur. Ef það er sett upp í rangar, þá myndu umskiptin ekki eiga sér stað og öllum les- og skrifbeiðnum yrði hafnað. Í þessu tilviki bíðum við eftir því að miðlari 1 komi aftur með ósnortin gögn sín í eftirmyndinni, sem mun aftur taka við forystunni.

Hrísgrjón. 11. Miðlari 1 fellur. Þegar bilun kemur upp tapast mikill fjöldi skilaboða

Framleiðandinn kemur á tengslum við síðasta miðlarann ​​og sér að hann er nú leiðtogi hlutans. Hann byrjar að senda skilaboð til miðlara 3.

Hrísgrjón. 12. Eftir stutt hlé eru skilaboð send aftur í lið 0

Við sáum að, fyrir utan stuttar truflanir til að koma á nýjum tengingum og leita að nýjum leiðtoga, var framleiðandinn stöðugt að senda skilaboð. Þessi uppsetning tryggir aðgengi á kostnað samkvæmni (gagnaöryggi). Kafka tapaði þúsundum skilaboða en hélt áfram að taka við nýjum skrifum.

Acks=allt og ISR

Við skulum endurtaka þessa atburðarás aftur, en með acks=allt. Miðlari 3 hefur að meðaltali fjórar sekúndur. Framleiðandinn sendir skilaboð með acks=allt, og fær nú ekki skjót viðbrögð. Leiðtoginn bíður eftir að skilaboðin verði vistuð af öllum eftirmyndum í ISR.

Hrísgrjón. 13. ISR með þremur eftirmyndum. Einn er hægur, sem veldur töfum á upptöku

Eftir fjögurra sekúndna viðbótartöf sendir miðlari 2 kvittun. Allar eftirlíkingar eru nú að fullu uppfærðar.

Hrísgrjón. 14. Allar eftirlíkingar vista skilaboð og senda ack

Miðlari 3 fellur nú lengra á eftir og er fjarlægður úr ISR. Seinkun minnkar verulega vegna þess að engar hægar eftirmyndir eru eftir í ISR. Miðlari 2 bíður nú aðeins eftir miðlara 1 og hann hefur að meðaltali 500 ms töf.

Hrísgrjón. 15. Eftirmyndin á miðlara 3 er fjarlægð úr ISR

Þá fellur miðlari 2 og forysta fer til miðlara 1 án þess að skeyti tapist.

Hrísgrjón. 16. Miðlari 2 fellur

Framleiðandinn finnur nýjan leiðtoga og byrjar að senda honum skilaboð. Töfin minnkar enn frekar vegna þess að ISR samanstendur nú af einni eftirmynd! Því kosturinn acks=allt bætir ekki við offramboði.

Hrísgrjón. 17. Eftirmynd á miðlara 1 tekur forystuna án þess að tapa skilaboðum

Þá hrynur miðlari 1 og forskotið fer til miðlara 3 með tap á 14238 skilaboðum!

Hrísgrjón. 18. Miðlari 1 deyr og leiðtogaskipti með óhreinum stillingum leiða til mikils gagnataps

Við gátum ekki sett upp valkostinn óhreinn.leiðtogi.kosningar í merkingu satt. Sjálfgefið er það jafnt rangar. Stillingar acks=allt с unclean.leader.election.enable=sannur veitir aðgengi með auknu gagnaöryggi. En eins og þú sérð getum við samt tapað skilaboðum.

En hvað ef við viljum auka gagnaöryggi? Þú getur sett unclean.leader.election.enable = rangt, en þetta mun ekki endilega vernda okkur gegn gagnatapi. Ef leiðtoginn féll hart og tók gögnin með sér, þá eru skilaboð enn týnd, auk þess sem framboð glatast þar til stjórnandi endurheimtir ástandið.

Það er betra að tryggja að öll skilaboð séu óþörf og farga upptökunni að öðrum kosti. Þá, að minnsta kosti frá sjónarhóli miðlarans, er gagnatap aðeins mögulegt ef tvær eða fleiri bilanir eru samtímis.

Acks=all, min.insync.replicas og ISR

Með efnisstillingu mín.insync.eftirmyndir Við erum að auka gagnaöryggisstigið. Við skulum fara í gegnum síðasta hluta fyrri atburðarásarinnar aftur, en í þetta sinn með min.insync.replicas=2.

Þannig að miðlari 2 hefur eftirmyndarleiðtoga og fylgismaður á miðlara 3 er fjarlægður úr ISR.

Hrísgrjón. 19. ISR úr tveimur eftirlíkingum

Miðlari 2 fellur og forysta fer til miðlara 1 án þess að skeyti tapist. En nú samanstendur ISR aðeins af einni eftirmynd. Þetta uppfyllir ekki lágmarksfjölda til að fá færslur og því svarar miðlari skriftilrauninni með villu NotEnoughReplicas.

Hrísgrjón. 20. Fjöldi ISR ​​er einum lægri en tilgreint er í min.insync.replicas

Þessi uppsetning fórnar framboði fyrir samræmi. Áður en við staðfestum skilaboð, tryggjum við að það sé skrifað á að minnsta kosti tvær eftirmyndir. Þetta gefur framleiðanda miklu meira sjálfstraust. Hér er skilaboðatap aðeins mögulegt ef tvær eftirmyndir mistakast samtímis á stuttu millibili þar til skilaboðin eru afrituð til viðbótarfylgjenda, sem er ólíklegt. En ef þú ert ofsóknaræðislegur geturðu stillt afritunarstuðulinn á 5, og mín.insync.eftirmyndir fyrir 3. Hér verða þrír miðlarar að falla á sama tíma til að tapa metinu! Auðvitað borgar þú fyrir þennan áreiðanleika í viðbótar töf.

Þegar aðgengi er nauðsynlegt vegna gagnaöryggis

Eins og í málið með RabbitMQ, stundum er aðgengi nauðsynlegt fyrir gagnaöryggi. Hér er það sem þú þarft að hugsa um:

• Getur útgefandinn einfaldlega skilað villu og látið andstreymisþjónustuna eða notandann reyna aftur síðar?
• Getur útgefandinn vistað skilaboðin á staðnum eða í gagnagrunni til að reyna aftur síðar?

Ef svarið er nei, þá bætir hagræðing aðgengi gagnaöryggi. Þú munt tapa minni gögnum ef þú velur framboð í stað þess að taka ekki upp. Þannig snýst allt um að finna jafnvægi og ákvörðunin fer eftir aðstæðum.

Merking ISR

ISR föruneytið gerir þér kleift að velja besta jafnvægið milli gagnaöryggis og leynd. Til dæmis, tryggja aðgengi ef bilun á meirihluta eftirmynda, lágmarka áhrif dauðra eða hægra eftirmynda hvað varðar leynd.

Við veljum merkinguna sjálf eftirmynd.töf.tími.max.ms í samræmi við þarfir þínar. Í meginatriðum þýðir þessi færibreyta hversu mikla töf við erum tilbúin að samþykkja hvenær acks=allt. Sjálfgefið gildi er tíu sekúndur. Ef þetta er of langt fyrir þig geturðu minnkað það. Þá mun tíðni breytinga á ISR aukast, þar sem fylgjendur verða fjarlægðir og bætt við oftar.

RabbitMQ er einfaldlega sett af speglum sem þarf að endurtaka. Hægir speglar kynna frekari leynd og dauðir speglar geta beðið þar til pakkarnir sem athuga framboð hvers hnúts (net tick) svara. ISR er áhugaverð leið til að forðast þessi leynd vandamál. En við hættum því að missa offramboð þar sem ISR getur aðeins minnkað til leiðtogans. Til að forðast þessa áhættu skaltu nota stillinguna mín.insync.eftirmyndir.

Ábyrgð á tengingu viðskiptavina

Í stillingum bootstrap.servers framleiðandi og neytandi geta tilgreint marga miðlara til að tengja saman viðskiptavini. Hugmyndin er sú að þegar einn hnút fer niður, þá eru nokkrir varahlutir eftir sem viðskiptavinurinn getur opnað tengingu við. Þetta eru ekki endilega deildarstjórar, heldur einfaldlega stökkpallur fyrir upphafshleðslu. Viðskiptavinurinn getur spurt þá hvaða hnút hýsir les/skrifa skiptingarleiðtogann.

Í RabbitMQ geta viðskiptavinir tengst hvaða hnút sem er og innri leið sendir beiðnina þangað sem hún þarf að fara. Þetta þýðir að þú getur sett upp álagsjafnara fyrir framan RabbitMQ. Kafka krefst þess að viðskiptavinir tengist hnútnum sem hýsir samsvarandi skiptingarleiðtoga. Í slíkum aðstæðum geturðu ekki sett upp álagsjafnara. Listi bootstrap.servers Það er mikilvægt að viðskiptavinir geti nálgast og fundið rétta hnúta eftir bilun.

Kafka Consensus Architecture

Hingað til höfum við ekki íhugað hvernig klasinn lærir um fall miðlarans og hvernig nýr leiðtogi er kjörinn. Til að skilja hvernig Kafka vinnur með netskiptingum þarftu fyrst að skilja samstöðuarkitektúrinn.

Hver Kafka þyrping er sett á laggirnar ásamt Zookeeper þyrpingu, sem er dreifð samstöðuþjónusta sem gerir kerfinu kleift að ná samstöðu um tiltekið ástand og forgangsraða samræmi fram yfir framboð. Samþykki meirihluta dýraverndarhnúta þarf til að samþykkja lestrar- og ritaðgerðir.

Zookeeper geymir ástand klasans:

• Listi yfir efni, hluta, uppsetningu, núverandi eftirmyndir leiðtoga, eftirmyndir sem valin er.
• Klasameðlimir. Hver miðlari smellir dýraverndarklasanum. Ef það fær ekki ping innan tiltekins tíma, þá skráir Zookeeper miðlarann ​​sem ótiltækan.
• Að velja aðal- og varahnúta fyrir stjórnandann.

Stjórnandi hnúturinn er einn af Kafka miðlarunum sem bera ábyrgð á að velja eftirmyndarleiðtoga. Zookeeper sendir tilkynningar til stjórnanda um klasaaðild og efnisbreytingar og verður stjórnandi að bregðast við þessum breytingum.

Til dæmis, við skulum taka nýtt efni með tíu skiptingum og afritunarstuðlinum 3. Stjórnandinn verður að velja leiðtoga fyrir hverja skiptingu og reyna að dreifa leiðtogum sem best á milli miðlara.

Fyrir hvern hlutastýringu:

• uppfærir upplýsingar í Zookeeper um ISR og leiðtoga;
• Sendir LeaderAndISRCommand til hvers miðlara sem hýsir eftirmynd af þessari skiptingu, upplýsir miðlara um ISR og leiðtogann.

Þegar miðlari með leiðtoga fellur, sendir Zookeeper tilkynningu til stjórnandans og hann velur nýjan leiðtoga. Aftur, stjórnandinn uppfærir Zookeeper fyrst og sendir síðan skipun til hvers miðlara sem tilkynnir þeim um leiðtogabreytinguna.

Hver leiðtogi ber ábyrgð á ráðningu ISRs. Stillingar eftirmynd.töf.tími.max.ms ákvarðar hverjir fara þangað inn. Þegar ISR breytist sendir leiðtoginn nýjar upplýsingar til Zookeeper.

Dýragarðsvörður er alltaf upplýstur um allar breytingar þannig að ef bilun kemur upp fer stjórnendur snurðulaust yfir í nýjan leiðtoga.

Hrísgrjón. 21. Kafka Samstaða

Afritunarreglur

Skilningur á smáatriðum afritunar hjálpar þér að skilja betur hugsanleg gagnatap.

Sýnatökufyrirspurnir, Log End Offset (LEO) og Highwater Mark (HW)

Við litum svo á að fylgjendur sendu söfnunarbeiðnir reglulega til leiðtogans. Sjálfgefið bil er 500ms. Þetta er frábrugðið RabbitMQ að því leyti að í RabbitMQ er afritun ekki hafin af biðraðarspeglinum heldur af skipstjóranum. Húsbóndinn ýtir á breytingar á speglunum.

Leiðtoginn og allir fylgjendur vista Log End Offset (LEO) og Highwater (HW) merkið. LEO merkið geymir offset síðasta skeytisins í staðbundnu eftirmyndinni og HW heldur offsetinu á síðustu skuldbindingunni. Mundu að fyrir skuldbindingarstöðu verða skilaboðin að vera viðvarandi í öllum ISR eftirlíkingum. Þetta þýðir að LEO er venjulega aðeins á undan HW.

Þegar leiðtoginn fær skilaboð geymir hann þau á staðnum. Fylgjandinn leggur fram beiðni um að sækja með því að senda LEO sinn. Leiðtoginn sendir síðan hóp af skilaboðum sem byrja á þessu LEO og sendir einnig núverandi HW. Þegar leiðtoginn fær upplýsingar um að allar eftirmyndir hafi geymt skilaboðin á tilteknu móti færir hann HW merkið. Aðeins leiðtoginn getur fært HW, og því munu allir fylgjendur vita núverandi gildi í svörum við beiðni þeirra. Þetta þýðir að fylgjendur geta verið á eftir leiðtoganum í bæði skilaboðum og HW þekkingu. Neytendur fá aðeins skilaboð upp að núverandi HW.

Athugaðu að "viðvarandi" þýðir skrifað í minni, ekki á disk. Fyrir frammistöðu samstillir Kafka við diskinn með ákveðnu millibili. RabbitMQ hefur líka slíkt bil, en það mun senda staðfestingu til útgefanda aðeins eftir að meistarinn og allir speglar hafa skrifað skilaboðin á diskinn. Kafka verktaki, af frammistöðu ástæðum, ákváðu að senda ack um leið og skilaboðin eru skrifuð í minnið. Kafka veðja á að offramboð vegur upp á móti hættunni á að geyma viðurkennd skilaboð í stutta stund eingöngu í minni.

Leiðtogi bilun

Þegar leiðtogi dettur lætur Zookeeper stjórnandann vita og hann velur nýja eftirmynd leiðtoga. Nýi leiðtoginn setur nýtt HW merki samkvæmt LEO hans. Fylgjendur fá síðan upplýsingar um nýja leiðtogann. Það fer eftir útgáfu Kafka, fylgjendur mun velja eina af tveimur atburðarásum:

1. Það mun stytta staðbundinn annál til þekkts HW og senda beiðni til nýja leiðtogans um skilaboð eftir þetta merki.
2. Mun senda beiðni til leiðtogans um að finna út HW á þeim tíma sem hann var kjörinn leiðtogi, og stytta síðan logginn í þessa mótvægi. Það mun þá byrja að gera reglubundnar sóttarbeiðnir sem byrja á þessari jöfnun.

Fylgismaður gæti þurft að stytta skrána af eftirfarandi ástæðum:

• Þegar leiðtogi mistakast vinnur fyrsti fylgismaðurinn í ISR settinu sem er skráður hjá Zookeeper kosningarnar og verður leiðtogi. Allir fylgjendur á ISR, þó þeir séu taldir „samstilltir“, hafa kannski ekki fengið afrit af öllum skilaboðum frá fyrrverandi leiðtoga. Það er alveg mögulegt að fylgjendur sem er sýndur hafi ekki nýjasta eintakið. Kafka tryggir að enginn munur sé á eftirmyndum. Þannig, til að forðast misræmi, verður hver fylgismaður að stytta logg sinn við HW gildi nýja leiðtogans þegar hann er kosinn. Þetta er önnur ástæða fyrir því að setja acks=allt svo mikilvægt fyrir samræmi.
• Skilaboð eru reglulega skrifuð á disk. Ef allir klasahnútar bila á sama tíma verða eftirlíkingar með mismunandi frávik geymdar á diskunum. Hugsanlegt er að þegar miðlarar koma aftur á netið muni nýi leiðtoginn sem er kjörinn vera á bak við fylgjendur sína vegna þess að hann var vistaður á disk á undan hinum.

Endurfundir með klasanum

Þegar þeir sameinast aftur í þyrpingunni, gera eftirlíkingarnar það sama og þegar leiðtogi mistakast: þær athuga eftirmynd leiðtogans og stytta logg sinn við HW hans (við kosningar). Til samanburðar lítur RabbitMQ jafnt á sameinaða hnúta sem alveg nýja. Í báðum tilfellum fleygir miðlarinn hvaða ríki sem er til staðar. Ef sjálfvirk samstilling er notuð, þá verður skipstjórinn að endurtaka algerlega allt núverandi efni í nýja spegilinn með „látum allan heiminn bíða“ aðferð. Skipstjórinn samþykkir engar les- eða skrifaðgerðir meðan á þessari aðgerð stendur. Þessi nálgun skapar vandamál í stórum biðröðum.

Kafka er dreifður log og almennt geymir hann fleiri skilaboð en RabbitMQ biðröð, þar sem gögn eru fjarlægð úr biðröðinni eftir að þau eru lesin. Virkar biðraðir ættu að vera tiltölulega litlar. En Kafka er annál með eigin varðveislustefnu, sem getur stillt daga eða vikur. Biðraðirlokun og full samstillingaraðferð er algerlega óviðunandi fyrir dreifðan annál. Þess í stað stytta fylgjendur Kafka einfaldlega færslubókina sína til HW leiðtogans (þegar hann er kosinn) ef eintak þeirra er á undan leiðtoganum. Í líklegra tilvikinu, þegar fylgjendur er á eftir, byrjar hann einfaldlega að sækja beiðnir frá núverandi LEO.

Nýir eða skráðir fylgjendur byrja utan ISR og taka ekki þátt í skuldbindingum. Þeir vinna einfaldlega við hlið hópsins og fá skilaboð eins fljótt og þeir geta þar til þeir ná leiðtoganum og fara inn í ISR. Það er engin læsing og engin þörf á að henda öllum gögnum þínum.

Tap á tengingu

Kafka hefur fleiri íhluti en RabbitMQ, svo það hefur flóknari hegðun þegar þyrpingin verður aftengd. En Kafka var upphaflega hannaður fyrir klasa, þannig að lausnirnar eru mjög vel ígrundaðar.

Hér að neðan eru nokkrar tengingarbilanir:

• Atburðarás 1: Fylgismaðurinn sér ekki leiðtogann, en sér samt dýragarðsvörðinn.
• Sviðsmynd 2: Leiðtoginn sér enga fylgjendur, en sér samt Zookeeper.
• Atburðarás 3: Fylgismaðurinn sér leiðtogann, en sér ekki dýragarðsvörðinn.
• Atburðarás 4: Leiðtoginn sér fylgjendurna en sér ekki dýragarðsvörðinn.
• Atburðarás 5: Fylgismaðurinn er algjörlega aðskilinn frá bæði öðrum Kafka hnútum og Zookeeper.
• Atburðarás 6: Leiðtoginn er algjörlega aðskilinn frá bæði öðrum Kafka hnútum og dýragarðsverði.
• Atburðarás 7: Kafka stjórnandi hnúturinn getur ekki séð annan Kafka hnút.
• Atburðarás 8: Kafka stjórnandi sér ekki Zookeeper.

Hver atburðarás hefur sína eigin hegðun.

Atburðarás 1: Fylgismaður sér ekki leiðtogann, en sér samt Zookeeper

Hrísgrjón. 22. Sviðsmynd 1: ISR af þremur eftirmyndum

Tengingarbilunin skilur miðlara 3 frá miðlara 1 og 2, en ekki frá Zookeeper. Miðlari 3 getur ekki lengur sent niðurhalsbeiðnir. Eftir að tíminn er liðinn eftirmynd.töf.tími.max.ms það er fjarlægt úr ISR og tekur ekki þátt í skilaboðum. Þegar tengingin hefur verið endurheimt mun hún halda áfram að sækja beiðnir og ganga til liðs við ISR þegar það nær leiðtoganum. Zookeeper mun halda áfram að fá ping og ganga út frá því að miðlarinn sé á lífi og heill.

Hrísgrjón. 23. Atburðarás 1: Miðlari er fjarlægður úr ISR ef engin sóttbeiðni berst frá honum innan eftirmyndar.lag.time.max.ms bilsins

Það er engin heila- eða hnútfjöðrun eins og í RabbitMQ. Þess í stað minnkar offramboð.

Sviðsmynd 2: Leiðtogi sér enga fylgjendur, en sér samt Zookeeper

Hrísgrjón. 24. Sviðsmynd 2. Leiðtogi og tveir fylgjendur

Bilun í nettengingu skilur leiðtogann frá fylgjendum, en miðlarinn getur samt séð Zookeeper. Eins og í fyrstu atburðarásinni minnkar ISR, en í þetta skiptið aðeins til leiðtogans þar sem allir fylgjendur hætta að senda niðurhalsbeiðnir. Aftur, það er engin rökrétt skipting. Þess í stað missir offramboð fyrir ný skilaboð þar til tenging er endurheimt. Zookeeper heldur áfram að fá ping og telur að miðlarinn sé á lífi.

Hrísgrjón. 25. Sviðsmynd 2. ISR hefur aðeins minnkað til leiðtogans

Atburðarás 3. Fylgismaður sér leiðtogann, en sér ekki dýragarðsvörðinn

Fylgismaðurinn er aðskilinn frá Zookeeper, en ekki frá miðlaranum með leiðtoganum. Þess vegna heldur fylgjendur áfram að sækja beiðnir og vera meðlimur ISR. Zookeeper fær ekki lengur ping og skráir hrun milli miðlara, en þar sem það er aðeins fylgjendur hafa engar afleiðingar eftir bata.

Hrísgrjón. 26. Atburðarás 3: Fylgjandinn heldur áfram að senda söfnunarbeiðnir til leiðtogans

Atburðarás 4. Leiðtogi sér fylgjendur, en sér ekki Zookeeper

Hrísgrjón. 27. Sviðsmynd 4. Leiðtogi og tveir fylgjendur

Leiðtoginn er aðskilinn frá Zookeeper, en ekki frá miðlarum með fylgjendur.

Hrísgrjón. 28. Sviðsmynd 4: Leiðtogi einangraður frá Zookeeper

Eftir nokkurn tíma mun Zookeeper skrá bilun í miðlara og láta stjórnanda vita um það. Hann mun velja nýjan leiðtoga meðal fylgjenda sinna. Hins vegar mun upphaflegi leiðtoginn halda áfram að halda að hann sé leiðtoginn og mun halda áfram að taka við færslum frá acks=1. Fylgjendur eru ekki lengur að senda honum beiðnir um að sækja, svo hann mun líta á þær sem dauða og reyna að minnka ISR til sjálfs sín. En þar sem það hefur ekki tengingu við Zookeeper mun það ekki geta gert þetta og á þeim tímapunkti mun það neita að taka við frekari færslum.

Сообщения acks=allt mun ekki fá staðfestingu vegna þess að ISR kveikir fyrst á öllum eftirmyndum og skilaboð berast þeim ekki. Þegar upphaflegi leiðtoginn reynir að fjarlægja þá úr ISR mun hann ekki geta það og hættir að samþykkja öll skilaboð.

Viðskiptavinir taka fljótlega eftir breytingunni á leiðtoga og byrja að senda færslur á nýja netþjóninn. Þegar netið hefur verið endurheimt sér upphafsleiðtoginn að hann er ekki lengur leiðtogi og styttir logg sinn í HW gildið sem nýi leiðtoginn hafði þegar ekki tókst að koma í veg fyrir mismun á loga. Það mun þá byrja að senda niðurhalsbeiðnir til nýja leiðtogans. Allar skrár frá upprunalega leiðtoganum sem eru ekki endurteknar til nýja leiðtogans glatast. Það er að segja að skilaboð sem upphaflega leiðtoginn samþykkti ekki á þessum örfáu sekúndum þegar tveir leiðtogar voru að störfum munu glatast.

Hrísgrjón. 29. Atburðarás 4. Leiðtoginn á miðlara 1 verður fylgismaður eftir að netið er endurheimt

Atburðarás 5: Fylgismaðurinn er algjörlega aðskilinn frá bæði öðrum Kafka hnútum og Zookeeper

Fylgismaðurinn er algjörlega einangraður frá bæði öðrum Kafka hnútum og Zookeeper. Hann einfaldlega fjarlægir sig frá ISR þar til netið er endurheimt, og þá nær hann hinum.

Hrísgrjón. 30. Atburðarás 5: Einangraður fylgismaður er fjarlægður úr ISR

Atburðarás 6: Leiðtoginn er algjörlega aðskilinn frá bæði öðrum Kafka hnútum og dýragarðsverði

Hrísgrjón. 31. Sviðsmynd 6. Leiðtogi og tveir fylgjendur

Leiðtoginn er algjörlega einangraður frá fylgjendum sínum, stjórnandanum og dýragarðsverðinum. Í stuttan tíma mun það halda áfram að taka við færslum frá acks=1.

Hrísgrjón. 32. Atburðarás 6: Að einangra leiðtogann frá öðrum Kafka og Zookeeper hnútum

Að hafa ekki fengið beiðnir eftir gildistíma eftirmynd.töf.tími.max.ms, það mun reyna að minnka ISR til sjálfs sín, en mun ekki geta gert það vegna þess að það er engin samskipti við Zookeeper, þá mun það hætta að samþykkja skrif.

Á meðan mun Zookeeper merkja einangraðan miðlara sem látinn og stjórnandinn mun velja nýjan leiðtoga.

Hrísgrjón. 33. Sviðsmynd 6. Tveir leiðtogar

Upphaflegi leiðtoginn getur samþykkt færslur í nokkrar sekúndur, en hættir síðan að samþykkja skilaboð. Viðskiptavinir eru uppfærðir á 60 sekúndna fresti með nýjustu lýsigögnum. Þeir verða upplýstir um leiðtogaskiptin og munu byrja að senda færslur til nýja leiðtogans.

Hrísgrjón. 34. Sviðsmynd 6: Framleiðendur skipta yfir í nýjan leiðtoga

Allar staðfestar færslur sem upphaflega leiðtoginn hefur gert frá því að tengingin var rofin munu glatast. Þegar netið er endurreist mun upphaflegi leiðtoginn uppgötva í gegnum Zookeeper að hann er ekki lengur leiðtoginn. Þá mun það stytta skráningu sína til HW nýja leiðtogans þegar kosið er og byrja að senda beiðnir sem fylgismaður.

Hrísgrjón. 35. Atburðarás 6: Uppruni leiðtoginn verður fylgismaður eftir að nettenging er endurheimt

Í þessu ástandi getur rökrétt aðskilnaður átt sér stað í stuttan tíma, en aðeins ef acks=1 и mín.insync.eftirmyndir einnig 1. Rökréttur aðskilnaður endar sjálfkrafa annað hvort eftir að netið er endurreist, þegar upphaflegi leiðtoginn áttar sig á því að hann er ekki lengur leiðtogi, eða þegar allir viðskiptavinir átta sig á því að leiðtoginn hefur breyst og byrja að skrifa til nýja leiðtogans - hvort sem gerist fyrst. Í öllum tilvikum munu einhver skilaboð glatast, en aðeins með acks=1.

Það er annað afbrigði af þessari atburðarás þar sem, rétt áður en netið klofnaði, féllu fylgjendur á eftir og leiðtoginn þjappaði ISR ​​saman við sjálfan sig. Það verður þá einangrað vegna taps á tengingu. Nýr leiðtogi er kjörinn, en upphaflegi leiðtoginn heldur áfram að taka við færslum, jafnvel acks=allt, því það er enginn annar í ISR nema hann. Þessar skrár munu glatast þegar netið er endurheimt. Eina leiðin til að forðast þennan valkost er min.insync.eftermyndir = 2.

Atburðarás 7: Kafka stjórnandi hnútur getur ekki séð annan Kafka hnút

Almennt séð, þegar tengingin við Kafka-hnút rofnar, mun stjórnandinn ekki geta sent neinar upplýsingar um leiðtogabreytingar til hans. Í versta falli mun þetta leiða til skammtíma rökræns aðskilnaðar eins og í atburðarás 6. Oftar en ekki mun miðlarinn einfaldlega ekki verða leiðtogaframbjóðandi ef sá síðarnefndi mistekst.

Atburðarás 8: Kafka stjórnandi sér ekki Zookeeper

Zookeeper mun ekki fá ping frá hinum fallna stjórnanda og mun velja nýjan Kafka hnút sem stjórnanda. Upprunalega stjórnandinn getur haldið áfram að kynna sig sem slíkan, en hann fær ekki tilkynningar frá Zookeeper, þannig að hann mun ekki hafa nein verkefni til að framkvæma. Þegar netið er endurreist mun hann átta sig á því að hann er ekki lengur stjórnandi heldur er hann orðinn venjulegur Kafka-hnútur.

Ályktanir úr sviðsmyndum

Við sjáum að tap á tengingu fylgismanna hefur ekki í för með sér tap á skilaboðum, heldur dregur einfaldlega úr offramboði tímabundið þar til netið er endurheimt. Þetta getur auðvitað leitt til taps á gögnum ef einn eða fleiri hnútar glatast.

Ef leiðtoginn verður aðskilinn frá Zookeeper vegna tengingarleysis gæti það leitt til þess að skilaboð glatast frá acks=1. Skortur á samskiptum við Zookeeper veldur stuttum rökréttum klofningi við leiðtogana tvo. Þetta vandamál er leyst með breytu acks=allt.

Viðfang mín.insync.eftirmyndir í tvær eða fleiri eftirmyndir veitir viðbótartryggingu fyrir því að slíkar skammtímaatburðarásir muni ekki leiða til glataðra skilaboða eins og í sviðsmynd 6.

Yfirlit yfir týnd skilaboð

Við skulum lista allar leiðirnar sem þú getur tapað gögnum í Kafka:

• Öll leiðtogabilun ef skilaboð voru staðfest með því að nota acks=1
• Öll óhrein umskipti leiðtoga, það er að fylgja utan ISR, jafnvel með acks=allt
• Að einangra leiðtogann frá Zookeeper ef skilaboð voru staðfest með því að nota acks=1
• Algjör einangrun leiðtogans sem hefur þegar minnkað ISR hópinn niður til sín. Öll skilaboð munu glatast, jafnvel acks=allt. Þetta er aðeins satt ef min.insync.replicas=1.
• Samtímis bilanir í öllum skiptingarhnútum. Vegna þess að skilaboð eru samþykkt úr minni er ekki víst að sum séu enn skrifuð á disk. Eftir að netþjónarnir hafa verið endurræstir gætu sum skilaboð vantað.

Hægt er að forðast óhreina leiðtogaskipti með því annað hvort að banna þau eða tryggja að minnsta kosti tvær uppsagnir. Varanlegasta uppsetningin er samsetning acks=allt и mín.insync.eftirmyndir yfir 1.

Beinn samanburður á áreiðanleika RabbitMQ og Kafka

Til að tryggja áreiðanleika og mikið aðgengi, innleiða báðir pallarnir aðal- og aukaafritunarkerfi. Hins vegar er RabbitMQ með akkillesarhæll. Þegar tengst er aftur eftir bilun, fleygja hnútar gögnum sínum og samstillingin er læst. Þetta tvöfalda vesen dregur í efa langlífi stórra biðraða í RabbitMQ. Þú verður annaðhvort að sætta þig við minnkaða offramboð eða langan lokunartíma. Að draga úr offramboði eykur hættuna á miklu gagnatapi. En ef biðraðirnar eru litlar, þá er hægt að takast á við stutt tímabil þar sem ekki er tiltækt (nokkrar sekúndur) með því að nota endurteknar tengingartilraunir vegna offramboðs.

Kafka á ekki við þetta vandamál að stríða. Það fleygir aðeins gögnum frá þeim stað þar sem leiðtogi og fylgismaður er ólíkur. Öll sameiginleg gögn eru vistuð. Að auki lokar afritun ekki kerfinu. Leiðtoginn heldur áfram að samþykkja færslur á meðan nýi fylgjendurinn nær upp á sig, þannig að fyrir devops verður aðild að eða aftur í þyrpinguna léttvægt verkefni. Auðvitað eru enn vandamál eins og netbandbreidd meðan á afritun stendur. Ef þú bætir við mörgum fylgjendum á sama tíma gætirðu lent í takmörkun á bandbreidd.

RabbitMQ er betri en Kafka í áreiðanleika þegar margir netþjónar í þyrpingu bila á sama tíma. Eins og við höfum þegar sagt, sendir RabbitMQ staðfestingu til útgefandans aðeins eftir að skilaboðin eru skrifuð á diskinn af meistaranum og öllum speglum. En þetta bætir við frekari leynd af tveimur ástæðum:

• fsync á nokkurra hundruð millisekúndna fresti
• Aðeins er hægt að taka eftir bilun í speglinum eftir að endingartími pakka sem athuga framboð hvers hnúts (nettikk) er útrunninn. Ef spegillinn hægir á sér eða dettur bætir þetta við seinkun.

Kafkas veðmál er að ef skilaboð eru geymd á mörgum hnútum getur það viðurkennt skilaboð um leið og þau lenda í minni. Vegna þessa er hætta á að skeyti af einhverju tagi glatist (jafnvel acks=allt, min.insync.replicas=2) ef bilun er samtímis.

Á heildina litið sýnir Kafka betri hugbúnaðarframmistöðu og er hannaður frá grunni fyrir klasa. Hægt er að fjölga fylgjendum í 11 ef þörf krefur fyrir áreiðanleika. Afritunarstuðull 5 og lágmarksfjöldi afrita í samstillingu min.insync.replicas=3 mun gera skeytimissi að mjög sjaldgæfum atburði. Ef innviðir þínir geta stutt þetta afritunarhlutfall og umframmagn, þá geturðu valið þennan valkost.

RabbitMQ þyrping er góð fyrir litlar biðraðir. En jafnvel litlar biðraðir geta vaxið hratt þegar mikil umferð er. Þegar biðraðir verða stórar þarftu að taka erfiðar ákvarðanir á milli framboðs og áreiðanleika. RabbitMQ þyrping hentar best fyrir óvenjulegar aðstæður þar sem ávinningurinn af sveigjanleika RabbitMQ vegur þyngra en ókostir þyrpingarinnar.

Eitt móteitur gegn varnarleysi RabbitMQ fyrir stórum biðröðum er að skipta þeim upp í margar smærri biðraðir. Ef þú krefst ekki fullrar pöntunar á allri biðröðinni, heldur aðeins viðeigandi skilaboða (til dæmis skilaboð frá tilteknum viðskiptavin), eða pantar ekki neitt, þá er þessi valkostur ásættanlegt: skoðaðu verkefnið mitt Endurjafnvægi að skipta biðröðinni (verkefnið er enn á frumstigi).

Að lokum, ekki gleyma fjölda galla í þyrpingum og afritunaraðferðum bæði RabbitMQ og Kafka. Með tímanum hafa kerfin orðið þroskaðari og stöðugri, en engin skilaboð verða nokkurn tíma 100% örugg fyrir tapi! Auk þess verða stórslys í gagnaverum!

Ef ég missti af einhverju, gerði mistök eða þú ert ósammála einhverjum punktum, ekki hika við að skrifa athugasemd eða hafa samband við mig.

Ég er oft spurður: "Hvað á að velja, Kafka eða RabbitMQ?", "Hvaða vettvangur er betri?". Sannleikurinn er sá að það fer mjög eftir aðstæðum þínum, núverandi reynslu osfrv. Ég er hikandi við að gefa álit mitt því það væri of mikil einföldun að mæla með einum vettvangi fyrir öll notkunartilvik og hugsanlegar takmarkanir. Ég skrifaði þessa greinaröð svo þú getir myndað þína eigin skoðun.

Ég vil meina að bæði kerfin séu leiðandi á þessu sviði. Ég gæti verið svolítið hlutdræg vegna þess að af reynslu minni af verkefnum hef ég tilhneigingu til að meta hluti eins og tryggða röð skilaboða og áreiðanleika.

Ég sé aðra tækni sem skortir þennan áreiðanleika og tryggða röðun, þá lít ég á RabbitMQ og Kafka og átta mig á ótrúlegu gildi beggja þessara kerfa.

Heimild: www.habr.com