Odolnosť voči chybám a vysoká dostupnosť sú veľké témy, preto budeme RabbitMQ a Kafkovi venovať samostatné články. Tento článok je o RabbitMQ a ďalší je o Kafkovi v porovnaní s RabbitMQ. Toto je dlhý článok, tak si urobte pohodlie.
Pozrime sa na stratégie tolerancie chýb, konzistencie a vysokej dostupnosti (HA) a kompromisy, ktoré každá stratégia prináša. RabbitMQ môže bežať na klastri uzlov - a potom je klasifikovaný ako distribuovaný systém. Pokiaľ ide o distribuované systémy, často hovoríme o konzistencii a dostupnosti.
Tieto pojmy popisujú, ako sa systém správa, keď zlyhá. Zlyhanie sieťového pripojenia, zlyhanie servera, porucha pevného disku, dočasná nedostupnosť servera z dôvodu hromadenia odpadu, straty paketov alebo spomalenia sieťového pripojenia. To všetko môže viesť k strate dát alebo konfliktom. Ukazuje sa, že je prakticky nemožné vytvoriť systém, ktorý by bol úplne konzistentný (žiadna strata údajov, žiadne rozdiely údajov) a zároveň dostupný (akceptuje čítanie a zápis) pre všetky scenáre zlyhania.
Uvidíme, že konzistencia a dostupnosť sú na opačných koncoch spektra a musíte si vybrať spôsob optimalizácie. Dobrou správou je, že s RabbitMQ je táto voľba možná. Máte tieto „nerdy“ páky na posunutie rovnováhy smerom k väčšej konzistencii alebo väčšej dostupnosti.
Osobitnú pozornosť budeme venovať tomu, ktoré konfigurácie vedú k strate údajov v dôsledku potvrdených záznamov. Medzi vydavateľmi, maklérmi a spotrebiteľmi existuje reťazec zodpovednosti. Akonáhle je správa prenesená k maklérovi, je jeho úlohou, aby správu nestratil. Keď maklér potvrdí vydavateľovi prijatie správy, neočakávame, že sa stratí. Uvidíme však, že sa to skutočne môže stať v závislosti od konfigurácie vášho makléra a vydavateľa.
Primitívy odolnosti jedného uzla
Odolné radenie/smerovanie
V RabbitMQ existujú dva typy frontov: trvanlivé a netrvanlivé. Všetky fronty sú uložené v databáze Mnesia. Odolné fronty sú opätovne inzerované pri spustení uzla, a tak prežijú reštarty, zlyhania systému alebo zlyhania servera (pokiaľ sú údaje zachované). To znamená, že pokiaľ vyhlásite smerovanie (výmenu) a front za odolné, infraštruktúra radenia/smerovania sa vráti do režimu online.
Nestále fronty a smerovanie sa odstránia, keď sa uzol reštartuje.
Trvalé správy
To, že je front odolný, neznamená, že všetky jeho správy prežijú reštart uzla. Iba správy nastavené vydavateľom ako utrpel (trvalý). Pretrvávajúce správy vytvárajú dodatočné zaťaženie makléra, ale ak je strata správ neprijateľná, potom neexistuje žiadna iná možnosť.
Ryža. 1. Matica udržateľnosti
Klastrovanie so zrkadlením vo fronte
Aby sme prežili stratu makléra, potrebujeme nadbytočnosť. Môžeme skombinovať viacero uzlov RabbitMQ do klastra a potom pridať ďalšiu redundanciu replikovaním frontov medzi viacerými uzlami. Týmto spôsobom, ak jeden uzol zlyhá, nestratíme dáta a zostaneme k dispozícii.
Zrkadlenie frontu:
- jeden hlavný front (master), ktorý prijíma všetky príkazy na zápis a čítanie
- jedno alebo viac zrkadiel, ktoré prijímajú všetky správy a metadáta z hlavného frontu. Tieto zrkadlá tu nie sú kvôli škálovaniu, ale čisto kvôli redundancii.
Ryža. 2. Zrkadlenie frontu
Zrkadlenie je nastavené príslušnou politikou. V ňom môžete vybrať koeficient replikácie a dokonca aj uzly, na ktorých sa má front nachádzať. Príklady:
ha-mode: allha-mode: exactly, ha-params: 2(jeden majster a jedno zrkadlo)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
Potvrdenie vydavateľa
Na dosiahnutie konzistentného záznamu sú potrebné Potvrdenia vydavateľa. Bez nich hrozí strata správ. Po zapísaní správy na disk sa vydavateľovi odošle potvrdenie. RabbitMQ nezapisuje správy na disk po prijatí, ale pravidelne, v rozsahu niekoľkých stoviek milisekúnd. Keď je front zrkadlený, potvrdenie sa odošle až potom, čo všetky zrkadlá tiež zapíšu svoju kópiu správy na disk. To znamená, že používanie potvrdení zvyšuje latenciu, ale ak je dôležitá bezpečnosť údajov, potom sú nevyhnutné.
Failover front
Keď maklér skončí alebo zlyhá, všetci vedúci frontu (master) na tomto uzle sa zrútia spolu s ním. Klaster potom vyberie najstaršie zrkadlo každého hlavného servera a povýši ho ako nový hlavný server.
Ryža. 3. Viacnásobné zrkadlené fronty a ich politiky
Broker 3 klesá. Všimnite si, že zrkadlo Queue C na Broker 2 je povýšené na master. Všimnite si tiež, že bolo vytvorené nové zrkadlo pre front C na Broker 1. RabbitMQ sa vždy pokúša zachovať replikačný faktor špecifikovaný vo vašich politikách.
Ryža. 4. Broker 3 zlyhá, čo spôsobí zlyhanie frontu C
Ďalší Broker 1 padá! Ostal nám už len jeden maklér. Zrkadlo Queue B je povýšené na master.
Obr. 5
Vrátili sme Broker 1. Bez ohľadu na to, ako dobre dáta prežijú stratu a obnovu brokera, všetky správy zrkadleného frontu sa po reštarte zahodia. Je dôležité si to uvedomiť, pretože to bude mať následky. Čoskoro sa pozrieme na tieto dôsledky. Takže Broker 1 je teraz opäť členom klastra a klaster sa snaží dodržiavať pravidlá, a preto vytvára zrkadlá na Broker 1.
V tomto prípade bola strata Brokera 1 úplná, rovnako ako údaje, takže nezrkadlený front B bol úplne stratený.
Ryža. 6. Maklér 1 sa vráti do prevádzky
Broker 3 je opäť online, takže fronty A a B získajú späť zrkadlá, ktoré sú na ňom vytvorené, aby splnili svoje zásady HA. Ale teraz sú všetky hlavné fronty na jednom uzle! To nie je ideálne, lepšia je rovnomerná distribúcia medzi uzlami. Nanešťastie tu nie je veľa možností na opätovné vyváženie majstrov. K tomuto problému sa vrátime neskôr, pretože sa najprv musíme pozrieť na synchronizáciu frontu.
Ryža. 7. Sprostredkovateľ 3 sa vráti do prevádzky. Všetky hlavné fronty na jednom uzle!
Takže teraz by ste mali mať predstavu o tom, ako zrkadlá poskytujú redundanciu a odolnosť voči chybám. To zaisťuje dostupnosť v prípade zlyhania jedného uzla a chráni pred stratou údajov. Ale ešte sme neskončili, pretože v skutočnosti je to oveľa komplikovanejšie.
synchronizácia
Pri vytváraní nového zrkadla budú všetky nové správy vždy replikované do tohto zrkadla a do všetkých ostatných. Pokiaľ ide o existujúce údaje v hlavnom fronte, môžeme ich replikovať do nového zrkadla, ktoré sa stane úplnou kópiou hlavného. Môžeme sa tiež rozhodnúť nereplikovať existujúce správy a nechať hlavný front a nové zrkadlo, aby sa v čase zbiehali, pričom nové správy prichádzajú na konci a existujúce správy opúšťajú hlavu hlavného frontu.
Táto synchronizácia sa vykonáva automaticky alebo manuálne a riadi sa pomocou politiky frontu. Pozrime sa na príklad.
Máme dva zrkadlené fronty. Front A sa synchronizuje automaticky a Front B sa synchronizuje manuálne. Oba fronty obsahujú desať správ.
Ryža. 8. Dva fronty s rôznymi režimami synchronizácie
Teraz strácame Brokera 3.
Ryža. 9. Broker 3 padol
Broker 3 sa vracia do prevádzky. Klaster vytvorí zrkadlo pre každý front na novom uzle a automaticky synchronizuje nový front A s hlavným. Zrkadlo nového frontu B však zostáva prázdne. Týmto spôsobom máme plnú redundanciu vo fronte A a iba jedno zrkadlo pre existujúce správy z frontu B.
Ryža. 10. Nové zrkadlo frontu A prijíma všetky existujúce správy, ale nové zrkadlo frontu B nie.
Do oboch radov príde ďalších desať správ. Broker 2 potom havaruje a front A sa vráti späť k najstaršiemu zrkadlu, ktoré je na Brokeri 1. Pri jeho zlyhaní nedochádza k strate údajov. Vo fronte B je dvadsať správ v hlavnom a iba desať v zrkadle, pretože tento front nikdy nereplikoval pôvodných desať správ.
Ryža. 11. Front A sa vráti späť na Broker 1 bez straty správ
Do oboch radov príde ďalších desať správ. Teraz spadne Broker 1. Front A sa ľahko prepne na zrkadlo bez straty správ. Front B má však problémy. V tomto bode môžeme optimalizovať dostupnosť alebo konzistenciu.
Ak chceme optimalizovať dostupnosť, tak politiku ha-promote-on-failure by mal byť nainštalovaný v vždy. Toto je predvolená hodnota, takže politiku jednoducho nemôžete zadať. V tomto prípade v podstate pripúšťame zlyhania v nesynchronizovaných zrkadlách. To spôsobí stratu správ, ale front zostane čitateľný a zapisovateľný.
Ryža. 12. Front A je vrátený späť do Brokera 3 bez straty správ. Front B sa vráti späť na Broker 3 s desiatimi stratenými správami
Vieme aj nainštalovať ha-promote-on-failure do významu when-synced. V tomto prípade namiesto návratu do zrkadla bude front čakať, kým sa Broker 1 so svojimi údajmi vráti do online režimu. Po návrate je hlavný front späť na Broker 1 bez straty údajov. Dostupnosť je obetovaná bezpečnosti údajov. Toto je ale riskantný režim, ktorý môže dokonca viesť k úplnej strate údajov, na čo sa čoskoro pozrieme.
Ryža. 13. Po strate Brokera 1 zostáva rad B nedostupný
Môžete sa opýtať: "Je lepšie nikdy nepoužívať automatickú synchronizáciu?" Odpoveď je, že synchronizácia je blokujúca operácia. Počas synchronizácie nemôže hlavný front vykonávať žiadne operácie čítania ani zápisu!
Pozrime sa na príklad. Teraz máme veľmi dlhé rady. Ako môžu narásť do takej veľkosti? Z niekoľkých dôvodov:
- Fronty sa aktívne nepoužívajú
- Ide o vysokorýchlostné fronty a spotrebitelia sú v súčasnosti pomalí
- Sú to vysokorýchlostné fronty, vyskytla sa chyba a spotrebitelia to doháňajú
Ryža. 14. Dva veľké fronty s rôznymi režimami synchronizácie
Teraz Broker 3 padá.
Ryža. 15. Broker 3 padá a v každom rade zostáva jeden master a mirror
Broker 3 sa vracia online a vytvárajú sa nové zrkadlá. Hlavný front A začne replikovať existujúce správy do nového zrkadla a počas tohto času je front nedostupný. Replikácia údajov trvá dve hodiny, výsledkom čoho sú dve hodiny výpadku tohto frontu!
Front B však zostáva dostupný počas celého obdobia. Pre dostupnosť obetovala určitú nadbytočnosť.
Ryža. 16. Front zostáva počas synchronizácie nedostupný
Po dvoch hodinách sa sprístupní aj front A a môže začať znova prijímať čítanie a zápis.
Aktualizácia
Toto blokujúce správanie počas synchronizácie sťažuje aktualizáciu klastrov s veľmi veľkými frontami. V určitom bode je potrebné reštartovať hlavný uzol, čo znamená buď prepnutie na zrkadlo, alebo zakázanie frontu počas aktualizácie servera. Ak sa rozhodneme pre prechod, stratíme správy, ak zrkadlá nie sú synchronizované. Štandardne sa počas výpadku sprostredkovateľa nevykonáva núdzové prepnutie na nesynchronizované zrkadlo. To znamená, že akonáhle sa maklér vráti, nestrácame žiadnu správu, jedinou škodou bola obyčajná fronta. Pravidlá správania pri odpojení makléra sú stanovené politikou ha-promote-on-shutdown. Môžete nastaviť jednu z dvoch hodnôt:
always= prechod na nesynchronizované zrkadlá je povolenýwhen-synced= prechod iba na synchronizované zrkadlo, inak sa front stane nečitateľným a nezapisovateľným. Fronta sa vráti do prevádzky hneď, ako sa maklér vráti
Tak či onak, pri veľkých frontoch si musíte vybrať medzi stratou dát a nedostupnosťou.
Keď dostupnosť zlepšuje bezpečnosť údajov
Pred rozhodnutím je potrebné zvážiť ešte jednu komplikáciu. Aj keď je automatická synchronizácia lepšia pre redundanciu, ako ovplyvňuje bezpečnosť údajov? Samozrejme, s lepšou redundanciou je menej pravdepodobné, že RabbitMQ stratí existujúce správy, ale čo nové správy od vydavateľov?
Tu je potrebné zvážiť nasledovné:
- Mohol by vydavateľ jednoducho vrátiť chybu a požiadať službu alebo používateľa, aby to skúsili znova neskôr?
- Môže vydavateľ uložiť správu lokálne alebo do databázy a skúsiť to znova neskôr?
Ak môže vydavateľ správu iba zahodiť, potom zlepšenie dostupnosti v skutočnosti zlepšuje aj bezpečnosť údajov.
Treba teda hľadať rovnováhu a riešenie závisí od konkrétnej situácie.
Problémy s ha-promote-on-failure=when-synced
Nápad ha-promote-on-failure= pri synchronizácii spočíva v tom, že zabránime prechodu na nesynchronizované zrkadlo, a tým zabránime strate údajov. Front zostáva nečitateľný alebo zapisovateľný. Namiesto toho sa snažíme obnoviť havarovaného makléra s neporušenými údajmi, aby mohol pokračovať v prevádzke ako hlavný bez straty údajov.
Ale (a to je veľké ale), ak broker stratil svoje dáta, potom máme veľký problém: fronta je stratená! Všetky údaje sú preč! Aj keď máte zrkadlá, ktoré väčšinou dobiehajú hlavný rad, tieto zrkadlá sú tiež vyradené.
Ak chcete znova pridať uzol s rovnakým názvom, povieme klastru, aby zabudol stratený uzol (pomocou príkazu rabbitmqctl forget_cluster_node) a spustite nového makléra s rovnakým názvom hostiteľa. Kým klaster si pamätá stratený uzol, pamätá si starý front a nesynchronizované zrkadlá. Keď sa klastru povie, aby zabudol na osamotený uzol, zabudne sa aj tento front. Teraz to musíme znova deklarovať. Stratili sme všetky údaje, hoci sme mali zrkadlá s čiastočným súborom údajov. Bolo by lepšie prejsť na nesynchronizované zrkadlo!
Preto manuálna synchronizácia (a zlyhanie synchronizácie) v kombinácii s ha-promote-on-failure=when-synced, podľa mňa dosť riskantné. Dokumenty hovoria, že táto možnosť existuje pre bezpečnosť údajov, ale je to dvojsečná zbraň.
Majstrovské vyvažovanie
Ako sme sľúbili, vraciame sa k problému akumulácie všetkých majstrov na jednom alebo viacerých uzloch. Môže sa to stať aj v dôsledku priebežnej aktualizácie klastra. V klastri s tromi uzlami sa všetky hlavné fronty nahromadia na jednom alebo dvoch uzloch.
Vyvažovanie masterov môže byť problematické z dvoch dôvodov:
- Neexistujú žiadne dobré nástroje na vykonanie opätovného vyváženia
- Synchronizácia frontu
Na opätovné vyváženie existuje tretia strana , ktorý nie je oficiálne podporovaný. Čo sa týka doplnkov tretích strán v príručke RabbitMQ : „Doplnok poskytuje niektoré ďalšie konfiguračné a reportovacie nástroje, ale nie je podporovaný ani overený tímom RabbitMQ. Použitie na vlastné riziko."
Existuje ďalší trik na presun hlavného frontu prostredníctvom politík HA. V príručke sa spomína pre to. Funguje to takto:
- Odstráni všetky zrkadlá pomocou dočasnej politiky, ktorá má vyššiu prioritu ako existujúca politika HA.
- Zmení dočasnú politiku HA na použitie režimu uzla, pričom určí uzol, do ktorého sa má preniesť hlavný front.
- Synchronizuje front pre migráciu push.
- Po dokončení migrácie odstráni dočasnú politiku. Nadobudne účinnosť počiatočná politika HA a vytvorí sa požadovaný počet zrkadiel.
Nevýhodou je, že tento prístup nemusí fungovať, ak máte veľké fronty alebo prísne požiadavky na redundanciu.
Teraz sa pozrime, ako fungujú klastre RabbitMQ so sieťovými oddielmi.
Strata konektivity
Uzly distribuovaného systému sú spojené sieťovými prepojeniami a sieťové prepojenia môžu byť a budú odpojené. Frekvencia výpadkov závisí od lokálnej infraštruktúry alebo spoľahlivosti zvoleného cloudu. V každom prípade si s nimi distribuované systémy musia poradiť. Opäť máme na výber medzi dostupnosťou a konzistenciou a opäť dobrou správou je, že RabbitMQ poskytuje obe možnosti (len nie súčasne).
S RabbitMQ máme dve hlavné možnosti:
- Povoliť logické delenie (split-brain). To zaisťuje dostupnosť, ale môže spôsobiť stratu údajov.
- Zakázať logické oddelenie. Môže viesť ku krátkodobej strate dostupnosti v závislosti od toho, ako sa klienti pripájajú ku klastru. Môže tiež viesť k úplnej nedostupnosti v klastri s dvoma uzlami.
Čo je však logické oddelenie? To je, keď sa klaster rozdelí na dve časti kvôli strate sieťových pripojení. Na každej strane sú zrkadlá povýšené na master, takže nakoniec je v rade niekoľko majstrov.
Ryža. 17. Hlavný rad a dve zrkadlá, každé na samostatnom uzle. Potom dôjde k zlyhaniu siete a jedno zrkadlo sa odpojí. Oddelený uzol vidí, že ďalšie dva odpadli a povýši svoje zrkadlá na master. Teraz máme dva hlavné fronty, zapisovateľné a čitateľné.
Ak vydavatelia pošlú údaje obom predlohám, skončíme s dvomi odlišnými kópiami frontu.
Rôzne režimy RabbitMQ poskytujú dostupnosť alebo konzistenciu.
Ignorovať režim (predvolené)
Tento režim zabezpečuje dostupnosť. Po strate konektivity nastáva logické oddelenie. Po obnovení pripojenia sa musí správca rozhodnúť, ktorému oddielu dá prioritu. Stratená strana sa reštartuje a všetky nahromadené údaje na tejto strane sa stratia.
Ryža. 18. Traja vydavatelia sú spojení s tromi maklérmi. Interne smeruje klaster všetky požiadavky do hlavného frontu na Broker 2.
Teraz prichádzame o makléra 3. Vidí, že ostatní makléri odpadli a povýši svoje zrkadlo na majstra. Takto dochádza k logickému oddeleniu.
Ryža. 19. Logické delenie (split-brain). Záznamy idú do dvoch hlavných radov a tieto dve kópie sa rozchádzajú.
Konektivita je obnovená, ale logické oddelenie zostáva. Správca musí manuálne vybrať stranu, ktorá prehrá. V nižšie uvedenom prípade administrátor reštartuje Broker 3. Všetky správy, ktoré nestihol preniesť, sa stratia.
Ryža. 20. Administrátor zakáže Broker 3.
Ryža. 21. Administrátor spustí Broker 3 a pripojí sa ku klastru, pričom stratí všetky správy, ktoré tam zostali.
Počas straty konektivity a po jej obnovení bol klaster a tento front k dispozícii na čítanie a zápis.
Režim autoheal
Funguje podobne ako režim Ignorovať, až na to, že samotný klaster si po rozdelení a obnovení konektivity automaticky vyberie stranu, ktorá stratí. Prehrávajúca strana sa vráti do klastra prázdna a front stratí všetky správy, ktoré boli odoslané iba tejto strane.
Pozastaviť menšinový režim
Ak nechceme povoliť logické delenie, tak našou jedinou možnosťou je zahodiť čítanie a zápis na menšiu stranu za klastrovým oddielom. Keď maklér vidí, že je na menšej strane, pozastaví prácu, to znamená, že uzavrie všetky existujúce spojenia a odmietne akékoľvek nové. Raz za sekundu skontroluje obnovenie pripojenia. Po obnovení pripojenia obnoví prevádzku a pripojí sa ku klastru.
Ryža. 22. Traja vydavatelia sú spojení s tromi maklérmi. Interne smeruje klaster všetky požiadavky do hlavného frontu na Broker 2.
Brokeri 1 a 2 sa potom oddelia od Brokera 3. Namiesto povýšenia svojho zrkadla na master sa Broker 3 pozastaví a stane sa nedostupným.
Ryža. 23. Broker 3 pozastaví, odpojí všetkých klientov a odmietne požiadavky na pripojenie.
Po obnovení pripojenia sa vráti do klastra.
Pozrime sa na ďalší príklad, kde je hlavný front na Broker 3.
Ryža. 24. Hlavný rad na Broker 3.
Potom dôjde k rovnakej strate pripojenia. Broker 3 sa pozastaví, pretože je na menšej strane. Na druhej strane uzly vidia, že Broker 3 spadol, takže staršie zrkadlo z Brokerov 1 a 2 je povýšené na master.
Ryža. 25. Prechod na Broker 2, ak je Broker 3 nedostupný.
Po obnovení pripojenia sa Broker 3 pripojí ku klastru.
Ryža. 26. Klaster sa vrátil do normálnej prevádzky.
Tu je dôležité pochopiť, že získame konzistentnosť, ale môžeme tiež získať dostupnosť, ak Klientov úspešne prevedieme na väčšinu sekcie. Pre väčšinu situácií by som si osobne vybral režim Pause Minority, ale naozaj záleží na konkrétnom prípade.
Na zabezpečenie dostupnosti je dôležité zabezpečiť, aby sa klienti úspešne pripojili k hostiteľovi. Pozrime sa na naše možnosti.
Zabezpečenie konektivity zákazníka
Máme viacero možností, ako klientov po výpadku konektivity nasmerovať do hlavnej časti klastra alebo do fungujúcich uzlov (po výpadku jedného uzla). Najprv si pamätajme, že konkrétny front je umiestnený na konkrétnom uzle, ale smerovanie a politiky sú replikované vo všetkých uzloch. Klienti sa môžu pripojiť k akémukoľvek uzlu a interné smerovanie ich nasmeruje tam, kam potrebujú. Ale keď je uzol pozastavený, odmieta pripojenia, takže klienti sa musia pripojiť k inému uzlu. Ak uzol odpadne, môže urobiť len málo.
Naše možnosti:
- Ku klastru sa pristupuje pomocou nástroja na vyvažovanie záťaže, ktorý jednoducho cyklicky prechádza cez uzly a klienti sa znova pokúšajú pripojiť, kým nebudú úspešné. Ak je uzol vypnutý alebo pozastavený, pokusy o pripojenie k tomuto uzlu zlyhajú, ale následné pokusy prejdú na iné servery (v režime round-robin). To je vhodné pre krátkodobú stratu pripojenia alebo výpadok servera, ktorý bude rýchlo obnovený.
- Vstúpte do klastra cez nástroj na vyrovnávanie záťaže a odstráňte pozastavené/zlyhané uzly zo zoznamu hneď, ako budú zistené. Ak to urobíme rýchlo a ak klienti budú môcť znova skúsiť pripojenie, dosiahneme stálu dostupnosť.
- Dajte každému klientovi zoznam všetkých uzlov a klient si pri pripájaní náhodne vyberie jeden z nich. Ak pri pokuse o pripojenie dostane chybu, presunie sa na ďalší uzol v zozname, kým sa nepripojí.
- Odstráňte prenos zo zlyhaného/pozastaveného uzla pomocou DNS. To sa vykonáva pomocou malého TTL.
Závery
Klastrovanie RabbitMQ má svoje výhody a nevýhody. Najzávažnejšie nevýhody sú:
- pri pripájaní sa do klastra uzly zahodia svoje údaje;
- blokovanie synchronizácie spôsobí, že sa front stane nedostupným.
Všetky ťažké rozhodnutia vychádzajú z týchto dvoch architektonických prvkov. Ak by RabbitMQ mohol uložiť údaje pri opätovnom pripojení klastra, synchronizácia by bola rýchlejšia. Ak by bol schopný neblokujúcej synchronizácie, lepšie by podporoval veľké fronty. Oprava týchto dvoch problémov by výrazne zlepšila výkon RabbitMQ ako technológie odolnej voči chybám a vysoko dostupnej technológie na odosielanie správ. Váhal by som odporučiť RabbitMQ s klastrovaním v nasledujúcich situáciách:
- Nespoľahlivá sieť.
- Nespoľahlivé skladovanie.
- Veľmi dlhé rady.
Pokiaľ ide o nastavenia vysokej dostupnosti, zvážte nasledovné:
ha-promote-on-failure=alwaysha-sync-mode=manualcluster_partition_handling=ignore(Aleboautoheal)- pretrvávajúce správy
- zabezpečiť pripojenie klientov k aktívnemu uzlu, keď niektorý uzol zlyhá
Pre konzistenciu (zabezpečenie údajov) zvážte nasledujúce nastavenia:
- Potvrdenia vydavateľa a manuálne potvrdenia na strane spotrebiteľa
ha-promote-on-failure=when-synced, ak to vydavatelia môžu skúsiť znova neskôr a ak máte veľmi spoľahlivé úložisko! Inak povedané=always.ha-sync-mode=automatic(ale pre veľké neaktívne fronty môže byť potrebný manuálny režim; tiež zvážte, či nedostupnosť spôsobí stratu správ)- Pozastaviť menšinový režim
- pretrvávajúce správy
Ešte sme nepokryli všetky otázky odolnosti voči chybám a vysokej dostupnosti; napríklad ako bezpečne vykonávať administratívne procedúry (ako sú priebežné aktualizácie). Musíme tiež hovoriť o federácii a doplnku Shovel.
Ak som ešte niečo vynechal, dajte mi vedieť.
Pozri aj moje , kde robím zmätok na klastri RabbitMQ pomocou Docker a Blockade na testovanie niektorých scenárov straty správ opísaných v tomto článku.
Predchádzajúce články zo série:
č. 1 -
č. 2 -
č. 3 -
Zdroj: hab.com