Tõrketaluvus ja kõrge kättesaadavus on suured teemad, seega pühendame RabbitMQ-le ja Kafkale eraldi artiklid. See artikkel räägib RabbitMQ-st ja järgmine Kafkast, võrreldes RabbitMQ-ga. See on pikk artikkel, nii et tundke end mugavalt.

Vaatame veataluvuse, järjepidevuse ja kõrge kättesaadavuse (HA) strateegiaid ning iga strateegiaga kaasnevaid kompromisse. RabbitMQ võib töötada sõlmede klastris ja klassifitseeritakse seejärel hajutatud süsteemiks. Hajutatud süsteemide puhul räägime sageli järjepidevusest ja saadavusest.

Need mõisted kirjeldavad, kuidas süsteem käitub, kui see ebaõnnestub. Võrguühenduse tõrge, serveri rike, kõvaketta tõrge, serveri ajutine kättesaamatus prügi kogumise, pakettide kadumise või võrguühenduse aeglustumise tõttu. Kõik see võib põhjustada andmete kadumist või konflikte. Selgub, et on praktiliselt võimatu luua süsteemi, mis oleks ühtaegu täiesti järjekindel (ilma andmete kadumiseta, andmete lahknemiseta) ja kättesaadav (lubab lugemist ja kirjutamist) kõigi rikete stsenaariumide jaoks.

Näeme, et järjepidevus ja kättesaadavus on spektri vastaskülgedel ning peate valima optimeerimisviisi. Hea uudis on see, et RabbitMQ-ga on see valik võimalik. Teil on sellised "nohikulised" hoovad, et nihutada tasakaal suurema järjepidevuse või parema juurdepääsetavuse suunas.

Pöörame erilist tähelepanu sellele, millised konfiguratsioonid põhjustavad kinnitatud kirjete tõttu andmete kadumist. Kirjastajate, maaklerite ja tarbijate vahel on vastutusahel. Kui sõnum on maaklerile edastatud, on tema ülesanne sõnumit mitte kaotada. Kui maakler kinnitab, et kirjastaja on sõnumi kätte saanud, ei eelda me selle kadumist. Kuid me näeme, et see võib tegelikult juhtuda sõltuvalt teie maakleri ja avaldaja konfiguratsioonist.

Ühe sõlme vastupidavuse primitiivid

Elastne järjekorda seadmine/marsruutimine

RabbitMQ-s on kahte tüüpi järjekordi: vastupidavad ja mittekestvad. Kõik järjekorrad salvestatakse Mnesia andmebaasi. Püsivaid järjekordi reklaamitakse uuesti sõlme käivitamisel ja seega jäävad need ellu ka taaskäivitamise, süsteemi krahhi või serveri kokkujooksmise korral (seni kuni andmed püsivad). See tähendab, et seni, kuni kuulutate marsruutimise (vahetuse) ja järjekorra vastupidavaks, taastub järjekorra/marsruutimise infrastruktuur võrgus.

Püsivad järjekorrad ja marsruutimine eemaldatakse sõlme taaskäivitamisel.

Püsivad sõnumid

See, et järjekord on vastupidav, ei tähenda, et kõik selle sõnumid jäävad sõlme taaskäivitamise korral ellu. Ainult kirjad, mille avaldaja on määranud kui vastupidav (püsiv). Püsivad sõnumid tekitavad küll maaklerile lisakoormust, kuid kui sõnumite kadumine on vastuvõetamatu, siis pole muud võimalust.

Riis. 1. Jätkusuutlikkuse maatriks

Klasterdamine järjekorra peegeldamisega

Maakleri kaotuse üleelamiseks vajame koondamist. Saame ühendada mitu RabbitMQ sõlme klastrisse ja seejärel lisada täiendavat liiasust, kopeerides järjekordi mitme sõlme vahel. Nii ei kaota me ühe sõlme rikke korral andmeid ja jääme kättesaadavaks.

Järjekordade peegeldamine:

• üks põhijärjekord (master), mis võtab vastu kõik kirjutamis- ja lugemiskäsud
• üks või mitu peeglit, mis saavad põhijärjekorrast kõik sõnumid ja metaandmed. Need peeglid pole seal skaleerimiseks, vaid puhtalt koondamiseks.

Riis. 2. Järjekordade peegeldamine

Peegeldamine on määratud vastava poliitikaga. Selles saate valida replikatsioonikoefitsiendi ja isegi sõlmed, millel järjekord peaks asuma. Näited:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (üks kapten ja üks peegel)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Väljaandja kinnitus

Järjepideva salvestamise saavutamiseks on vaja väljaandja kinnitusi. Ilma nendeta on oht, et sõnumid lähevad kaotsi. Pärast teate kettale kirjutamist saadetakse väljaandjale kinnitus. RabbitMQ kirjutab sõnumeid kettale mitte vastuvõtmisel, vaid perioodiliselt, mõnesaja millisekundi piires. Kui järjekord on peegeldatud, saadetakse kinnitus alles pärast seda, kui kõik peeglid on oma sõnumi koopia kettale kirjutanud. See tähendab, et kinnituste kasutamine lisab latentsust, kuid kui andmete turvalisus on oluline, siis on need vajalikud.

Rikkumisjärjekord

Kui maakler lõpetab või jookseb kokku, jooksevad kõik selle sõlme järjekorra juhid (ülemad) sellega kaasa. Seejärel valib klaster iga meistri vanima peegli ja reklaamib seda uueks meistriks.

Riis. 3. Mitu peegeldatud järjekorda ja nende eeskirjad

Maakler 3 läheb alla. Pange tähele, et Broker 2 järjekorra C peegel ülendatakse valdajaks. Pange tähele ka seda, et Broker 1 järjekorra C jaoks on loodud uus peegel. RabbitMQ püüab alati säilitada teie poliitikates määratud replikatsiooniteguri.

Riis. 4. Maakler 3 ebaõnnestub, põhjustades järjekorra C tõrke

Järgmine Broker 1 kukub! Meil on jäänud vaid üks maakler. Järjekorra B peegel ülendatakse meistriks.

Joon. 5

Oleme tagastanud Broker 1. Olenemata sellest, kui hästi säilivad andmed maakleri kadumise ja taastamise korral, visatakse taaskäivitamisel kõik peegeldatud järjekorrateated kõrvale. See on oluline meeles pidada, sest sellel on tagajärjed. Vaatleme peagi neid tagajärgi. Seega on Broker 1 nüüd taas klastri liige ja klaster püüab järgida eeskirju ning loob seetõttu Broker 1 peeglid.

Sel juhul oli Broker 1 kadumine täielik, nagu ka andmed, nii et peegeldamata järjekord B läks täielikult kaduma.

Riis. 6. Maakler 1 naaseb teenistusse

Broker 3 on taas võrgus, nii et järjekorrad A ja B saavad tagasi sellel loodud peeglid, et täita oma HA poliitikat. Nüüd on aga kõik põhijärjekorrad ühel sõlmel! See pole ideaalne, parem on ühtlane jaotus sõlmede vahel. Kahjuks ei ole siin meistrite taastamiseks palju võimalusi. Tuleme selle probleemi juurde hiljem tagasi, sest kõigepealt peame vaatama järjekorra sünkroonimist.

Riis. 7. Maakler 3 naaseb teenusesse. Kõik põhijärjekorrad ühel sõlmel!

Nii et nüüd peaks teil olema idee, kuidas peeglid tagavad liiasuse ja veataluvuse. See tagab kättesaadavuse ühe sõlme rikke korral ja kaitseb andmete kadumise eest. Kuid me ei ole veel lõpetanud, sest tegelikult on see palju keerulisem.

Sünkrooni

Uue peegli loomisel kopeeritakse kõik uued sõnumid alati sellele peeglile ja teistele. Mis puutub põhijärjekorras olemasolevatesse andmetesse, siis saame need kopeerida uude peeglisse, millest saab põhijärjekorra täielik koopia. Samuti võime olemasolevaid sõnumeid mitte kopeerida ja lasta põhijärjekorral ja uuel peeglil aja jooksul läheneda, uued sõnumid saabuvad sabas ja olemasolevad lahkuvad põhijärjekorra peast.

See sünkroonimine toimub automaatselt või käsitsi ja seda hallatakse järjekorrapoliitika abil. Vaatame näidet.

Meil on kaks peegeldatud järjekorda. Järjekord A sünkroonitakse automaatselt ja järjekord B käsitsi. Mõlemad järjekorrad sisaldavad kümmet sõnumit.

Riis. 8. Kaks erineva sünkroonimisrežiimiga järjekorda

Nüüd kaotame Broker 3.

Riis. 9. Maakler 3 kukkus

Maakler 3 naaseb teenindusse. Klaster loob uue sõlme iga järjekorra jaoks peegli ja sünkroonib uue järjekorra A automaatselt ülemseadmega. Uue B-järjekorra peegel jääb aga tühjaks. Nii on meil A-järjekorras täielik liiasus ja ainult üks peegel olemasolevate järjekorra B sõnumite jaoks.

Riis. 10. Järjekorra A uus peegel võtab vastu kõik olemasolevad sõnumid, kuid järjekorra B uus peegel mitte.

Mõlemasse järjekorda saabub veel kümme sõnumit. Broker 2 jookseb seejärel kokku ja järjekord A veereb tagasi vanima peegli juurde, mis on Broker 1-l. Andmed ei kao, kui see ebaõnnestub. Järjekorras B on kakskümmend sõnumit põhikirjas ja ainult kümme peeglis, kuna see järjekord ei kordanud kunagi kümmet algset sõnumit.

Riis. 11. Järjekord A veereb tagasi Broker 1 juurde ilma sõnumeid kaotamata

Mõlemasse järjekorda saabub veel kümme sõnumit. Nüüd jookseb Broker 1 kokku. Järjekord A lülitub hõlpsalt peeglisse ilma sõnumeid kaotamata. Järjekorras B on aga probleeme. Siinkohal saame optimeerida kas kättesaadavust või järjepidevust.

Kui tahame juurdepääsetavust optimeerida, siis poliitikat ha-promoe-on-ebaõnnestumine tuleks sisse paigaldada alati. See on vaikeväärtus, nii et te ei saa poliitikat üldse määrata. Sel juhul lubame sisuliselt sünkroniseerimata peeglite rikkeid. See põhjustab sõnumite kadumise, kuid järjekord jääb loetavaks ja kirjutatavaks.

Riis. 12. Järjekord A veeretatakse tagasi Broker 3-le ilma sõnumeid kaotamata. Järjekord B veereb tagasi vahendaja 3 juurde kümne kadunud sõnumiga

Saame ka paigaldada ha-promote-on-failure tähendusse when-synced. Sel juhul ootab järjekord peeglisse tagasi kerimise asemel, kuni Broker 1 oma andmetega naaseb võrgurežiimi. Pärast selle naasmist on põhijärjekord tagasi Broker 1-s ilma andmete kadumiseta. Kättesaadavus ohverdatakse andmete turvalisuse nimel. Kuid see on riskantne režiim, mis võib viia isegi täieliku andmete kadumiseni, mida me peagi vaatame.

Riis. 13. Järjekord B jääb pärast vahendaja 1 kaotamist kättesaamatuks

Võite küsida: "Kas on parem mitte kunagi kasutada automaatset sünkroonimist?" Vastus on, et sünkroonimine on blokeeriv toiming. Sünkroonimise ajal ei saa põhijärjekord sooritada lugemis- ega kirjutamistoiminguid!

Vaatame näidet. Nüüd on meil väga pikad järjekorrad. Kuidas nad saavad selliseks kasvada? Mitmel põhjusel:

• Järjekordi aktiivselt ei kasutata
• Need on kiired järjekorrad ja praegu on tarbijad aeglased
• Need on kiired järjekorrad, on esinenud tõrkeid ja tarbijad jõuavad järele

Riis. 14. Kaks suurt järjekorda erinevate sünkroonimisrežiimidega

Nüüd langeb Broker 3.

Riis. 15. Maakler 3 kukub, jättes igasse järjekorda ühe masteri ja peegli

Broker 3 tuleb uuesti võrku ja luuakse uued peeglid. Põhijärjekord A hakkab olemasolevaid sõnumeid uude peeglisse kopeerima ja selle aja jooksul pole järjekord saadaval. Andmete kopeerimiseks kulub kaks tundi, mille tulemuseks on selle järjekorra jaoks kaks tundi seisakut!

Järjekord B on aga saadaval kogu perioodi vältel. Ta ohverdas ligipääsetavuse nimel mõningase koondamise.

Riis. 16. Järjekord jääb sünkroonimise ajal kättesaamatuks

Kahe tunni pärast muutub kättesaadavaks ka järjekord A ning see võib uuesti lugemist ja kirjutamist vastu võtta.

Uuendused

Selline blokeeriv käitumine sünkroonimise ajal muudab väga suurte järjekordadega klastrite värskendamise keeruliseks. Mingil hetkel tuleb peasõlm taaskäivitada, mis tähendab serveri uuendamise ajal peegelsile ümberlülitamist või järjekorra keelamist. Kui valime ülemineku, kaotame sõnumid, kui peeglid pole sünkroonitud. Vaikimisi ei teostata maakleri katkestuse ajal tõrkesiiret sünkroonimata peeglisse. See tähendab, et niipea kui maakler naaseb, ei kaota me ühtegi sõnumit, ainuke kahju oli lihtne järjekord. Käitumisreeglid maakleri ühenduse katkestamisel on kehtestatud poliitikaga ha-promote-on-shutdown. Saate määrata ühe kahest väärtusest:

• always= üleminek sünkroniseerimata peeglitele on lubatud
• when-synced= üleminek ainult sünkroniseeritud peeglile, vastasel juhul muutub järjekord loetamatuks ja kirjutamatuks. Järjekord naaseb teenindusse niipea, kui maakler naaseb

Nii või teisiti tuleb suurte järjekordade puhul valida andmete kadumise ja kättesaamatuse vahel.

Kui saadavus parandab andmeturvet

Enne otsuse tegemist tuleb arvestada veel ühe komplikatsiooniga. Kuigi automaatne sünkroonimine on koondamise jaoks parem, kuidas see mõjutab andmete turvalisust? Loomulikult kaotab RabbitMQ parema koondamise korral olemasolevad sõnumid väiksema tõenäosusega, kuid kuidas on lood kirjastajate uute sõnumitega?

Siin peate arvestama järgmisega:

• Kas väljaandja võib lihtsalt veateate tagastada ja lasta ülesvoolu teenusel või kasutajal hiljem uuesti proovida?
• Kas avaldaja saab sõnumi salvestada kohapeal või andmebaasi, et hiljem uuesti proovida?

Kui kirjastaja saab sõnumist vaid loobuda, siis tegelikult parandab ligipääsetavuse parandamine ka andmete turvalisust.

Seega tuleb otsida tasakaalu ja lahendus sõltub konkreetsest olukorrast.

Probleemid funktsiooniga ha-promote-on-failure=when-synced

Mõte ha-promoe-on-ebaõnnestumine= millal-sünkroonitud takistame sünkroonimata peeglile üleminekut ja väldime sellega andmete kadumist. Järjekord jääb loetamatuks või kirjutamatuks. Selle asemel proovime kokkujooksnud maakleri taastada tervete andmetega, et see saaks ilma andmete kadumiseta jätkata põhifunktsiooni toimimist.

Aga (ja see on suur aga) kui maakler on oma andmed kaotanud, siis on meil suur probleem: järjekord on kadunud! Kõik andmed on kadunud! Isegi kui teil on peeglid, mis jõuavad enamasti põhijärjekorrale järele, jäetakse ka need peeglid kõrvale.

Samanimelise sõlme uuesti lisamiseks käsime klastril kaotatud sõlm unustada (käsuga rabbitmqctl unusta_klastri_sõlm) ja käivitage uus maakler sama hostinimega. Kuigi klaster mäletab kadunud sõlme, mäletab see vana järjekorda ja sünkroonimata peegleid. Kui klastril kästakse unustada orvuks jäänud sõlm, unustatakse ka see järjekord. Nüüd peame selle uuesti deklareerima. Kaotasime kõik andmed, kuigi meil olid osalise andmekogumiga peeglid. Parem oleks sünkroniseerimata peeglile üle minna!

Seetõttu käsitsi sünkroonimine (ja sünkroonimise ebaõnnestumine) koos ha-promote-on-failure=when-synced, minu arust üsna riskantne. Dokumendid ütlevad, et see valik on andmete turvalisuse jaoks olemas, kuid see on kahe teraga nuga.

Master tasakaalustamine

Nagu lubatud, pöördume tagasi probleemi juurde, mis puudutab kõigi meistrite akumuleerumist ühes või mitmes sõlmes. See võib juhtuda isegi jooksva klastri värskenduse tulemusena. Kolme sõlmega klastris kogunevad kõik põhijärjekorrad ühte või kahte sõlme.

Meistrite tasakaalustamine võib olla problemaatiline kahel põhjusel:

• Tasakaalu taastamiseks pole häid tööriistu
• Järjekorra sünkroonimine

Tasakaalustamiseks on kolmas osapool pistikprogramm, mida ametlikult ei toetata. Kolmandate osapoolte pistikprogrammide kohta RabbitMQ juhendis ütles: "Plugin pakub mõningaid täiendavaid konfiguratsiooni- ja aruandlustööriistu, kuid RabbitMQ meeskond seda ei toeta ega kinnita. Kasutage omal riisikol."

Põhijärjekorra teisaldamiseks HA poliitikate kaudu on veel üks nipp. Kasutusjuhendis mainitakse stsenaarium selle jaoks. See toimib järgmiselt:

• Eemaldab kõik peeglid, kasutades ajutist poliitikat, millel on kõrgem prioriteet kui olemasoleval HA-poliitikal.
• Muudab HA ajutise poliitika sõlmerežiimi kasutamiseks, määrates sõlme, kuhu põhijärjekord üle kanda.
• Sünkroonib tõukerände järjekorda.
• Pärast migratsiooni lõpetamist kustutab ajutise poliitika. Esialgne HA-poliitika jõustub ja vajalik arv peegleid luuakse.

Negatiivne külg on see, et see lähenemisviis ei pruugi töötada, kui teil on suured järjekorrad või ranged koondamisnõuded.

Nüüd vaatame, kuidas RabbitMQ klastrid võrgusektsioonidega töötavad.

Ühenduse kaotus

Hajutatud süsteemi sõlmed on ühendatud võrgulinkide kaudu ning võrgulinke saab ja katkestatakse. Katkestuste sagedus sõltub kohalikust infrastruktuurist või valitud pilve töökindlusest. Igal juhul peavad hajutatud süsteemid nendega toime tulema. Taas on meil valida saadavuse ja järjepidevuse vahel ning jällegi on hea uudis see, et RabbitMQ pakub mõlemat võimalust (lihtsalt mitte samal ajal).

RabbitMQ-ga on meil kaks peamist võimalust:

• Luba loogiline jaotus (split-brain). See tagab kättesaadavuse, kuid võib põhjustada andmete kadumise.
• Keela loogiline eraldamine. Sõltuvalt sellest, kuidas kliendid klastriga ühenduse loovad, võib selle tulemuseks olla lühiajaline kättesaadavuse kaotus. Võib põhjustada ka täieliku kättesaamatuse kahe sõlmega klastris.

Aga mis on loogiline eraldamine? See on siis, kui klaster jaguneb võrguühenduste katkemise tõttu kaheks. Mõlemal küljel ülendatakse peeglid meistriks, nii et lõpuks on järjekorras mitu meistrit.

Riis. 17. Põhijärjekord ja kaks peeglit, kumbki eraldi sõlmel. Siis tekib võrgutõrge ja üks peegel eraldub. Eraldatud sõlm näeb, et ülejäänud kaks on maha kukkunud ja tõstab oma peeglid kapteni. Meil on nüüd kaks põhijärjekorda, nii kirjutatavad kui ka loetavad.

Kui väljaandjad saadavad andmed mõlemale põhivormingule, saame järjekorrast kaks erinevat koopiat.

RabbitMQ erinevad režiimid tagavad kas kättesaadavuse või järjepidevuse.

Ignoreeri režiim (vaikimisi)

See režiim tagab juurdepääsetavuse. Pärast ühenduse katkemist toimub loogiline eraldamine. Pärast ühenduse taastamist peab administraator otsustama, millist partitsiooni eelistada. Kaotanud pool taaskäivitatakse ja kõik sellel poolel kogunenud andmed lähevad kaotsi.

Riis. 18. Kolm väljaandjat on seotud kolme maakleriga. Sisemiselt suunab klaster kõik päringud Broker 2 põhijärjekorda.

Nüüd oleme kaotamas Maakleri 3. Ta näeb, et teised maaklerid on maha kukkunud ja edutab oma peegli meistriks. Nii toimub loogiline eraldamine.

Riis. 19. Loogiline jaotus (split-brain). Kirjed lähevad kahte põhijärjekorda ja kaks koopiat erinevad üksteisest.

Ühenduvus taastub, kuid loogiline eraldatus jääb alles. Administraator peab käsitsi valima kaotaja poole. Alloleval juhul taaskäivitab administraator Broker 3. Kõik sõnumid, mida tal ei õnnestunud edastada, lähevad kaotsi.

Riis. 20. Administraator keelab Broker 3.

Riis. 21. Administraator käivitab Broker 3 ja see liitub klastriga, kaotades kõik sinna jäetud sõnumid.

Ühenduse katkemise ajal ja pärast selle taastamist olid klaster ja see järjekord lugemiseks ja kirjutamiseks saadaval.

Automaatne ravirežiim

Töötab sarnaselt Ignoreeri režiimiga, välja arvatud see, et klaster ise valib pärast ühenduvuse jagamist ja taastamist automaatselt kaotaja poole. Kaotanud pool naaseb tühjana klastrisse ja järjekord kaotab kõik kirjad, mis saadeti ainult sellele poolele.

Peatage vähemusrežiim

Kui me ei soovi loogilist partitsiooni lubada, on meie ainus võimalus jätta lugemis- ja kirjutamistoimingud kõrvale pärast klastri partitsiooni. Kui maakler näeb, et see on väiksemal poolel, peatab ta töö, st sulgeb kõik olemasolevad ühendused ja keeldub uutest. Kord sekundis kontrollib see ühenduse taastamist. Kui ühenduvus on taastatud, jätkab see tööd ja liitub klastriga.

Riis. 22. Kolm väljaandjat on seotud kolme maakleriga. Sisemiselt suunab klaster kõik päringud Broker 2 põhijärjekorda.

Vahendid 1 ja 2 jagunevad seejärel Broker 3-st. Selle asemel, et tõsta oma peegli meistriks, peatab Broker 3 ja muutub kättesaamatuks.

Riis. 23. Maakler 3 peatab, katkestab kõigi klientide ühenduse ja lükkab ühendustaotlused tagasi.

Kui ühenduvus on taastatud, naaseb see klastrisse.

Vaatame veel ühte näidet, kus põhijärjekord on Broker 3-s.

Riis. 24. Maakleri 3 põhijärjekord.

Siis toimub sama ühenduse katkemine. Maakler 3 teeb pausi, kuna see asub väiksemal küljel. Teisel pool näevad sõlmed, et Broker 3 on maha kukkunud, nii et vanem peegel Brokers 1 ja 2 ülendatakse meistriks.

Riis. 25. Üleminek Broker 2-le, kui Broker 3 pole saadaval.

Kui ühenduvus on taastatud, liitub klastriga Broker 3.

Riis. 26. Klaster on naasnud normaalsele tööle.

Siin on oluline mõista, et saavutame järjepidevuse, kuid saame ka kättesaadavuse, kui Viime kliente edukalt üle enamikku sektsiooni. Enamiku olukordade jaoks valiksin isiklikult režiimi Pause Minority, kuid see sõltub konkreetsest juhtumist.

Kättesaadavuse tagamiseks on oluline tagada klientide edukas hostiga ühenduse loomine. Vaatame oma võimalusi.

Kliendi ühenduvuse tagamine

Meil on mitu võimalust, kuidas suunata kliente pärast ühenduse katkemist klastri põhiossa või töötavatesse sõlmedesse (pärast ühe sõlme riket). Esiteks pidage meeles, et konkreetne järjekord on hostitud konkreetses sõlmes, kuid marsruutimist ja poliitikaid korratakse kõigis sõlmedes. Kliendid saavad ühenduse luua mis tahes sõlmega ja sisemine marsruutimine suunab nad sinna, kuhu nad peavad minema. Kuid kui sõlm on peatatud, lükkab see ühendused tagasi, seega peavad kliendid ühenduma teise sõlmega. Kui sõlm ära kukub, ei saa ta üldse midagi teha.

Meie valikud:

• Klastrile pääseb juurde koormuse tasakaalustaja abil, mis lihtsalt liigub läbi sõlmede ja kliendid proovivad uuesti ühendust luua, kuni see õnnestub. Kui sõlm on maas või peatatud, siis katsed selle sõlmega ühenduse loomiseks ebaõnnestuvad, kuid järgnevad katsed lähevad teistele serveritele (ümberringi). See sobib lühiajalise ühenduse katkemise või serveri allakukkumise korral, mis taastatakse kiiresti.
• Juurdepääs klastrile koormuse tasakaalustaja kaudu ja peatatud/ebaõnnestunud sõlmede eemaldamine loendist niipea, kui need tuvastatakse. Kui teeme seda kiiresti ja kui kliendid saavad ühendust uuesti proovida, siis saavutame pideva kättesaadavuse.
• Andke igale kliendile kõigi sõlmede loend ja klient valib ühenduse loomisel neist juhuslikult ühe. Kui see saab ühenduse loomisel tõrketeate, liigub see loendis järgmisesse sõlme, kuni ühendub.
• Eemaldage DNS-i abil liiklus ebaõnnestunud/peatatud sõlmest. Seda tehakse väikese TTL-i abil.

Järeldused

RabbitMQ klasterdamisel on oma eelised ja puudused. Kõige tõsisemad puudused on järgmised:

• klastriga liitumisel loobuvad sõlmed oma andmetest;
• sünkroonimise blokeerimine muudab järjekorra kättesaamatuks.

Kõik rasked otsused tulenevad nendest kahest arhitektuurilisest eripärast. Kui RabbitMQ saaks klastri uuesti ühendamisel andmeid salvestada, oleks sünkroonimine kiirem. Kui see oleks võimeline mitteblokeerivaks sünkroonimiseks, toetaks see paremini suuri järjekordi. Nende kahe probleemi lahendamine parandaks oluliselt RabbitMQ kui tõrketaluvusega ja hästi kättesaadava sõnumitehnoloogia jõudlust. Sooviksin kõhklevalt RabbitMQ-d koos klastritega järgmistes olukordades:

• Ebausaldusväärne võrk.
• Ebausaldusväärne salvestusruum.
• Väga pikad järjekorrad.

Kõrge kättesaadavuse seadete puhul võtke arvesse järgmist.

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (Või autoheal)
• püsivad sõnumid
• tagama klientide ühenduse aktiivse sõlmega, kui mõni sõlm ebaõnnestub

Järjepidevuse (andmete turvalisuse) tagamiseks kaaluge järgmisi sätteid.

• Väljaandja kinnitused ja manuaalsed kinnitused tarbija poolel
• ha-promote-on-failure=when-synced, kui väljaandjad saavad hiljem uuesti proovida ja kui teil on väga usaldusväärne salvestusruum! Muidu panna =always.
• ha-sync-mode=automatic (kuid suurte passiivsete järjekordade puhul võib olla vajalik käsitsi režiim; samuti kaaluge, kas kättesaamatus ei põhjusta sõnumite kadumist)
• Peatage vähemuse režiim
• püsivad sõnumid

Me ei ole veel käsitlenud kõiki tõrketaluvuse ja kõrge kättesaadavuse probleeme; näiteks kuidas turvaliselt läbi viia haldusprotseduure (nt jooksvaid värskendusi). Peame rääkima ka föderatsioonist ja Shoveli pistikprogrammist.

Kui ma olen millestki muust ilma jäänud, palun andke mulle teada.

Vaata ka minu postitus, kus ma hävitan RabbitMQ-klastri, kasutades Dockerit ja Blockade'i, et testida mõningaid selles artiklis kirjeldatud sõnumite kadumise stsenaariume.

Sarja varasemad artiklid:
nr 1 - habr.com/ru/company/itsumma/blog/416629
nr 2 - habr.com/ru/company/itsumma/blog/418389
nr 3 - habr.com/ru/company/itsumma/blog/437446

Allikas: www.habr.com