Bilanaþol og mikið framboð eru stór efni, svo við munum verja aðskildum greinum RabbitMQ og Kafka. Þessi grein er um RabbitMQ, og sú næsta er um Kafka, í samanburði við RabbitMQ. Þetta er löng grein, svo láttu þér líða vel.
Við skulum líta á bilanaþol, samkvæmni og háan framboð (HA) aðferðir og málamiðlanir sem hver stefna gerir. RabbitMQ getur keyrt á þyrping hnúta - og er þá flokkað sem dreifð kerfi. Þegar kemur að dreifðum kerfum er oft talað um samræmi og framboð.
Þessi hugtök lýsa því hvernig kerfi hegðar sér þegar það bilar. Bilun í nettengingu, bilun á netþjóni, bilun á harða disknum, tímabundið óaðgengi á netþjóni vegna sorpsöfnunar, pakkataps eða hægja á nettengingu. Allt þetta getur leitt til gagnataps eða árekstra. Það kemur í ljós að það er nánast ómögulegt að setja upp kerfi sem er bæði fullkomlega samkvæmt (ekkert gagnatap, engin gagnamunur) og tiltækt (mun taka við lestri og skrifum) fyrir allar bilunaratburðarásir.
Við munum sjá að samkvæmni og framboð eru á gagnstæðum endum litrófsins og þú þarft að velja hvaða leið þú vilt hagræða. Góðu fréttirnar eru þær að með RabbitMQ er þetta val mögulegt. Þú hefur svona „nörda“ stangir til að færa jafnvægið í átt að meiri samkvæmni eða meira aðgengi.
Við munum fylgjast sérstaklega með því hvaða stillingar leiða til gagnataps vegna staðfestra gagna. Það er keðja ábyrgðar á milli útgefenda, miðlara og neytenda. Þegar skilaboðin hafa verið send til miðlara er það hans hlutverk að missa ekki skilaboðin. Þegar miðlari viðurkennir móttöku útgefanda á skeytinu, gerum við ekki ráð fyrir að það glatist. En við munum sjá að þetta getur raunverulega gerst eftir uppsetningu miðlara og útgefanda.
Einn hnútur seiglu frumstæður
Seigur í biðröð/leiðsögn
Það eru tvær tegundir af biðröðum í RabbitMQ: endingargóðar og óvaranlegar. Allar biðraðir eru vistaðar í Mnesia gagnagrunninum. Varanlegar biðraðir eru auglýstar aftur við ræsingu hnúta og lifa þannig af endurræsingar, kerfishrun eða netþjónahrun (svo lengi sem gögnin eru viðvarandi). Þetta þýðir að svo lengi sem þú lýsir því yfir að leið (skipti) og biðröð séu seigur, mun biðröð/leiðarinnviðir koma aftur á netið.
Óstöðugar biðraðir og leið eru fjarlægðar þegar hnúturinn er endurræstur.
Viðvarandi skilaboð
Þó að biðröð sé varanleg þýðir það ekki að öll skilaboð hennar muni lifa af endurræsingu hnúts. Aðeins skilaboð sem útgefandi hefur stillt sem sjálfbær (viðvarandi). Viðvarandi skilaboð skapa aukið álag á miðlara, en ef skilaboðatap er óviðunandi, þá er enginn annar valkostur.
Hrísgrjón. 1. Sjálfbærni fylki
Klustun með biðröðspeglun
Til að lifa af tap miðlara þurfum við offramboð. Við getum sameinað marga RabbitMQ hnúta í þyrping og síðan bætt við viðbótar offramboði með því að endurtaka biðraðir á milli margra hnúta. Þannig, ef einn hnút mistekst, týnum við ekki gögnum og erum áfram tiltæk.
Biðraðarspeglun:
- ein aðalröð (master), sem tekur við öllum skrif- og lesskipunum
- einn eða fleiri speglar sem taka við öllum skilaboðum og lýsigögnum úr aðalröðinni. Þessir speglar eru ekki til staðar fyrir mælikvarða, heldur eingöngu fyrir offramboð.
Hrísgrjón. 2. Biðröð speglun
Speglun er sett af viðeigandi stefnu. Í henni er hægt að velja afritunarstuðulinn og jafnvel hnútana sem biðröðin á að vera á. Dæmi:
ha-mode: allha-mode: exactly, ha-params: 2(einn meistari og einn spegill)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
Staðfesting útgefanda
Til að ná stöðugri upptöku þarf útgefanda staðfestingu. Án þeirra er hætta á að skilaboð glatist. Staðfesting er send til útgefanda eftir að skilaboðin eru skrifuð á diskinn. RabbitMQ skrifar skilaboð á diskinn ekki við móttöku, heldur með reglulegu millibili, á bilinu nokkur hundruð millisekúndur. Þegar biðröð er speglað er staðfesting send aðeins eftir að allir speglar hafa einnig skrifað afrit sitt af skilaboðunum á diskinn. Þetta þýðir að notkun staðfestinga bætir við leynd, en ef gagnaöryggi er mikilvægt, þá eru þær nauðsynlegar.
Bilunarröð
Þegar miðlari hættir eða hrynur hrynja allir biðraðir (meistarar) á þeim hnút ásamt honum. Klasinn velur síðan elsta spegil hvers meistara og kynnir hann sem nýjan meistara.
Hrísgrjón. 3. Margar speglaðar biðraðir og reglur þeirra
Miðlari 3 fellur. Athugaðu að biðröð C spegillinn á Broker 2 er gerður að meistara. Athugaðu einnig að nýr spegill hefur verið búinn til fyrir biðröð C á miðlara 1. RabbitMQ reynir alltaf að viðhalda afritunarstuðlinum sem tilgreindur er í reglum þínum.
Hrísgrjón. 4. Miðlari 3 mistekst, sem veldur því að biðröð C bilar
Næsti miðlari 1 fellur! Við eigum aðeins einn miðlara eftir. Biðröð B spegillinn er gerður að meistara.
Fig. 5
Við höfum skilað miðlara 1. Óháð því hversu vel gögnin lifa af tap og endurheimt miðlarans, er öllum spegluðum biðröð skilaboðum hent við endurræsingu. Þetta er mikilvægt að hafa í huga vegna þess að það mun hafa afleiðingar. Við munum skoða þessar afleiðingar fljótlega. Þannig að miðlari 1 er nú aftur meðlimur í klasanum og klasinn reynir að fara að reglum og býr því til spegla á miðlara 1.
Í þessu tilviki var tap á miðlara 1 algjörlega, sem og gögnin, þannig að óspeglað biðröð B var algjörlega týnd.
Hrísgrjón. 6. Miðlari 1 kemur aftur í þjónustu
Miðlari 3 er aftur á netinu, svo biðraðir A og B fá til baka speglana sem eru búnir til á honum til að uppfylla HA stefnur þeirra. En nú eru allar helstu biðraðir á einum hnút! Þetta er ekki tilvalið, jöfn dreifing milli hnúta er betri. Því miður, það eru ekki margir möguleikar hér fyrir endurjafnvægi meistara. Við munum koma aftur að þessu máli síðar vegna þess að við þurfum að skoða samstillingu biðraða fyrst.
Hrísgrjón. 7. Miðlari 3 kemur aftur í þjónustu. Allar helstu biðraðir á einum hnút!
Svo nú ættir þú að hafa hugmynd um hvernig speglar veita offramboð og bilanaþol. Þetta tryggir aðgengi ef einn hnút bilar og verndar gegn tapi gagna. En við erum ekki búnir enn, því í raun og veru er þetta miklu flóknara.
Samstilling
Þegar nýr spegil er búinn til verða öll ný skilaboð alltaf afrituð í þennan spegil og önnur. Hvað varðar núverandi gögn í aðalröðinni, getum við endurtekið þau í nýjan spegil, sem verður að fullu afriti af masternum. Við getum líka valið að endurtaka ekki núverandi skilaboð og láta aðalröðina og nýja spegilinn renna saman í tíma, þar sem ný skilaboð berast í skottið og núverandi skilaboð fara í höfuðið á aðalröðinni.
Þessi samstilling er framkvæmd sjálfkrafa eða handvirkt og er stjórnað með því að nota biðraðarstefnu. Við skulum líta á dæmi.
Við erum með tvær speglaðar biðraðir. Biðröð A er samstillt sjálfkrafa og biðröð B er samstillt handvirkt. Báðar biðraðir innihalda tíu skilaboð.
Hrísgrjón. 8. Tvær biðraðir með mismunandi samstillingarstillingum
Nú erum við að tapa Broker 3.
Hrísgrjón. 9. Miðlari 3 féll
Miðlari 3 kemur aftur í þjónustu. Klasinn býr til spegil fyrir hverja biðröð á nýja hnútnum og samstillir sjálfkrafa nýju biðröð A við skipstjórann. Hins vegar er spegillinn í nýju biðröð B enn tómur. Þannig höfum við fulla offramboð á biðröð A og aðeins einn spegil fyrir núverandi biðröð B skilaboð.
Hrísgrjón. 10. Nýi spegill biðröð A tekur við öllum fyrirliggjandi skilaboðum, en nýi spegill biðröð B gerir það ekki.
Tíu skilaboð til viðbótar berast í báðar biðraðir. Broker 2 hrynur síðan og biðröð A rúllar aftur í elsta spegilinn, sem er á Broker 1. Það er ekkert gagnatap þegar það bilar. Í biðröð B eru tuttugu skilaboð í masternum og aðeins tíu í speglinum vegna þess að þessi biðröð endurtók aldrei upprunalegu tíu skilaboðin.
Hrísgrjón. 11. Biðröð A rennur aftur til miðlara 1 án þess að tapa skilaboðum
Tíu skilaboð til viðbótar berast í báðar biðraðir. Nú hrynur miðlari 1. Biðröð A skiptir auðveldlega yfir í spegilinn án þess að tapa skilaboðum. Hins vegar er biðröð B í vandræðum. Á þessum tímapunkti getum við fínstillt annað hvort framboð eða samkvæmni.
Ef við viljum hagræða aðgengi, þá er stefnan ha-efla-á-bilun ætti að vera sett upp í alltaf. Þetta er sjálfgefið gildi, svo þú getur einfaldlega alls ekki tilgreint stefnuna. Í þessu tilviki erum við í raun að leyfa bilanir í ósamstilltum speglum. Þetta mun valda því að skilaboð glatast, en biðröðin verður áfram læsileg og skrifanleg.
Hrísgrjón. 12. Biðröð A er rúllað aftur í miðlara 3 án þess að tapa skilaboðum. Biðröð B rennur aftur til miðlara 3 með tíu skilaboð týnd
Við getum líka sett upp ha-promote-on-failure í merkingu when-synced. Í þessu tilviki, í stað þess að rúlla aftur að speglinum, mun biðröðin bíða þar til miðlari 1 með gögnin fer aftur í netham. Eftir að hún kemur aftur er aðalröðin aftur á Broker 1 án þess að tapa gögnum. Framboði er fórnað fyrir gagnaöryggi. En þetta er áhættusöm háttur sem getur jafnvel leitt til algjörs gagnataps, sem við munum skoða fljótlega.
Hrísgrjón. 13. Biðröð B er enn ótiltæk eftir að hafa tapað miðlara 1
Þú gætir spurt: "Er betra að nota aldrei sjálfvirka samstillingu?" Svarið er að samstilling er hindrunaraðgerð. Meðan á samstillingu stendur getur aðalröðin ekki framkvæmt neinar les- eða skrifaðgerðir!
Við skulum líta á dæmi. Núna erum við með mjög langar biðraðir. Hvernig geta þeir vaxið í svona stærð? Af nokkrum ástæðum:
- Biðraðir eru ekki notaðar á virkan hátt
- Þetta eru háhraða biðraðir og núna eru neytendur hægir
- Það eru hraðar biðraðir, það hefur verið bilun og neytendur eru að ná sér
Hrísgrjón. 14. Tvær stórar biðraðir með mismunandi samstillingarstillingum
Nú fellur Broker 3.
Hrísgrjón. 15. Miðlari 3 fellur og skilur eftir einn meistara og spegill í hverri röð
Broker 3 kemur aftur á netið og nýir speglar eru búnir til. Aðalröð A byrjar að endurtaka fyrirliggjandi skilaboð í nýja spegilinn og á þessum tíma er biðröðin ekki tiltæk. Það tekur tvær klukkustundir að endurtaka gögnin, sem leiðir til tveggja tíma niður í biðröð fyrir þessa biðröð!
Hins vegar er biðröð B áfram tiltæk allt tímabilið. Hún fórnaði nokkurri offramboði fyrir aðgengi.
Hrísgrjón. 16. Biðröð er áfram ótiltæk meðan á samstillingu stendur
Eftir tvær klukkustundir verður biðröð A einnig tiltæk og getur aftur tekið við lestri og skrifum.
Uppfærslur
Þessi lokunarhegðun við samstillingu gerir það erfitt að uppfæra klasa með mjög stórum biðröðum. Á einhverjum tímapunkti þarf að endurræsa aðalhnútinn, sem þýðir annað hvort að skipta yfir í spegil eða slökkva á biðröðinni á meðan verið er að uppfæra þjóninn. Ef við veljum að skipta, munum við missa skilaboð ef speglarnir eru ekki samstilltir. Sjálfgefið er, meðan á bilun miðlara stendur, er ekki framkvæmt bilun í ósamstilltan spegil. Þetta þýðir að um leið og miðlarinn kemur aftur týnum við engin skilaboð, eina tjónið var einföld biðröð. Reglur um hegðun þegar miðlari er aftengdur eru settar af stefnu ha-promote-on-shutdown. Þú getur stillt eitt af tveimur gildum:
always= umskipti yfir í ósamstillta spegla er virkjuðwhen-synced= aðeins umskipti yfir í samstilltan spegil, annars verður röðin ólæsileg og óskrifanleg. Biðröðin fer aftur í þjónustu um leið og miðlari kemur aftur
Með einum eða öðrum hætti, með stórar biðraðir þarftu að velja á milli gagnataps og óaðgengis.
Þegar framboð bætir gagnaöryggi
Það er enn eitt vandamálið sem þarf að huga að áður en ákvörðun er tekin. Þó að sjálfvirk samstilling sé betri fyrir offramboð, hvernig hefur það áhrif á gagnaöryggi? Auðvitað, með betri offramboði, er ólíklegra að RabbitMQ tapi núverandi skilaboðum, en hvað með ný skilaboð frá útgefendum?
Hér þarf að huga að eftirfarandi:
- Gæti ú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 útgefandinn getur aðeins hent skilaboðunum, þá bætir það í raun einnig gagnaöryggi að bæta aðgengi.
Því verður að leita jafnvægis og lausnin fer eftir aðstæðum.
Vandamál með ha-promote-on-failure=when-synced
Hugmynd ha-efla-á-bilun= þegar það er samstillt er að við komum í veg fyrir að skipt sé yfir í ósamstilltan spegil og forðumst þar með gagnatap. Röðin er áfram ólæsileg eða skrifanleg. Þess í stað reynum við að endurheimta miðlarann sem hrundi með gögnin ósnortin svo að hann geti haldið áfram að starfa sem meistari án þess að tapa gögnum.
En (og þetta er stórt en) ef miðlarinn hefur týnt gögnunum sínum, þá höfum við stórt vandamál: biðröðin er týnd! Öll gögn eru horfin! Jafnvel ef þú ert með spegla sem ná að mestu leyti upp í aðalröðina, þá er þeim speglum hent líka.
Til að bæta aftur við hnút með sama nafni segjum við þyrpingunni að gleyma týnda hnútnum (með skipuninni rabbitmqctl forget_cluster_node) og stofnaðu nýjan miðlara með sama hýsingarnafni. Á meðan þyrpingin man eftir týnda hnútnum, man hann gömlu biðröðina og ósamstillta spegla. Þegar þyrping er sagt að gleyma munaðarlausum hnút gleymist sú biðröð líka. Nú þurfum við að lýsa því yfir aftur. Við týndum öllum gögnum, þó við hefðum spegla með hluta af gögnum. Það væri betra að skipta yfir í ósamstilltan spegil!
Því handvirk samstilling (og bilun í samstillingu) ásamt ha-promote-on-failure=when-synced, að mínu mati, alveg áhættusamt. Skjölin segja að þessi valkostur sé til fyrir gagnaöryggi, en hann er tvíeggjaður hnífur.
Meistari endurjafnvægi
Eins og lofað var, snúum við aftur að vandamálinu við uppsöfnun allra meistara á einum eða nokkrum hnútum. Þetta getur jafnvel gerst vegna uppfærslu á rúllandi klasa. Í þriggja hnúta þyrping munu allar aðalraðir safnast saman á einum eða tveimur hnútum.
Meistarar að koma jafnvægi á jafnvægi getur verið vandamál af tveimur ástæðum:
- Það eru engin góð tæki til að framkvæma endurjafnvægi
- Biðröð samstilling
Það er þriðji aðili fyrir endurjafnvægi , sem er ekki opinberlega studd. Varðandi viðbætur frá þriðja aðila í RabbitMQ handbókinni : „Viðbótin veitir nokkur viðbótarstillingar- og skýrslutól, en er ekki studd eða staðfest af RabbitMQ teyminu. Notkun á eigin ábyrgð."
Það er annað bragð til að færa aðalröðina í gegnum stefnur HA. Í handbókinni er minnst á fyrir þetta. Það virkar svona:
- Fjarlægir alla spegla með því að nota tímabundna stefnu sem hefur meiri forgang en núverandi HA-stefna.
- Breytir bráðabirgðastefnu HA til að nota hnútstillingu, tilgreinir hnútinn sem aðalröð ætti að flytja til.
- Samstillir biðröðina fyrir þrýstiflutning.
- Eftir að flutningi er lokið eyðir bráðabirgðareglunni. Upphafleg HA stefna tekur gildi og tilskilinn fjöldi spegla er búinn til.
Gallinn er sá að þessi aðferð virkar kannski ekki ef þú ert með miklar biðraðir eða strangar kröfur um offramboð.
Nú skulum við sjá hvernig RabbitMQ klasar vinna með netsneiðum.
Tap á tengingu
Hnútar dreifðs kerfis eru tengdir með nettengingum og nettenglar geta og verða aftengdir. Tíðni bilana fer eftir staðbundnum innviðum eða áreiðanleika skýsins sem valið er. Í öllum tilvikum verða dreifð kerfi að geta tekist á við þau. Enn og aftur höfum við val á milli framboðs og samræmis, og aftur eru góðu fréttirnar þær að RabbitMQ býður upp á báða valkostina (bara ekki á sama tíma).
Með RabbitMQ höfum við tvo megin valkosti:
- Leyfa rökræna skiptingu (klofinn heili). Þetta tryggir aðgengi, en getur valdið gagnatapi.
- Slökktu á rökréttum aðskilnaði. Getur leitt til skammtímaskerðingar á framboði eftir því hvernig viðskiptavinir tengjast þyrpingunni. Getur einnig leitt til algjörs óaðgengis í tveggja hnúta klasa.
En hvað er rökréttur aðskilnaður? Þetta er þegar þyrping skiptist í tvennt vegna taps á nettengingum. Á hvorri hlið eru speglarnir færðir til meistara, þannig að það eru að lokum nokkrir meistarar í hverri umferð.
Hrísgrjón. 17. Aðalröð og tveir speglar, hver á sínum hnút. Þá kemur netbilun og einn spegill losnar. Aðskilinn hnútur sér að hinir tveir hafa dottið af og kynnir spegla sína til meistarans. Við höfum nú tvær aðalraðir, bæði skrifanlegar og læsilegar.
Ef útgefendur senda gögn til beggja meistaranna endum við með tvö ólík eintök af biðröðinni.
Mismunandi stillingar RabbitMQ veita annað hvort framboð eða samkvæmni.
Hunsa ham (sjálfgefin)
Þessi háttur tryggir aðgengi. Eftir tap á tengingu á sér stað rökréttur aðskilnaður. Eftir að tenging er endurheimt verður stjórnandi að ákveða hvaða skipting á að hafa forgang. Taphliðin verður endurræst og öll uppsöfnuð gögn á þeirri hlið glatast.
Hrísgrjón. 18. Þrír útgefendur eru tengdir þremur miðlarum. Innbyrðis vísar klasinn öllum beiðnum í aðalröðina á miðlara 2.
Nú erum við að missa miðlara 3. Hann sér að aðrir miðlarar hafa fallið frá og kynnir spegilinn sinn fyrir meistaranum. Þannig verður rökréttur aðskilnaður.
Hrísgrjón. 19. Rökfræðileg skipting (klofinn heili). Skrárnar fara í tvær aðalraðir og eintökin tvö víkja.
Tenging er endurheimt, en rökréttur aðskilnaður er áfram. Stjórnandinn verður að velja handvirkt taphliðina. Í tilvikinu hér að neðan endurræsir stjórnandinn Broker 3. Öll skilaboð sem hann náði ekki að senda glatast.
Hrísgrjón. 20. Kerfisstjóri slekkur á miðlara 3.
Hrísgrjón. 21. Kerfisstjórinn byrjar Broker 3 og hann tengist þyrpingunni og tapar öllum skilaboðum sem voru skilin eftir þar.
Meðan tengingin var rofin og eftir að hún var endurreist var þyrpingin og þessi biðröð tiltæk fyrir lestur og ritun.
Autoheal háttur
Virkar svipað og Ignore mode, nema að þyrpingin sjálf velur sjálfkrafa taphliðina eftir að hafa skipt upp og endurheimt tengingu. Týndi hliðin snýr aftur í þyrpinguna tóm, og biðröðin tapar öllum skilaboðum sem voru send aðeins til þeirrar hliðar.
Gera hlé á Minority Mode
Ef við viljum ekki leyfa rökrétta skiptingu, þá er eini möguleikinn okkar að henda lestri og skrifum á minni hliðinni á eftir klasaskiptingu. Þegar miðlarinn sér að það er í minni kantinum stöðvar hann vinnu, það er að segja lokar öllum núverandi tengingum og neitar nýjum. Einu sinni á sekúndu athugar það hvort tengingar séu endurheimtar. Þegar tengingin hefur verið endurheimt fer hún aftur í gang og tengist þyrpingunni.
Hrísgrjón. 22. Þrír útgefendur eru tengdir þremur miðlarum. Innbyrðis vísar klasinn öllum beiðnum í aðalröðina á miðlara 2.
Miðlari 1 og 2 hættu síðan frá miðlara 3. Í stað þess að kynna spegilinn sinn til að ná góðum tökum, hættir miðlari 3 og verður ófáanlegur.
Hrísgrjón. 23. Miðlari 3 gerir hlé, aftengir alla viðskiptavini og hafnar tengingarbeiðnum.
Þegar tenging er endurheimt fer hún aftur í þyrpinguna.
Við skulum skoða annað dæmi þar sem aðalröðin er á Broker 3.
Hrísgrjón. 24. Aðalröð á miðlara 3.
Þá verður sami tengingarleysið. Miðlari 3 gerir hlé vegna þess að hann er í minni kantinum. Á hinni hliðinni sjá hnútarnir að Broker 3 hefur dottið af, þannig að eldri spegillinn frá Brokers 1 og 2 er gerður að meistara.
Hrísgrjón. 25. Skipt yfir í miðlara 2 ef miðlari 3 er ekki tiltækur.
Þegar tenging er endurheimt mun Broker 3 ganga í þyrpinguna.
Hrísgrjón. 26. Þyrpingin er komin aftur í eðlilegan rekstur.
Það sem er mikilvægt að skilja hér er að við fáum samræmi, en við getum líka fengið framboð, ef Við munum með góðum árangri flytja viðskiptavini yfir í flesta hlutann. Fyrir flestar aðstæður myndi ég persónulega velja Pause Minority ham, en það fer mjög eftir einstökum tilfellum.
Til að tryggja aðgengi er mikilvægt að tryggja að viðskiptavinir geti tengst gestgjafanum. Við skulum skoða valkosti okkar.
Að tryggja tengingu viðskiptavina
Við höfum nokkra möguleika á því hvernig á að beina viðskiptavinum að meginhluta klasans eða að virkum hnútum (eftir að einn hnút bilar) eftir tengingarleysi. Fyrst skulum við muna að ákveðin biðröð er hýst á tilteknum hnút, en leið og stefnur eru endurteknar yfir alla hnúta. Viðskiptavinir geta tengst hvaða hnút sem er og innri leið mun vísa þeim þangað sem þeir þurfa að fara. En þegar hnút er lokað hafnar hann tengingum, þannig að viðskiptavinir verða að tengjast öðrum hnút. Ef hnúturinn dettur af er lítið sem hann getur gert.
Valkostir okkar:
- Aðgangur er að þyrpingunni með því að nota álagsjafnara sem einfaldlega fer í gegnum hnútana og viðskiptavinir reyna aftur að tengjast þar til það tekst. Ef hnútur er niðri eða stöðvaður, þá munu tilraunir til að tengjast þeim hnút mistakast, en síðari tilraunir munu fara á aðra netþjóna (í hringrás). Þetta er hentugur fyrir skammtíma tap á tengingu eða niðurfelldan netþjón sem verður fljótt færður upp aftur.
- Fáðu aðgang að klasanum í gegnum álagsjafnara og fjarlægðu frestað/misheppnaða hnúta af listanum um leið og þeir finnast. Ef við gerum þetta fljótt og ef viðskiptavinir geta reynt tenginguna aftur, þá munum við ná stöðugu aðgengi.
- Gefðu hverjum viðskiptavini lista yfir alla hnúta og viðskiptavinurinn velur einn af þeim af handahófi þegar hann tengist. Ef það fær villu þegar reynt er að tengjast, færist það á næsta hnút á listanum þar til það tengist.
- Fjarlægðu umferð frá biluðum/stöðvuðum hnút með DNS. Þetta er gert með því að nota lítið TTL.
Niðurstöður
RabbitMQ þyrping hefur sína kosti og galla. Alvarlegustu ókostirnir eru þessir:
- þegar þeir ganga í þyrping, henda hnútar gögnum sínum;
- lokun á samstillingu veldur því að röðin verður ótiltæk.
Allar erfiðar ákvarðanir stafa af þessum tveimur byggingareinkennum. Ef RabbitMQ gæti vistað gögn þegar þyrpingin er sameinuð aftur, þá væri samstillingin hraðari. Ef það væri fær um að hindra samstillingu myndi það betur styðja stórar biðraðir. Að lagfæra þessi tvö mál myndi stórbæta frammistöðu RabbitMQ sem villuþolin og mjög tiltæk skilaboðatækni. Ég myndi hika við að mæla með RabbitMQ með þyrping í eftirfarandi aðstæðum:
- Óáreiðanlegt net.
- Óáreiðanleg geymsla.
- Mjög langar biðraðir.
Þegar kemur að stillingum fyrir mikla framboð skaltu íhuga eftirfarandi:
ha-promote-on-failure=alwaysha-sync-mode=manualcluster_partition_handling=ignore(Eðaautoheal)- viðvarandi skilaboð
- tryggja að viðskiptavinir tengist virka hnútnum þegar einhver hnút mistekst
Til að tryggja samræmi (gagnaöryggi), skaltu íhuga eftirfarandi stillingar:
- Útgefandi staðfestir og handvirkar viðurkenningar á neytendahliðinni
ha-promote-on-failure=when-synced, ef útgefendur geta reynt aftur síðar og ef þú ert með mjög áreiðanlega geymslu! Annars sett=always.ha-sync-mode=automatic(en fyrir stórar óvirkar biðraðir gæti verið þörf á handvirkri stillingu; íhugaðu einnig hvort óaðgengi muni valda því að skilaboð glatast)- Gera hlé á minnihlutastillingu
- viðvarandi skilaboð
Við höfum ekki fjallað um öll vandamál um bilanaþol og mikið framboð ennþá; td hvernig á að framkvæma stjórnunarferli á öruggan hátt (svo sem uppfærslur í rúlluformi). Við þurfum líka að tala um federation og Shovel viðbótina.
Ef ég hef misst af einhverju öðru, vinsamlegast láttu mig vita.
Sjá líka mitt , þar sem ég geri eyðileggingu á RabbitMQ þyrpingu með því að nota Docker og Blockade til að prófa sumar skeytimissisaðstæður sem lýst er í þessari grein.
Fyrri greinar í seríunni:
Nr. 1 -
Nr. 2 -
Nr. 3 -
Heimild: www.habr.com