Toleranca e gabimeve dhe disponueshmëria e lartë janë tema të mëdha, kështu që ne do t'i kushtojmë artikuj të veçantë RabbitMQ dhe Kafka. Ky artikull ka të bëjë me RabbitMQ, dhe artikulli tjetër ka të bëjë me Kafkën, në krahasim me RabbitMQ. Ky është një artikull i gjatë, kështu që qetësohuni.

Le të shohim strategjitë e tolerancës së gabimeve, qëndrueshmërisë dhe disponueshmërisë së lartë (HA) dhe kompromiset që bën secila strategji. RabbitMQ mund të ekzekutohet në një grup nyjesh - dhe më pas klasifikohet si një sistem i shpërndarë. Kur bëhet fjalë për sistemet e shpërndara, ne shpesh flasim për qëndrueshmëri dhe disponueshmëri.

Këto koncepte përshkruajnë se si një sistem sillet kur ai dështon. Dështimi i lidhjes së rrjetit, dështimi i serverit, dështimi i hard drive-it, mosdisponueshmëria e përkohshme e serverit për shkak të grumbullimit të mbeturinave, humbjes së paketave ose ngadalësimit të lidhjes së rrjetit. E gjithë kjo mund të çojë në humbje ose konflikte të të dhënave. Rezulton se është praktikisht e pamundur të vendosësh një sistem që është plotësisht i qëndrueshëm (pa humbje të dhënash, pa divergjencë të dhënash) dhe i disponueshëm (do të pranojë lexime dhe shkrime) për të gjithë skenarët e dështimit.

Do të shohim se qëndrueshmëria dhe disponueshmëria janë në skajet e kundërta të spektrit dhe ju duhet të zgjidhni se cilën mënyrë të optimizoni. Lajmi i mirë është se me RabbitMQ kjo zgjedhje është e mundur. Ju keni këto lloj levash "të mërzitshme" për të zhvendosur ekuilibrin drejt qëndrueshmërisë më të madhe ose aksesit më të madh.

Ne do t'i kushtojmë vëmendje të veçantë se cilat konfigurime çojnë në humbjen e të dhënave për shkak të regjistrimeve të konfirmuara. Ekziston një zinxhir përgjegjësie midis botuesve, ndërmjetësve dhe konsumatorëve. Pasi mesazhi t'i transmetohet ndërmjetësit, detyra e tij është të mos e humbasë mesazhin. Kur ndërmjetësi pranon marrjen e mesazhit nga botuesi, ne nuk presim që ai të humbasë. Por ne do të shohim se kjo mund të ndodhë në të vërtetë në varësi të konfigurimit të ndërmjetësit dhe botuesit tuaj.

Primitivët e elasticitetit të një nyjeje

Radhë/Rrugë elastike

Ekzistojnë dy lloje të radhëve në RabbitMQ: të qëndrueshme dhe jo të qëndrueshme. Të gjitha radhët ruhen në bazën e të dhënave Mnesia. Radhët e qëndrueshme ri-reklamohen në fillimin e nyjeve dhe kështu mbijetojnë rinisjet, përplasjet e sistemit ose prishjet e serverit (për sa kohë që të dhënat vazhdojnë). Kjo do të thotë se për sa kohë që ju deklaroni se rutimi (shkëmbimi) dhe radha janë elastike, infrastruktura e radhës/drejtimit do të kthehet në linjë.

Radhët e paqëndrueshme dhe drejtimi hiqen kur nyja riniset.

Mesazhe të vazhdueshme

Vetëm për shkak se një radhë është e qëndrueshme nuk do të thotë që të gjitha mesazhet e saj do t'i mbijetojnë një rifillimi të nyjeve. Vetëm mesazhet e vendosura nga botuesi si të qëndrueshme (i vazhdueshëm). Mesazhet e vazhdueshme krijojnë ngarkesë shtesë tek ndërmjetësi, por nëse humbja e mesazhit është e papranueshme, atëherë nuk ka mundësi tjetër.

Oriz. 1. Matrica e qëndrueshmërisë

Grumbullim me pasqyrim në radhë

Për t'i mbijetuar humbjes së një ndërmjetësi, ne kemi nevojë për tepricë. Ne mund të kombinojmë shumë nyje RabbitMQ në një grup, dhe më pas të shtojmë tepricë shtesë duke përsëritur radhët midis nyjeve të shumta. Në këtë mënyrë, nëse një nyje dështon, ne nuk humbasim të dhëna dhe mbetemi të disponueshme.

Pasqyrimi i radhës:

• një radhë kryesore (master), e cila merr të gjitha komandat e shkrimit dhe leximit
• një ose më shumë pasqyra që marrin të gjitha mesazhet dhe meta të dhënat nga radha kryesore. Këto pasqyra nuk janë atje për shkallëzim, por thjesht për tepricë.

Oriz. 2. Pasqyrimi i radhës

Pasqyrimi përcaktohet nga politika e duhur. Në të mund të zgjidhni koeficientin e replikimit dhe madje edhe nyjet në të cilat duhet të vendoset radha. Shembuj:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (një mjeshtër dhe një pasqyrë)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Konfirmimi i botuesit

Për të arritur regjistrim të qëndrueshëm, kërkohen konfirmimet e botuesit. Pa to, ekziston rreziku i humbjes së mesazheve. Një konfirmim i dërgohet botuesit pasi mesazhi të jetë shkruar në disk. RabbitMQ shkruan mesazhe në disk jo pas marrjes, por në baza periodike, në rajonin prej disa qindra milisekondash. Kur një radhë pasqyrohet, një konfirmim dërgohet vetëm pasi të gjitha pasqyrat të kenë shkruar gjithashtu kopjen e mesazhit në disk. Kjo do të thotë se përdorimi i konfirmimeve shton vonesën, por nëse siguria e të dhënave është e rëndësishme, atëherë ato janë të nevojshme.

Radha e dështimit

Kur një ndërmjetës largohet ose rrëzohet, të gjithë drejtuesit e radhëve (mjeshtrit) në atë nyje rrëzohen së bashku me të. Më pas grupi zgjedh pasqyrën më të vjetër të çdo masteri dhe e promovon atë si master të ri.

Oriz. 3. Radhët e shumëfishta të pasqyruara dhe politikat e tyre

Broker 3 shkon poshtë. Vini re se pasqyra e radhës C në Broker 2 po promovohet në master. Gjithashtu vini re se është krijuar një pasqyrë e re për Radhën C në Broker 1. RabbitMQ përpiqet gjithmonë të ruajë faktorin e përsëritjes të specifikuar në politikat tuaja.

Oriz. 4. Ndërmjetësi 3 dështon, duke bërë që radha C të dështojë

Brokeri tjetër 1 bie! Na ka mbetur vetëm një ndërmjetës. Pasqyra e radhës B promovohet në master.

Fig. 5

Ne kemi kthyer Brokerin 1. Pavarësisht se sa mirë i mbijetojnë të dhënave humbjes dhe rikuperimit të ndërmjetësit, të gjitha mesazhet e radhës të pasqyruara hidhen pas rinisjes. Kjo është e rëndësishme të theksohet sepse do të ketë pasoja. Ne do t'i shikojmë këto implikime së shpejti. Pra, Broker 1 është tani përsëri një anëtar i grupit dhe grupi përpiqet të pajtohet me politikat dhe për këtë arsye krijon pasqyra në Broker 1.

Në këtë rast, humbja e Broker 1 ishte e plotë, siç ishin të dhënat, kështu që Radha B e papasqyruar humbi plotësisht.

Oriz. 6. Ndërmjetësi 1 kthehet në shërbim

Broker 3 është përsëri në linjë, kështu që radhët A dhe B marrin përsëri pasqyrat e krijuara në të për të përmbushur politikat e tyre HA. Por tani të gjitha radhët kryesore janë në një nyje! Kjo nuk është ideale, një shpërndarje e barabartë midis nyjeve është më e mirë. Fatkeqësisht, nuk ka shumë opsione këtu për ribalancimin e mjeshtrave. Ne do t'i kthehemi kësaj çështjeje më vonë sepse duhet të shikojmë fillimisht sinkronizimin e radhëve.

Oriz. 7. Ndërmjetësi 3 kthehet në shërbim. Të gjitha radhët kryesore në një nyje!

Pra, tani duhet të keni një ide se si pasqyrat ofrojnë tepricë dhe tolerancë ndaj gabimeve. Kjo siguron disponueshmërinë në rast të dështimit të një nyje të vetme dhe mbron nga humbja e të dhënave. Por nuk kemi mbaruar ende, sepse në realitet është shumë më e ndërlikuar.

sinkronizim

Kur krijoni një pasqyrë të re, të gjitha mesazhet e reja gjithmonë do të kopjohen në këtë pasqyrë dhe në çdo tjetër. Sa i përket të dhënave ekzistuese në radhën kryesore, ne mund t'i përsërisim ato në një pasqyrë të re, e cila bëhet një kopje e plotë e masterit. Ne gjithashtu mund të zgjedhim të mos përsërisim mesazhet ekzistuese dhe të lëmë radhën kryesore dhe pasqyrën e re të konvergojnë në kohë, me mesazhe të reja që vijnë në bisht dhe mesazhet ekzistuese që largohen nga kreu i radhës kryesore.

Ky sinkronizim kryhet automatikisht ose manualisht dhe menaxhohet duke përdorur një politikë të radhës. Le të shohim një shembull.

Kemi dy radhë të pasqyruara. Radha A sinkronizohet automatikisht dhe Radha B sinkronizohet manualisht. Të dy radhët përmbajnë dhjetë mesazhe.

Oriz. 8. Dy radhë me mënyra të ndryshme sinkronizimi

Tani po humbasim Broker 3.

Oriz. 9. Ndërmjetësi 3 ra

Broker 3 kthehet në shërbim. Grupi krijon një pasqyrë për çdo radhë në nyjen e re dhe sinkronizon automatikisht radhën e re A me masterin. Megjithatë, pasqyra e radhës së re B mbetet bosh. Në këtë mënyrë kemi tepricë të plotë në Radhën A dhe vetëm një pasqyrë për mesazhet ekzistuese të Radhës B.

Oriz. 10. Pasqyra e re e Radhës A merr të gjitha mesazhet ekzistuese, por pasqyra e re e Radhës B jo.

Dhjetë mesazhe të tjera mbërrijnë në të dy radhët. Më pas, Broker 2 rrëzohet dhe Radha A kthehet në pasqyrën më të vjetër, e cila është në Broker 1. Nuk ka humbje të të dhënave kur ajo dështon. Në radhën B, ka njëzet mesazhe në master dhe vetëm dhjetë në pasqyrë, sepse kjo radhë nuk ka përsëritur kurrë dhjetë mesazhet origjinale.

Oriz. 11. Radha A kthehet në Broker 1 pa humbur mesazhet

Dhjetë mesazhe të tjera mbërrijnë në të dy radhët. Tani prishet Broker 1. Radha A kalon lehtësisht në pasqyrë pa humbur mesazhe. Megjithatë, Radha B ka probleme. Në këtë pikë ne mund të optimizojmë disponueshmërinë ose qëndrueshmërinë.

Nëse duam të optimizojmë aksesueshmërinë, atëherë politika ha-promovoj-në-dështim duhet të instalohet në gjithmonë. Kjo është vlera e paracaktuar, kështu që thjesht nuk mund ta specifikoni fare politikën. Në këtë rast, në thelb po lejojmë dështime në pasqyrat e pasinkronizuara. Kjo do të bëjë që mesazhet të humbasin, por radha do të mbetet e lexueshme dhe e shkruar.

Oriz. 12. Radha A kthehet në Broker 3 pa humbur mesazhe. Radha B kthehet në Broker 3 me dhjetë mesazhe të humbura

Ne gjithashtu mund të instalojmë ha-promote-on-failure në kuptim when-synced. Në këtë rast, në vend që të kthehet në pasqyrë, radha do të presë derisa Broker 1 me të dhënat e tij të kthehet në modalitetin online. Pasi të kthehet, radha kryesore kthehet në Broker 1 pa asnjë humbje të të dhënave. Disponueshmëria sakrifikohet për sigurinë e të dhënave. Por kjo është një mënyrë e rrezikshme që madje mund të çojë në humbje të plotë të të dhënave, të cilën do ta shohim së shpejti.

Oriz. 13. Radha B mbetet e padisponueshme pas humbjes së Brokerit 1

Ju mund të pyesni: "A është më mirë të mos përdorni kurrë sinkronizimin automatik?" Përgjigja është se sinkronizimi është një operacion bllokues. Gjatë sinkronizimit, radha kryesore nuk mund të kryejë asnjë operacion leximi ose shkrimi!

Le të shohim një shembull. Tani kemi radhë shumë të gjata. Si mund të rriten në një madhësi të tillë? Për disa arsye:

• Radhët nuk përdoren në mënyrë aktive
• Këto janë radhë me shpejtësi të lartë dhe tani konsumatorët janë të ngadaltë
• Janë radhë me shpejtësi të lartë, ka pasur një defekt dhe konsumatorët po e kapin hapin

Oriz. 14. Dy radhë të mëdha me mënyra të ndryshme sinkronizimi

Tani Broker 3 bie.

Oriz. 15. Ndërmjetësi 3 bie, duke lënë një master dhe pasqyrë në çdo radhë

Broker 3 kthehet në internet dhe krijohen pasqyra të reja. Radha kryesore A fillon të riprodhojë mesazhet ekzistuese në pasqyrën e re dhe gjatë kësaj kohe Radha është e padisponueshme. Duhen dy orë për të përsëritur të dhënat, duke rezultuar në dy orë pushim për këtë Radhë!

Megjithatë, Radha B mbetet e disponueshme gjatë gjithë periudhës. Ajo sakrifikoi disa teprica për aksesueshmërinë.

Oriz. 16. Radha mbetet e padisponueshme gjatë sinkronizimit

Pas dy orësh, Radha A bëhet gjithashtu e disponueshme dhe mund të fillojë të pranojë përsëri lexime dhe shkrime.

Updates

Kjo sjellje bllokuese gjatë sinkronizimit e bën të vështirë përditësimin e grupimeve me radhë shumë të mëdha. Në një moment, nyja kryesore duhet të riniset, që do të thotë ose kalimi në një pasqyrë ose çaktivizimi i radhës ndërsa serveri është duke u përmirësuar. Nëse zgjedhim të kalojmë, do të humbasim mesazhet nëse pasqyrat nuk sinkronizohen. Si parazgjedhje, gjatë një ndërprerjeje ndërmjetësi, një dështim në një pasqyrë të pasinkronizuar nuk kryhet. Kjo do të thotë që sapo ndërmjetësi të kthehet, ne nuk humbasim asnjë mesazh, dëmi i vetëm ishte një radhë e thjeshtë. Rregullat e sjelljes kur një ndërmjetës është i shkëputur përcaktohen nga politika ha-promote-on-shutdown. Mund të vendosni një nga dy vlerat:

• always= aktivizohet kalimi në pasqyra të pasinkronizuara
• when-synced= kalim vetëm në një pasqyrë të sinkronizuar, përndryshe radha bëhet e palexueshme dhe e pashkruar. Radha kthehet në shërbim sapo ndërmjetësi të kthehet

Në një mënyrë apo tjetër, me radhë të mëdha duhet të zgjidhni midis humbjes së të dhënave dhe mosdisponueshmërisë.

Kur disponueshmëria përmirëson sigurinë e të dhënave

Ekziston edhe një ndërlikim tjetër për t'u marrë parasysh përpara se të merrni një vendim. Ndërsa sinkronizimi automatik është më i mirë për tepricë, si ndikon ai në sigurinë e të dhënave? Natyrisht, me tepricë më të mirë, RabbitMQ ka më pak gjasa të humbasë mesazhet ekzistuese, por çfarë ndodh me mesazhet e reja nga botuesit?

Këtu duhet të keni parasysh sa vijon:

• A mundet botuesi thjesht të kthejë një gabim dhe të bëjë që shërbimi ose përdoruesi të provojë sërish më vonë?
• A mundet botuesi ta ruajë mesazhin në nivel lokal ose në një bazë të dhënash për ta provuar përsëri më vonë?

Nëse botuesi mund ta heqë vetëm mesazhin, atëherë në fakt, përmirësimi i aksesueshmërisë përmirëson gjithashtu sigurinë e të dhënave.

Kështu, duhet kërkuar një ekuilibër dhe zgjidhja varet nga situata specifike.

Probleme me ha-promote-on-failure=kur-sinkronizohet

Ide ha-promovoj-në-dështim= kur-sinkronizuar është se ne parandalojmë kalimin në një pasqyrë të pasinkronizuar dhe në këtë mënyrë shmangim humbjen e të dhënave. Radha mbetet e palexueshme ose e shkruajtshme. Në vend të kësaj, ne përpiqemi të rikuperojmë ndërmjetësin e rrëzuar me të dhënat e tij të paprekura, në mënyrë që të mund të rifillojë funksionimin si master pa humbje të të dhënave.

Por (dhe kjo është një por e madhe) nëse ndërmjetësi ka humbur të dhënat e tij, atëherë kemi një problem të madh: radha ka humbur! Të gjitha të dhënat janë zhdukur! Edhe nëse keni pasqyra që më së shumti kapin radhën kryesore, ato pasqyra gjithashtu hidhen.

Për të rishtuar një nyje me të njëjtin emër, i themi grupit të harrojë nyjen e humbur (me komandën rabbitmqctl harroni_grup_nyje) dhe filloni një ndërmjetës të ri me të njëjtin emër pritës. Ndërsa grupi kujton nyjen e humbur, kujton radhën e vjetër dhe pasqyrat e pasinkronizuara. Kur një grupi i thuhet të harrojë një nyje jetime, ajo radhë gjithashtu harrohet. Tani duhet ta rideklarojmë. Ne i humbëm të gjitha të dhënat, megjithëse kishim pasqyra me një grup të pjesshëm të dhënash. Do të ishte më mirë të kaloni në një pasqyrë jo të sinkronizuar!

Prandaj, sinkronizimi manual (dhe dështimi për të sinkronizuar) në kombinim me ha-promote-on-failure=when-synced, për mendimin tim, mjaft i rrezikshëm. Dokumentet thonë se ky opsion ekziston për sigurinë e të dhënave, por është një thikë me dy tehe.

Master ribalancimi

Siç u premtua, ne kthehemi te problemi i akumulimit të të gjithë zotërinjve në një ose disa nyje. Kjo mund të ndodhë edhe si rezultat i një përditësimi të grumbullimit të vazhdueshëm. Në një grup me tre nyje, të gjitha radhët kryesore do të grumbullohen në një ose dy nyje.

Masters ribalancimi mund të jetë problematik për dy arsye:

• Nuk ka mjete të mira për të kryer ribalancimin
• Sinkronizimi i radhës

Ekziston një palë e tretë për ribalancim plugin, e cila nuk mbështetet zyrtarisht. Në lidhje me shtojcat e palëve të treta në manualin RabbitMQ tha: “Plugina ofron disa mjete shtesë konfigurimi dhe raportimi, por nuk mbështetet ose verifikohet nga ekipi i RabbitMQ. Përdoreni në rrezikun tuaj."

Ekziston një mashtrim tjetër për të lëvizur radhën kryesore përmes politikave HA. Manuali përmend skenar për këtë. Ajo funksionon si kjo:

• Heq të gjitha pasqyrat duke përdorur një politikë të përkohshme që ka një përparësi më të lartë se politika ekzistuese HA.
• Ndryshon politikën e përkohshme HA për të përdorur modalitetin e nyjeve, duke specifikuar nyjen në të cilën duhet të transferohet radha kryesore.
• Sinkronizon radhën për migrimin e shtytjes.
• Pasi të përfundojë migrimi, fshin politikën e përkohshme. Politika fillestare HA hyn në fuqi dhe krijohet numri i kërkuar i pasqyrave.

E keqja është se kjo qasje mund të mos funksionojë nëse keni radhë të mëdha ose kërkesa strikte për tepricë.

Tani le të shohim se si grupet RabbitMQ punojnë me ndarjet e rrjetit.

Humbja e lidhjes

Nyjet e një sistemi të shpërndarë lidhen me lidhje rrjeti dhe lidhjet e rrjetit mund dhe do të shkëputen. Frekuenca e ndërprerjeve varet nga infrastruktura lokale ose besueshmëria e resë së zgjedhur. Në çdo rast, sistemet e shpërndara duhet të jenë në gjendje t'i përballojnë ato. Edhe një herë ne kemi një zgjedhje midis disponueshmërisë dhe qëndrueshmërisë, dhe përsëri lajmi i mirë është se RabbitMQ ofron të dyja opsionet (vetëm jo në të njëjtën kohë).

Me RabbitMQ kemi dy opsione kryesore:

• Lejo ndarjen logjike (tru të ndarë). Kjo siguron disponueshmërinë, por mund të shkaktojë humbje të të dhënave.
• Çaktivizo ndarjen logjike. Mund të rezultojë në humbje afatshkurtër të disponueshmërisë në varësi të mënyrës se si klientët lidhen me grupin. Mund të çojë gjithashtu në mosdisponueshmëri të plotë në një grup me dy nyje.

Por çfarë është ndarja logjike? Kjo ndodh kur një grup ndahet në dysh për shkak të humbjes së lidhjeve të rrjetit. Në çdo anë, pasqyrat promovohen në një mjeshtër, në mënyrë që përfundimisht të ketë disa mjeshtra për kthesë.

Oriz. 17. Radha kryesore dhe dy pasqyra, secila në një nyje të veçantë. Pastaj ndodh një dështim i rrjetit dhe një pasqyrë shkëputet. Nyja e ndarë sheh se dy të tjerat kanë rënë dhe i promovon pasqyrat e saj te mjeshtri. Tani kemi dy radhë kryesore, të dyja të shkruajtshme dhe të lexueshme.

Nëse botuesit u dërgojnë të dhëna të dy masterave, ne përfundojmë me dy kopje divergjente të radhës.

Mënyrat e ndryshme të RabbitMQ ofrojnë disponueshmëri ose qëndrueshmëri.

Modaliteti i injorimit (i parazgjedhur)

Kjo mënyrë siguron aksesueshmëri. Pas humbjes së lidhjes, ndodh një ndarje logjike. Pas rivendosjes së lidhjes, administratori duhet të vendosë se cilës ndarje t'i japë përparësi. Ana humbëse do të riniset dhe të gjitha të dhënat e grumbulluara në atë anë do të humbasin.

Oriz. 18. Tre botues janë të lidhur me tre ndërmjetës. Brenda, grupi i drejton të gjitha kërkesat në radhën kryesore në Broker 2.

Tani ne po humbasim Brokerin 3. Ai sheh që agjentët e tjerë kanë rënë dhe ia promovon pasqyrën e tij zotërisë. Kështu ndodh një ndarje logjike.

Oriz. 19. Ndarja logjike (split-brain). Regjistrimet shkojnë në dy radhë kryesore dhe dy kopjet ndryshojnë.

Lidhshmëria është rivendosur, por ndarja logjike mbetet. Administratori duhet të zgjedhë manualisht anën e humbur. Në rastin e mëposhtëm, administratori rinis Broker 3. Të gjitha mesazhet që ai nuk ka arritur të transmetojë humbasin.

Oriz. 20. Administratori çaktivizon Broker 3.

Oriz. 21. Administratori nis Broker 3 dhe ai bashkohet me grupin, duke humbur të gjitha mesazhet që kanë mbetur atje.

Gjatë humbjes së lidhjes dhe pas restaurimit të tij, grupi dhe kjo radhë ishin të disponueshme për lexim dhe shkrim.

Modaliteti i shërimit automatik

Funksionon në mënyrë të ngjashme me modalitetin Injoro, përveç që vetë grupi zgjedh automatikisht anën e humbur pas ndarjes dhe rivendosjes së lidhjes. Ana humbëse kthehet në grup bosh, dhe radha humbet të gjitha mesazhet që janë dërguar vetëm në atë anë.

Ndalo modalitetin e pakicës

Nëse nuk duam të lejojmë ndarjen logjike, atëherë opsioni ynë i vetëm është të heqim leximin dhe shkrimin në anën më të vogël pas ndarjes së grupit. Kur sheh ndërmjetësi që është në anën më të vogël, ai pezullon punën, domethënë mbyll të gjitha lidhjet ekzistuese dhe refuzon çdo të re. Një herë në sekondë ai kontrollon për rivendosjen e lidhjes. Pasi të rikthehet lidhja, ajo rifillon funksionimin dhe bashkohet me grupin.

Oriz. 22. Tre botues janë të lidhur me tre ndërmjetës. Brenda, grupi i drejton të gjitha kërkesat në radhën kryesore në Broker 2.

Brokerët 1 dhe 2 më pas ndahen nga Brokeri 3. Në vend që të promovojë pasqyrën e tyre në master, Broker 3 pezullohet dhe bëhet i padisponueshëm.

Oriz. 23. Broker 3 ndalon, shkëput të gjithë klientët dhe refuzon kërkesat për lidhje.

Pasi të rikthehet lidhja, ajo kthehet në grup.

Le të shohim një shembull tjetër ku radha kryesore është në Broker 3.

Oriz. 24. Radha kryesore në Broker 3.

Pastaj ndodh e njëjta humbje e lidhjes. Ndërmjetësi 3 ndalon sepse është në anën më të vogël. Në anën tjetër, nyjet shohin që Broker 3 ka rënë, kështu që pasqyra më e vjetër nga Brokers 1 dhe 2 promovohet në master.

Oriz. 25. Kaloni në Broker 2 nëse Broker 3 nuk është i disponueshëm.

Kur lidhja të rikthehet, Broker 3 do të bashkohet me grupin.

Oriz. 26. Grupi është kthyer në funksionimin normal.

Gjëja e rëndësishme për të kuptuar këtu është se ne kemi qëndrueshmëri, por mund të marrim edhe disponueshmëri, nëse Ne do të transferojmë me sukses klientët në pjesën më të madhe të seksionit. Për shumicën e situatave, unë personalisht do të zgjidhja modalitetin Pause Minority, por në të vërtetë varet nga rasti individual.

Për të siguruar disponueshmërinë, është e rëndësishme të siguroheni që klientët të lidhen me sukses me hostin. Le të shohim opsionet tona.

Sigurimi i lidhjes me klientët

Ne kemi disa opsione se si t'i drejtojmë klientët në pjesën kryesore të grupit ose në nyjet e punës (pasi një nyje dështon) pas një humbjeje të lidhjes. Së pari, le të kujtojmë se një radhë specifike është pritur në një nyje specifike, por rutimi dhe politikat përsëriten në të gjitha nyjet. Klientët mund të lidhen me çdo nyje dhe rrugëtimi i brendshëm do t'i drejtojë ata ku duhet të shkojnë. Por kur një nyje pezullohet, ajo refuzon lidhjet, kështu që klientët duhet të lidhen me një nyje tjetër. Nëse nyja bie, ai mund të bëjë fare pak.

Opsionet tona:

• Ky grup arrihet duke përdorur një balancues ngarkese që thjesht qarkullon nëpër nyje dhe klientët ripërpiqen të lidhen deri sa të kenë sukses. Nëse një nyje është e mbyllur ose e pezulluar, atëherë përpjekjet për t'u lidhur me atë nyje do të dështojnë, por përpjekjet e mëvonshme do të shkojnë në serverë të tjerë (në një mënyrë të rrumbullakët). Kjo është e përshtatshme për një humbje afatshkurtër të lidhjes ose një server të prishur që do të rikthehet shpejt.
• Hyni në grup përmes një balancuesi të ngarkesës dhe hiqni nyjet e pezulluara/të dështuara nga lista sapo të zbulohen. Nëse e bëjmë këtë shpejt dhe nëse klientët janë në gjendje të riprovojnë lidhjen, atëherë do të arrijmë disponueshmëri të vazhdueshme.
• Jepini secilit klient një listë të të gjitha nyjeve dhe klienti zgjedh rastësisht një prej tyre kur lidhet. Nëse merr një gabim kur përpiqet të lidhet, ai kalon në nyjen tjetër në listë derisa të lidhet.
• Hiqni trafikun nga një nyje e dështuar/suspenduar duke përdorur DNS. Kjo bëhet duke përdorur një TTL të vogël.

Gjetjet

Grumbullimi i RabbitMQ ka avantazhet dhe disavantazhet e veta. Disavantazhet më serioze janë se:

• kur bashkohen me një grup, nyjet hedhin poshtë të dhënat e tyre;
• bllokimi i sinkronizimit bën që radha të bëhet e padisponueshme.

Të gjitha vendimet e vështira burojnë nga këto dy karakteristika arkitekturore. Nëse RabbitMQ mund të ruante të dhëna kur grupi ribashkohet, atëherë sinkronizimi do të ishte më i shpejtë. Nëse do të ishte në gjendje të mos bllokonte sinkronizimin, do të mbështeste më mirë radhët e mëdha. Rregullimi i këtyre dy çështjeve do të përmirësonte shumë performancën e RabbitMQ si një teknologji mesazhesh tolerante ndaj gabimeve dhe shumë e disponueshme. Unë do të hezitoja të rekomandoja RabbitMQ me grupim në situatat e mëposhtme:

• Rrjet jo i besueshëm.
• Magazinim jo i besueshëm.
• Radhë shumë të gjata.

Kur bëhet fjalë për cilësimet e disponueshmërisë së lartë, merrni parasysh sa vijon:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (Ose autoheal)
• mesazhe të vazhdueshme
• Sigurohuni që klientët të lidhen me nyjen aktive kur disa nyje dështojnë

Për konsistencë (sigurinë e të dhënave), merrni parasysh cilësimet e mëposhtme:

• Botuesi konfirmon dhe mirënjohjet manuale nga ana e konsumatorit
• ha-promote-on-failure=when-synced, nëse botuesit mund të provojnë përsëri më vonë dhe nëse keni hapësirë ​​shumë të besueshme! Përndryshe vënë =always.
• ha-sync-mode=automatic (por për radhë të mëdha joaktive mund të kërkohet modaliteti manual; gjithashtu merrni parasysh nëse mosdisponueshmëria do të shkaktojë humbjen e mesazheve)
• Ndalo modalitetin e pakicës
• mesazhe të vazhdueshme

Ne nuk i kemi mbuluar ende të gjitha çështjet e tolerancës së gabimeve dhe disponueshmërisë së lartë; për shembull, si të kryhen në mënyrë të sigurt procedurat administrative (të tilla si përditësimet e vazhdueshme). Duhet të flasim edhe për federatën dhe shtojcën Shovel.

Nëse më ka munguar ndonjë gjë tjetër, ju lutem më njoftoni.

Shih edhe timin post, ku unë kryej një kërdi në një grup RabbitMQ duke përdorur Docker dhe Blockade për të testuar disa nga skenarët e humbjes së mesazheve të përshkruara në këtë artikull.

Artikujt e mëparshëm në seri:
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

Burimi: www.habr.com