Foutverdraagsaamheid en hoë beskikbaarheid is groot onderwerpe, daarom sal ons aparte artikels aan RabbitMQ en Kafka wy. Hierdie artikel handel oor RabbitMQ en die volgende een handel oor Kafka versus RabbitMQ. Die artikel is lank, so maak jouself gemaklik.

Kom ons kyk na fouttoleransie, konsekwentheid en hoë beskikbaarheid (HA) strategieë en die afwegings wat elke strategie moet maak. RabbitMQ kan op 'n groep nodusse loop - en dan word dit as 'n verspreide stelsel geklassifiseer. Wanneer dit by verspreide stelsels kom, praat ons dikwels oor konsekwentheid en beskikbaarheid.

Hierdie konsepte beskryf hoe die stelsel optree wanneer dit misluk. Netwerkverbindingsfout, bedienerfout, hardeskyffout, bediener tydelike onbeskikbaarheid as gevolg van vullisversameling, pakkieverlies of netwerkverbinding verlangsaming. Dit alles kan lei tot dataverlies of konflikte. Dit blyk dat dit byna onmoontlik is om 'n stelsel in te samel wat beide heeltemal konsekwent is (geen dataverlies, geen data-teenstrydigheid) en beskikbaar (sal lees en skryf aanvaar) vir alle mislukkingscenario's.

Ons sal sien dat konsekwentheid en beskikbaarheid aan verskillende kante van die spektrum is, en jy moet kies watter manier om te optimaliseer. Die goeie nuus is dat met RabbitMQ hierdie keuse moontlik is. Jy het 'n soort "nerdish" hefbome om die balans na meer konsekwentheid of meer toeganklikheid te verskuif.

Ons sal spesiale aandag gee aan watter konfigurasies lei tot dataverlies as gevolg van erkende skryfwerk. Daar is 'n ketting van verantwoordelikheid tussen uitgewers, makelaars en verbruikers. Nadat die boodskap aan die makelaar deurgegee is, is dit sy taak om nie die boodskap te verloor nie. Wanneer 'n makelaar 'n boodskap aan 'n uitgewer erken, verwag ons nie dat dit verlore gaan nie. Maar ons sal sien dat dit eintlik kan gebeur, afhangende van die konfigurasie van jou makelaar en uitgewer.

Enkelnode Veerkragtigheid Primitiewe

Duursame toue/roetering

Daar is twee tipes tou in RabbitMQ: duursaam/stabiel (duursaam) en onstabiel (nie-duursaam). Alle toue word in die Mnesia-databasis gestoor. Duursame toue word herverklaar by die opstart van die nodus en oorleef dus 'n herbegin, stelselongeluk of bedienerongeluk (solank die data voortduur). Dit beteken dat solank as wat jy roetering (uitruil) en die tou aanhoudend verklaar, die tou-/roetering-infrastruktuur weer aanlyn sal kom.

Vlugtige toue en roetering word verwyder wanneer die nodus herbegin word.

Volhoubare boodskappe

Net omdat 'n tou duursaam is, beteken dit nie dat al sy boodskappe 'n knoopherbegin sal oorleef nie. Slegs boodskappe gestel deur die uitgewer as volhoubaar (aanhoudend). Aanhoudende boodskappe plaas wel bykomende las op die makelaar, maar as boodskapverlies onaanvaarbaar is, is daar geen ander opsie nie.

Rys. 1. Stabiliteitsmatriks

Groepering met tou-spieëling

Om die verlies van 'n makelaar te oorleef, het ons oortolligheid nodig. Ons kan verskeie RabbitMQ-nodusse groepeer en dan bykomende oortolligheid byvoeg deur rye oor verskeie nodusse te repliseer. Dus, as een nodus afgaan, verloor ons nie data nie en bly ons beskikbaar.

Waglysspieëling:

• een hooftou (meester) wat alle skryf- en leesopdragte ontvang
• een of meer spieëls wat alle boodskappe en metadata van die hoofry ontvang. Hierdie spieëls bestaan ​​nie vir skaal nie, maar suiwer vir oortolligheid.

Rys. 2. Spieël die tou

Spieëling word bepaal deur die toepaslike beleid. Daarin kan u die replikasiefaktor kies en selfs die nodusse waarop die tou geplaas moet word. Voorbeelde:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (een meester en een spieël)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Uitgewer bevestiging

Uitgewerbevestigings word vereis om konsekwente skryfwerk te verkry. Sonder hulle is daar 'n kans om boodskappe te verloor. 'n Erkenning word aan die uitgewer gestuur nadat die boodskap op skyf geskryf is. RabbitMQ skryf boodskappe na skyf nie by ontvangs nie, maar op 'n periodieke basis, in die omgewing van 'n paar honderd millisekondes. Wanneer 'n tou weerspieël word, word 'n erkenning eers gestuur nadat alle spieëls ook hul kopie van die boodskap op skyf geskryf het. Dit beteken dat die gebruik van bevestigings latensie byvoeg, maar as datasekuriteit belangrik is, is dit nodig.

Misluktou

Wanneer 'n makelaar afskakel of ineenstort, val alle touleiers (meesters) op daardie nodus daarmee af. Die groepie kies dan die oudste spieël van elke meester en bevorder dit as die nuwe meester.

Rys. 3. Veelvuldige spieëlrye en hul beleide

Makelaar 3 ineenstort. Let daarop dat die spieël van Tou C op Broker 2 bevorder word om te bemeester. Let ook daarop dat 'n nuwe spieël geskep is vir Tou C op Makelaar 1. RabbitMQ probeer altyd om die replikasiefaktor te handhaaf wat in jou polisse gespesifiseer word.

Rys. 4. Makelaar 3 val af, wat veroorsaak dat tou C misluk

Die volgende Broker 1 is af! Ons het net een makelaar oor. Die spieël van Tou B word bevorder tot die meester.

Fig. 5

Ons het Broker 1 teruggekeer. Maak nie saak hoe goed die data die verlies en herstel van die makelaar oorleef het nie, alle weerspieëlde touboodskappe word met herbegin weggegooi. Dit is belangrik om daarop te let aangesien daar gevolge sal wees. Ons sal hierdie implikasies binnekort hersien. Makelaar 1 is dus nou weer 'n lid van die groepering, en die groep probeer om aan die beleide te voldoen en skep dus spieëls op Makelaar 1.

In hierdie geval was die verlies van Broker 1 volledig, asook die verlies van data, dus is die nie-gespieëlde tou B heeltemal verlore.

Rys. 6. Makelaar 1 keer terug na diens

Makelaar 3 is terug aanlyn, so toue A en B kry hul spieëls terug om hul HA-beleide te bevredig. Maar nou is alle meester-toue op dieselfde nodus! Dit is nie perfek nie, dit is beter om 'n eenvormige verspreiding tussen die nodusse te hê. Ongelukkig is daar geen spesifieke opsies vir herbalansering van meesters nie. Ons sal later na hierdie probleem terugkom, aangesien ons eers tou-sinchronisasie moet oorweeg.

Rys. 7. Makelaar 3 keer terug na diens. Alle meester-toue op een nodus!

U behoort dus nou 'n idee te hê van hoe spieëls oortolligheid en fouttoleransie bied. Dit verseker beskikbaarheid in die geval van 'n enkele nodus mislukking en beskerm teen dataverlies. Maar ons is nog nie klaar nie, want eintlik is alles baie meer ingewikkeld.

sinchronisasie

Wanneer 'n nuwe spieël geskep word, sal alle nuwe boodskappe altyd na daardie spieël en enige ander gerepliseer word. Wat die bestaande data in die hoofry betref, kan ons dit na 'n nuwe spieël herhaal, wat 'n volledige kopie van die meester word. Ons kan ook kies om nie bestaande boodskappe te herhaal nie en toelaat dat die hooftou en die nuwe spieël konvergeer op die tyd wanneer nuwe boodskappe die stert binnekom en bestaande boodskappe die hoof van die hooftou verlaat.

Hierdie sinchronisasie is outomaties of handmatig en word beheer deur 'n toustaanbeleid. Oorweeg 'n voorbeeld.

Ons het twee spieëlrye. Tou A word outomaties gesinchroniseer, terwyl tou B met die hand gesinchroniseer word. Albei rye bevat tien boodskappe.

Rys. 8. Twee toue met verskillende tydsberekeningmodusse

Nou verloor ons Broker 3.

Rys. 9. Makelaar 3 het afgegaan

Makelaar 3 is weer in diens. Die groep skep 'n spieël vir elke tou op die nuwe nodus en sinchroniseer outomaties die nuwe tou A met die meester. Die spieël van die nuwe Tou B bly egter leeg. Dus, ons het volle oortolligheid van tou A en slegs een spieël vir die bestaande boodskappe van tou B.

Rys. 10. Die nuwe spieël van tou A ontvang alle bestaande boodskappe, maar die nuwe spieël van tou B nie

Albei rye ontvang nog tien boodskappe. Makelaar 2 gaan dan af, en Tou A val terug na die oudste spieël, wat op Makelaar 1 is. Daar is geen dataverlies wanneer dit misluk nie. Tou B het twintig boodskappe in die meester en slegs tien in die spieël, want daardie tou het nooit die oorspronklike tien boodskappe herhaal nie.

Rys. 11. Tou A word teruggerol deur Makelaar 1 sonder boodskapverlies

Albei rye ontvang elk nog tien boodskappe. Makelaar 1 val nou ineen. Tou A misluk na die spieël sonder enige boodskapverlies. Tou B het egter probleme. Op hierdie stadium kan ons óf beskikbaarheid óf konsekwentheid optimaliseer.

As ons beskikbaarheid wil optimaliseer, dan is die beleid ha-bevorder-op-mislukking geïnstalleer moet word in altyd. Dit is die verstekwaarde, so jy kan eenvoudig glad nie die beleid spesifiseer nie. In so 'n geval laat ons in werklikheid mislukkings toe in spieëls wat nie gesinkroniseer is nie. Dit sal veroorsaak dat boodskappe verlore gaan, maar die tou bly leesbaar en skryfbaar.

Rys. 12. Tou A word teruggerol na Makelaar 3 sonder boodskapverlies. Tou B val terug na Broker 3 met tien boodskappe verlore

Ons kan ook installeer ha-promote-on-failure tot betekenis when-synced. In hierdie geval, in plaas daarvan om terug te rol na die spieël, sal die tou wag totdat Broker 1 aanlyn terugkeer met sy data. Nadat dit teruggekeer het, is die hoofry terug op Broker 1 sonder dataverlies. Beskikbaarheid word opgeoffer vir datasekuriteit. Maar dit is 'n riskante modus, wat selfs tot volledige dataverlies kan lei, wat ons binnekort sal oorweeg.

Rys. 13. Tou B bly onbeskikbaar nadat jy Makelaar 1 verloor het

Jy kan die vraag vra: "Miskien is dit beter om nooit outomatiese sinchronisasie te gebruik nie?". Die antwoord is dat sinchronisasie 'n blokkeerbewerking is. Tydens sinchronisasie kan die hooftou geen lees- of skryfbewerkings uitvoer nie!

Oorweeg 'n voorbeeld. Nou het ons baie lang toue. Hoe kan hulle tot so 'n grootte groei? Om verskeie redes:

• Toue word nie aktief gebruik nie
• Dit is hoëspoed-toue, en op die oomblik hardloop verbruikers stadig.
• Dit is hoëspoed-toue, daar was 'n mislukking en verbruikers haal die agterstand in

Rys. 14. Twee groot toue met verskillende tydsberekeningmodusse

Makelaar 3 val nou ineen.

Rys. 15. Makelaar 3 ineenstort wat een meester en spieël in elke tou laat

Broker 3 kom terug aanlyn en nuwe spieëls word geskep. Meesterwag A begin bestaande boodskappe na die nuwe spieël repliseer, en gedurende hierdie tyd is die waglys nie beskikbaar nie. Dit neem twee uur om data te repliseer, wat lei tot twee uur se stilstand vir hierdie tou!

Tou B bly egter regdeur die tydperk beskikbaar. Sy het 'n mate van oortolligheid opgeoffer vir toeganklikheid.

Rys. 16. Tou bly onbeskikbaar tydens sinchronisasie

Na twee uur word Tou A ook beskikbaar en kan lees en skryf weer begin aanvaar.

Updates

Hierdie blokkeergedrag tydens sinchronisasie maak dit moeilik om groepe met baie groot rye op te dateer. Op 'n sekere punt moet die hoofnodus herbegin word, wat beteken dat jy óf na die spieël gaan óf die tou afskakel tydens die bedieneropgradering. As ons kies om oor te skakel, sal ons boodskappe verloor as die spieëls nie gesinchroniseer is nie. By verstek, tydens 'n makelaaronderbreking, word failover na 'n buite-gesinkroniseerde spieël nie uitgevoer nie. Dit beteken dat sodra die makelaar terugkom, ons geen boodskappe verloor nie, die enigste skade was net 'n eenvoudige tou. Die gedragsreëls wanneer die makelaar ontkoppel word, word deur die beleid bepaal ha-promote-on-shutdown. Jy kan een van twee waardes stel:

• always= Failover na ongesinchroniseerde spieëls geaktiveer
• when-synced= Skuif slegs na 'n gesinchroniseerde spieël, anders word die tou onleesbaar en skryfbaar. Die tou keer terug na diens sodra die makelaar terugkeer

Op een of ander manier, met groot toue, moet jy kies tussen dataverlies en onbeskikbaarheid.

Wanneer beskikbaarheid datasekuriteit verbeter

Daar is nog een komplikasie om te oorweeg voordat 'n besluit geneem word. Alhoewel outomatiese sinkronisering beter is vir oortolligheid, hoe beïnvloed dit datasekuriteit? Natuurlik, met beter oortolligheid, is RabbitMQ minder geneig om bestaande boodskappe te verloor, maar wat van nuwe boodskappe van uitgewers?

Hier moet jy die volgende in ag neem:

• Kan die uitgewer net 'n fout terugstuur en die stroomopdiens of gebruiker later weer laat probeer?
• Kan die uitgewer die boodskap plaaslik of in die databasis stoor om later weer te probeer?

As die uitgewer slegs die boodskap kan weggooi, verbeter die toeganklikheid in werklikheid ook datasekuriteit.

Daar moet dus 'n balans gesoek word, en die besluit hang af van die spesifieke situasie.

Probleme met ha-promote-on-failure=wanneer gesinkroniseer

Idee ha-bevorder-op-mislukking= wanneer gesinkroniseer is dat ons verhoed dat ons na 'n ongesinchroniseerde spieël oorskakel en sodoende dataverlies vermy. Die tou bly onleesbaar of skryfbaar. In plaas daarvan probeer ons om die gevalle makelaar met ongeskonde data terug te bring sodat dit as 'n meester kan hervat sonder dataverlies.

Maar (en dit is 'n groot maar) as die makelaar sy data verloor het, dan het ons 'n groot probleem: die tou is verlore! Alle data is weg! Selfs as jy spieëls het wat meestal die hooftou inhaal, word daardie spieëls ook weggegooi.

Om 'n nodus met dieselfde naam weer by te voeg, sê ons vir die groep om die weesknoop te vergeet (met rabbitmqctl vergeet_cluster_node) en begin 'n nuwe makelaar met dieselfde gasheernaam. Terwyl die groepering die verlore knoop onthou, onthou dit die ou tou en spieëls wat nie gesinkroniseer is nie. Wanneer die groep aangesê word om 'n verlore knoop te vergeet, word hierdie tou ook vergeet. Nou moet ons dit weer verklaar. Ons het alle data verloor al het ons spieëls met 'n gedeeltelike stel data gehad. Dit sal beter wees om na 'n ongesinchroniseerde spieël oor te skakel!

Daarom, handmatige sinchronisasie (en versuim om te sinchroniseer) in kombinasie met ha-promote-on-failure=when-syncednogal riskant na my mening. Die dokumente sê hierdie opsie bestaan ​​vir datasekuriteit, maar dit is 'n tweesnydende mes.

Bemeester herbalansering

Soos belowe, keer ons terug na die probleem van die ophoping van alle meesters op een of meer nodusse. Dit kan selfs gebeur as gevolg van 'n deurlopende opdatering van die groepering. In 'n drie-nodus-kluster sal alle meester-toue op een of twee nodusse ophoop.

Herbalansering van meesters kan om twee redes problematies wees:

• Daar is geen goeie gereedskap om herbalansering uit te voer nie
• Tou-sinchronisasie

Daar is 'n derde party vir herbalansering plugin, wat nie amptelik ondersteun word nie. Met betrekking tot derdeparty-inproppe in die RabbitMQ-handleiding gesê: "Die inprop verskaf 'n paar bykomende konfigurasie- en verslagdoeningsnutsgoed, maar word nie deur die RabbitMQ-span ondersteun of getoets nie. Gebruik op eie risiko."

Daar is nog 'n truuk om die hooftou deur HA-beleide te skuif. Die handleiding noem skrif vir dit. Dit werk so:

• Verwyder alle spieëls deur 'n tydelike beleid met 'n hoër prioriteit as die bestaande HA-beleid te gebruik.
• Verander die HA-tydelike beleid om "nodes"-modus te gebruik, en spesifiseer die nodus waarheen jy die hooftou wil skuif.
• Sinkroniseer die tou vir gedwonge migrasie.
• Nadat die migrasie voltooi is, vee dit die tydelike beleid uit. Die oorspronklike HA-beleid tree in werking en die vereiste aantal spieëls word geskep.

Die nadeel is dat hierdie benadering dalk nie werk as jy groot toue of streng oortolligheidsvereistes het nie.

Kom ons kyk nou hoe RabbitMQ-klusters met netwerkpartisies werk.

Verbindingsontwrigting

Die nodusse van 'n verspreide stelsel word deur netwerkskakels verbind, en netwerkskakels kan en sal ontkoppel word. Die frekwensie van onderbrekings hang af van die plaaslike infrastruktuur of die betroubaarheid van die geselekteerde wolk. Hoe dit ook al sy, verspreide stelsels behoort dit te kan hanteer. Weereens het ons 'n keuse tussen beskikbaarheid en konsekwentheid, en weereens is die goeie nuus dat RabbitMQ albei opsies bied (net nie op dieselfde tyd nie).

Met RabbitMQ het ons twee hoofopsies:

• Laat logiese skeiding toe (gesplete brein). Dit verseker beskikbaarheid, maar kan dataverlies veroorsaak.
• Deaktiveer logiese skeiding. Kan 'n korttermynverlies aan beskikbaarheid tot gevolg hê, afhangende van hoe kliënte aan die groep koppel. Dit kan ook volledige onbeskikbaarheid in 'n twee-node-kluster veroorsaak.

Maar wat is logiese skeiding? Dit is wanneer die groepering in twee verdeel as gevolg van die verlies van netwerkskakels. Aan elke kant word die spieëls na die meester bevorder, sodat daar uiteindelik verskeie meesters per tou is.

Rys. 17. Hooftou en twee spieëls, elk op 'n aparte nodus. Dan is daar 'n netwerkfout en een spieël word geskei. Die losstaande nodus sien dat die ander twee afgeval het en beweeg sy spieëls na die meester. Ons het nou twee hoofrye, wat albei leesbaar en skryfbaar is.

As uitgewers data aan beide meesters stuur, sal ons twee uiteenlopende kopieë van die tou hê.

Verskillende modusse van RabbitMQ bied óf beskikbaarheid óf konsekwentheid.

Ignoreer modus (verstek)

Hierdie modus bied toeganklikheid. Na die verlies van konnektiwiteit vind 'n logiese skeiding plaas. Nadat konnektiwiteit herstel is, moet die administrateur besluit watter partisie om te prioritiseer. Die verloorkant sal herbegin word en alle opgehoopte data van daardie kant af gaan verlore.

Rys. 18. Drie uitgewers is geaffilieer met drie makelaars. Intern lei die groepering alle versoeke na die hoofry op Broker 2.

Nou verloor ons Broker 3. Hy sien die ander makelaars het afgeval en beweeg sy spieël na die meester. Dit is hoe die logiese skeiding plaasvind.

Rys. 19. Logiese verdeling (gesplete brein). Die rekords gaan na die twee hoofrye, en die twee kopieë gaan uit.

Konnektiwiteit word herstel, maar die logiese skeiding bly. Die administrateur moet die verloorparty met die hand kies. In die volgende geval herbegin die administrateur Broker 3. Alle boodskappe wat dit nie tyd gehad het om te stuur nie, gaan verlore.

Rys. 20. Administrateur deaktiveer Makelaar 3.

Rys. 21. Administrateur begin Broker 3 en dit sluit by die groep aan, en verloor alle boodskappe wat daar gelaat is.

Tydens die verlies van konnektiwiteit en na die herstel daarvan, was die cluster en hierdie tou beskikbaar vir lees en skryf.

Autoheal-modus

Werk soortgelyk aan Ignoreer-modus, behalwe dat die groepering self outomaties die verloorkant kies nadat dit verdeel en weer gekoppel is. Die verloorkant keer terug na die leë groepie, en die tou verloor alle boodskappe wat net aan daardie kant gestuur is.

Onderbreek die geringe modus

As ons nie logiese partisionering wil toelaat nie, dan is ons enigste opsie om te weier om aan die kleiner kant na die groeppartisie te lees en te skryf. Wanneer die makelaar sien dat dit aan die kleiner kant is, skort dit werk op, dit wil sê, sluit alle bestaande verbindings en weier enige nuwes. Een keer per sekonde kyk dit vir herverbinding. Sodra konnektiwiteit herstel is, hervat dit werk en sluit dit by die groep aan.

Rys. 22. Drie uitgewers is geaffilieer met drie makelaars. Intern lei die groepering alle versoeke na die hoofry op Broker 2.

Makelaars 1 en 2 skei dan van Makelaar 3. In plaas daarvan om sy spieël te bevorder om te bemeester, breek Makelaar 3 en word onbeskikbaar.

Rys. 23. Makelaar 3 skort, ontkoppel alle kliënte en verwerp verbindingsversoeke.

Sodra konnektiwiteit herstel is, keer dit terug na die groepering.

Kom ons kyk na nog 'n voorbeeld waar die hoofry op Broker 3 is.

Rys. 24. Hooftou by Makelaar 3.

Dan vind dieselfde verlies aan konnektiwiteit plaas. Makelaar 3 pouses omdat dit aan die kleiner kant is. Aan die ander kant sien die nodusse dat Broker 3 afgeval het, so die ouer spieël van Brokers 1 en 2 word bevorder tot meester.

Rys. 25. Skakel oor na Makelaar 2 wanneer Makelaar 3 nie beskikbaar is nie.

Wanneer konnektiwiteit herstel word, sal Broker 3 by die groep aansluit.

Rys. 26. Die groep het teruggekeer na normale werking.

Dit is belangrik om hier te verstaan ​​dat ons konsekwentheid kry, maar ons kan ook toeganklikheid kry, indien ons sal kliënte suksesvol na die grootste deel van die afdeling oorplaas. Vir die meeste situasies sou ek persoonlik die Pouse Minority-modus kies, maar dit hang regtig van die individuele geval af.

Om beskikbaarheid te verseker, is dit belangrik om te verseker dat kliënte suksesvol aan die gasheer koppel. Kom ons kyk na ons opsies.

Verseker kliënt konnektiwiteit

Ons het verskeie opsies vir hoe om kliënte na die hoofgedeelte van die groepering of na werkende nodusse te lei na 'n verlies aan konnektiwiteit (na 'n mislukking van een nodus). Eerstens, laat ons onthou dat 'n spesifieke tou op 'n spesifieke nodus gehuisves word, maar roetering en beleide word oor alle nodusse gerepliseer. Kliënte kan aan enige nodus koppel, en interne roetering sal hulle lei waarheen hulle moet gaan. Maar wanneer 'n nodus onderbreek word, verwerp dit verbindings, sodat kliënte aan 'n ander nodus moet koppel. As die nodus afgeval het, kan dit min doen.

Ons opsies:

• Die groep word verkry deur 'n lasbalanseerder wat eenvoudig deur die nodusse blaai en die kliënte probeer weer koppel totdat dit suksesvol is. As 'n nodus af is of opgeskort is, sal pogings om aan daardie nodus te koppel misluk, maar daaropvolgende pogings sal na ander bedieners gaan (op 'n rondomtalie manier). Dit is geskik vir 'n kortstondige verlies van konneksie of 'n afgelaaide bediener wat vinnig na vore gebring sal word.
• Toegang tot die groepering via 'n lasbalanseerder en verwydering van opgeskorte/gevalle nodusse van die lys sodra hulle opgespoor word. As dit vinnig gedoen word, en as kliënte in staat is om weer verbinding te probeer, dan sal ons konstante beskikbaarheid kry.
• Gee vir elke kliënt 'n lys van alle nodusse, en die kliënt kies lukraak een van hulle wanneer dit verbind. As dit 'n fout kry terwyl hy probeer om te koppel, skuif dit na die volgende nodus in die lys totdat dit verbind.
• Verwyder verkeer van 'n afgelaaide/geskorste gasheer met DNS. Dit word gedoen met 'n klein TTL.

Bevindinge

RabbitMQ-groepering het sy voordele en nadele. Die ernstigste nadele is dat:

• wanneer hulle by 'n groep aansluit, gooi nodusse hul data weg;
• blokkering van sinchronisasie veroorsaak dat die tou onbeskikbaar raak.

Alle moeilike besluite spruit uit hierdie twee argitektoniese kenmerke. As RabbitMQ data kon stoor wanneer hy weer by die groep aansluit, sou sinchronisasie vinniger wees. As dit in staat was om sinchronisasie nie te blokkeer nie, sou dit groot rye beter ondersteun. Om hierdie twee probleme reg te stel, sal RabbitMQ se werkverrigting as 'n foutverdraagsame en hoogs beskikbare boodskaptegnologie aansienlik verbeter. Ek sal huiwerig wees om RabbitMQ met groepering in die volgende situasies aan te beveel:

• Onbetroubare netwerk.
• Onbetroubare berging.
• Baie lang rye.

Wat instellings vir hoë beskikbaarheid betref, oorweeg hierdie:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (Of autoheal)
• volhoubare boodskappe
• maak seker dat kliënte aan die aktiewe nodus koppel wanneer een of ander nodus afgaan

Vir konsekwentheid (datasekuriteit), oorweeg die volgende instellings:

• Uitgewer bevestig en handmatige erkennings aan die verbruikerskant
• ha-promote-on-failure=when-syncedas uitgewers later weer kan probeer en as jy baie sterk berging het! Anders gestel =always.
• ha-sync-mode=automatic (maar groot onaktiewe toue kan handmatige modus vereis; oorweeg ook of onbeskikbaarheid boodskappe sal laat verlore gaan)
• Onderbreek minderheidsmodus
• volhoubare boodskappe

Ons het nog nie al die kwessies van foutverdraagsaamheid en hoë beskikbaarheid gedek nie; byvoorbeeld, hoe om administratiewe prosedures veilig uit te voer (soos deurlopende opdaterings). Ons moet ook praat oor federasie en die Shovel-inprop.

As ek nog iets gemis het, laat weet my asseblief.

Sien ook myne postwaar ek 'n RabbitMQ-kluster met Docker en Blockade pogrommer om sommige van die boodskapverlies-scenario's wat in hierdie artikel beskryf word, te toets.

Vorige artikels in die reeks:
No. 1 - habr.com/ru/company/itsumma/blog/416629
No. 2 - habr.com/ru/company/itsumma/blog/418389
No. 3 - habr.com/ru/company/itsumma/blog/437446

Bron: will.com