Feeler Toleranz an héich Disponibilitéit si grouss Themen, also wäerte mir separat Artikelen op RabbitMQ a Kafka widmen. Dësen Artikel ass iwwer RabbitMQ, an deen nächsten ass iwwer Kafka, am Verglach mat RabbitMQ. Dëst ass e laangen Artikel, also maacht Iech bequem.
Loosst eis d'Feeltoleranz, d'Konsistenz an d'High Disponibilitéit (HA) Strategien kucken an d'Ofdreiwungen déi all Strategie mécht. RabbitMQ kann op engem Cluster vun Wirbelen lafen - a gëtt dann als verdeelt System klasséiert. Wann et ëm verdeelt Systemer geet, schwätze mir dacks iwwer Konsistenz an Disponibilitéit.
Dës Konzepter beschreiwen wéi e System sech behält wann et feelt. Netzverbindungsfehler, Serverfehler, Festplackfehler, Server temporär Onverfügbarkeet wéinst Müllsammlung, Paketverloscht oder Netzverbindung verlangsamt. All dëst kann zu Datenverloscht oder Konflikter féieren. Et stellt sech eraus datt et quasi onméiglech ass e System opzestellen, dee souwuel komplett konsequent ass (keng Dateverloscht, keng Datendivergenz) a verfügbar ass (liest a schreift akzeptéiert) fir all Ausfallszenarie.
Mir wäerte gesinn datt d'Konsistenz an d'Disponibilitéit op de Géigendeel Enn vum Spektrum sinn, an Dir musst wielen wéi eng Manéier Dir optiméiert. Déi gutt Noriicht ass datt mat RabbitMQ dëse Choix méiglech ass. Dir hutt dës Zort "nerdy" Heber fir d'Gläichgewiicht op méi Konsistenz oder méi Accessibilitéit ze réckelen.
Mir wäerte besonnesch oppassen op wéi eng Konfiguratiounen zu Datenverloscht féieren wéinst bestätegten Opzeechnungen. Et gëtt eng Kette vu Verantwortung tëscht Verëffentlecher, Broker a Konsumenten. Wann de Message un de Broker iwwerdroen ass, ass et seng Aarbecht net de Message ze verléieren. Wann de Broker den Empfang vum Verlag vun der Noriicht unerkennt, erwaarden mir net datt et verluer geet. Awer mir wäerte gesinn datt dëst tatsächlech ka geschéien ofhängeg vun Ärer Broker a Verëffentlecher Konfiguratioun.
Single Node Resilience Primitives
Resilient Queuing / Routing
Et ginn zwou Zorte vu Schlaangen am RabbitMQ: haltbar an net haltbar. All Schlaangen ginn an der Mnesia Datebank gespäichert. Haltbar Schlaangen ginn nei ugekënnegt beim Startup vum Node an iwwerliewen domat Restart, System Crash oder Server Crash (soulaang d'Donnéeën bestoe bleiwen). Dëst bedeit datt soulaang Dir de Routing (Austausch) an d'Schlaang als elastesch deklaréiert, wäert d'Schlaang / Routing-Infrastruktur erëm online kommen.
Volatile Schlaangen a Routing ginn geläscht wann de Node nei gestart gëtt.
Persistent Messagen
Just well eng Schlaang haltbar ass heescht net datt all seng Messagen en Node-Restart iwwerliewen. Nëmme Messagen, déi vum Verlag als nohalteg (persistent). Persistent Messagen erstellen zousätzlech Belaaschtung op de Broker, awer wann de Message Verloscht inakzeptabel ass, da gëtt et keng aner Optioun.
Reis. 1. Nohaltegkeet Matrixentgasung
Clustering mat Schlaangspigel
Fir de Verloscht vun engem Broker ze iwwerliewen, brauche mir Redundanz. Mir kënne verschidde RabbitMQ Noden an e Stärekoup kombinéieren, an dann zousätzlech Redundanz addéieren andeems Dir Schlaangen tëscht multiple Noden replizéiert. Op dës Manéier, wann een Node feelt, verléiere mir keng Daten a bleiwen verfügbar.
Queue Mirroring:
- eng Haaptrei (Meeschter), déi kritt all schreiwen a liesen Kommandoen
- een oder méi Spigelen déi all Messagen a Metadaten aus der Haaptschlaang kréien. Dës Spigelen sinn net do fir Skaléieren, mee reng fir Redundanz.
Reis. 2. Schlaang Spigelen
Mirroring gëtt vun der entspriechender Politik gesat. An et kënnt Dir de Replikatiounskoeffizient auswielen a souguer d'Knäppchen op deenen d'Schlaang sollt sinn. Beispiller:
ha-mode: allha-mode: exactly, ha-params: 2(e Meeschter an ee Spigel)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
Verlag Bestätegung
Fir konsequent Opnahmen z'erreechen, Publisher Confirms sinn erfuerderlech. Ouni si besteet e Risiko datt Messagen verluer ginn. Eng Bestätegung gëtt un de Verlag geschéckt nodeems de Message op Disk geschriwwe gouf. RabbitMQ schreift Messagen op Disk net op Empfang, awer op enger periodesch Basis, an der Regioun vun e puer honnert Millisekonnen. Wann eng Schlaang gespigelt gëtt, gëtt eng Unerkennung eréischt geschéckt nodeems all Spigelen och hir Kopie vum Message op Disk geschriwwen hunn. Dëst bedeit datt d'Benotzung vun Bestätegunge Latenz bäidréit, awer wann d'Datesécherheet wichteg ass, da si se néideg.
Failover Schlaang
Wann e Broker ophält oder ofstëmmt, Crash all Schlaang Leader (Meeschter) op deem Node zesumme mat him. De Stärekoup wielt dann den eelste Spigel vun all Meeschter a fördert en als neie Meeschter.
Reis. 3. Multiple gespigelte Schlaangen an hir Politik
Broker 3 geet erof. Bedenkt datt de Queue C Spigel op Broker 2 op Meeschter gefördert gëtt. Notéiert och datt en neie Spigel erstallt gouf fir Queue C op Broker 1. RabbitMQ probéiert ëmmer de Replikatiounsfaktor, deen an Ärer Politik spezifizéiert ass, z'erhalen.
Reis. 4. Broker 3 klappt, wouduerch d'Schlaang C versoen
Den nächste Broker 1 fällt! Mir hunn nëmmen ee Broker lénks. De Queue B Spigel gëtt zu Meeschter gefördert.
Fig. 5
Mir hunn de Broker zréckginn 1. Egal wéi gutt d'Donnéeën de Verloscht an d'Erhuelung vum Broker iwwerliewen, all gespigelte Schlaangmessage ginn beim Neistart verworf. Dëst ass wichteg ze notéieren well et Konsequenze wäert sinn. Mir wäerten dës Implikatioune kuerz kucken. Also de Broker 1 ass elo erëm Member vum Cluster, an de Cluster probéiert d'Politik ze respektéieren an erstellt dofir Spigelen um Broker 1.
An dësem Fall war de Verloscht vum Broker 1 komplett, sou wéi d'Donnéeën, sou datt d'onmirrored Queue B komplett verluer ass.
Reis. 6. Broker 1 geet zréck op Service
De Broker 3 ass erëm online, sou datt d'Schlaangen A a B d'Spigelen erstallt hunn zréck fir hir HA Politik ze zefridden. Awer elo sinn all d'Haaptschlaangen op engem Node! Dëst ass net ideal, eng gläichméisseg Verdeelung tëscht Noden ass besser. Leider ginn et hei net vill Méiglechkeeten fir Meeschter ze rebalancing. Mir kommen méi spéit op dëst Thema zréck, well mir musse fir d'éischt d'Schlaangsynchroniséierung kucken.
Reis. 7. Broker 3 geet zréck op de Service. All Haaptschlaangen op engem Node!
Also elo sollt Dir eng Iddi hunn wéi Spigelen Redundanz a Feelertoleranz ubidden. Dëst garantéiert Disponibilitéit am Fall vun engem eenzegen Node Echec a schützt géint Dateverloscht. Mee mir sinn nach net fäerdeg, well et a Wierklechkeet vill méi komplizéiert ass.
Synchroniséierung
Wann Dir en neie Spigel erstellt, ginn all nei Messagen ëmmer op dëse Spigel an all aner replizéiert. Wat d'bestehend Donnéeën an der Masterschlaang ugeet, kënne mir se an en neie Spigel replizéieren, wat eng komplett Kopie vum Master gëtt. Mir kënnen och wielen net existéierend Messagen ze replizéieren an d'Haaptschlaang an den neie Spigel an der Zäit ze konvergéieren, mat neie Messagen déi um Schwanz kommen an existéierend Messagen déi de Kapp vun der Haaptrei verloossen.
Dës Synchroniséierung gëtt automatesch oder manuell gemaach a gëtt mat enger Schlaangpolitik geréiert. Loosst eis e Beispill kucken.
Mir hunn zwou gespigelte Schlaangen. Queue A gëtt automatesch synchroniséiert, an Queue B gëtt manuell synchroniséiert. Béid Schlaangen enthalen zéng Messagen.
Reis. 8. Zwee Schlaangen mat verschiddene Synchroniséierungsmodi
Elo verléiere mir Broker 3.
Reis. 9. Broker 3 gefall
Broker 3 geet zréck op de Service. De Stärekoup erstellt e Spigel fir all Schlaang op den neien Node an synchroniséiert automatesch déi nei Queue A mam Master. Allerdéngs bleift de Spigel vun der neier Queue B eidel. Op dës Manéier hu mir voll Redundanz op Queue A an nëmmen ee Spigel fir existent Queue B Messagen.
Reis. 10. Den neie Spigel vun der Queue A kritt all existent Messagen, awer den neie Spigel vun der Queue B net.
Zéng méi Messagen kommen a béide Schlaangen. De Broker 2 klappt dann an d'Queue A rullt zréck an den eelste Spigel, deen um Broker 1 ass. Et gëtt keen Dateverloscht wann et klappt. An der Queue B sinn et zwanzeg Messagen am Master an nëmmen zéng am Spigel, well dës Schlaang ni déi originell zéng Messagen replizéiert huet.
Reis. 11. Queue A rullt zréck op Broker 1 ouni Messagen ze verléieren
Zéng méi Messagen kommen a béide Schlaangen. Elo klappt de Broker 1. Queue A schalt einfach an de Spigel ouni Messagen ze verléieren. Wéi och ëmmer, Queue B huet Problemer. Zu dësem Zäitpunkt kënne mir entweder Disponibilitéit oder Konsequenz optimiséieren.
Wa mir d’Accessibilitéit wëllen optimiséieren, dann d’Politik ha-förderen-op-Feele soll installéiert ginn an ëmmer. Dëst ass de Standardwäert, sou datt Dir d'Politik einfach guer net spezifizéiere kënnt. An dësem Fall erlaben mir am Wesentlechen Feeler an onsynchroniséierte Spigelen. Dëst wäert Messagen verluer ginn, awer d'Schlaang bleift liesbar a schreiwenbar.
Reis. 12. Queue A gëtt zréck op Broker 3 gerullt ouni Messagen ze verléieren. Queue B rullt zréck op de Broker 3 mat zéng verluerene Messagen
Mir kënnen och installéieren ha-promote-on-failure an Bedeitung when-synced. An dësem Fall, amplaz zréck an de Spigel ze rullen, wäert d'Schlaang waarden bis de Broker 1 mat sengen Donnéeën an den Online Modus zréckkënnt. Nodeems et zréck ass, ass d'Haaptschlaang zréck op Broker 1 ouni Datenverloscht. Disponibilitéit gëtt fir Datesécherheet geaffert. Awer dëst ass e riskante Modus dee souguer zu kompletten Dateverloscht féiere kann, wat mir kuerz kucken.
Reis. 13. Queue B bleift net verfügbar nodeems de Broker 1 verluer ass
Dir kënnt froen: "Ass et besser ni automatesch Synchroniséierung ze benotzen?" D'Äntwert ass datt d'Synchroniséierung eng Blockéierungsoperatioun ass. Wärend der Synchroniséierung kann d'Haaptschlaang keng Lies- oder Schreifoperatioune maachen!
Loosst eis e Beispill kucken. Elo hu mir ganz laang Schlaangen. Wéi kënne se zu esou enger Gréisst wuessen? Aus e puer Grënn:
- Schlaangen ginn net aktiv benotzt
- Dëst sinn Héich-Vitesse Schlaangen, a grad elo Konsumenten sinn lues
- Et ass High-Speed-Schlaangen, et gouf e Feeler an d'Konsumenten fänken un
Reis. 14. Zwee grouss Schlaangen mat verschiddene Synchroniséierungsmodi
Elo fällt Broker 3.
Reis. 15. Broker 3 Falen, loosst ee Meeschter a Spigel an all Schlaang
Broker 3 kënnt zréck online an nei Spigelen ginn erstallt. Main Queue A fänkt un existent Messagen op den neie Spigel ze replizéieren, a wärend dëser Zäit ass d'Queue net verfügbar. Et dauert zwou Stonne fir d'Donnéeën ze replizéieren, wat zu zwou Stonnen Ausdauer fir dës Queue resultéiert!
Wéi och ëmmer, Queue B bleift iwwer déi ganz Period verfügbar. Si huet e puer Redundanz fir Accessibilitéit geaffert.
Reis. 16. Schlaang bleift während der Synchroniséierung net verfügbar
No zwou Stonnen ass d'Queue A och verfügbar a kann d'Liesen a Schreiwen erëm akzeptéieren.
Aktualiséierungen
Dëst Blockéierungsverhalen während der Synchroniséierung mécht et schwéier Cluster mat ganz grousse Schlaangen ze aktualiséieren. Iergendwann muss de Master Node nei gestart ginn, dat heescht entweder op e Spigel ze wiesselen oder d'Schlaang auszeschalten wärend de Server aktualiséiert gëtt. Wa mir den Iwwergank wielen, wäerte mir Messagen verléieren wann d'Spigel net synchroniséiert sinn. Par défaut, wärend engem Brokerausfall, gëtt e Failover op en onsynchroniséierte Spigel net gemaach. Dëst bedeit datt soubal de Broker zréckkënnt, mir verléieren keng Messagen, deen eenzege Schued war eng einfach Schlaang. Verhalensregele wann e Broker ofgeschalt gëtt gi vu Politik festgeluecht ha-promote-on-shutdown. Dir kënnt ee vun zwee Wäerter setzen:
always= Iwwergank op onsynchroniséiert Spigelen ass aktivéiertwhen-synced= Iwwergank nëmmen op e synchroniséierte Spigel, soss gëtt d'Schlaang onliesbar an net schreiwenbar. D'Schlaang geet zréck an de Service soubal de Broker zréckkënnt
Op déi eng oder aner Manéier, mat grousse Schlaangen musst Dir tëscht Datenverloscht an Onverfügbarkeet wielen.
Wann Disponibilitéit d'Datesécherheet verbessert
Et gëtt eng méi Komplikatioun fir ze berücksichtegen ier Dir eng Entscheedung maacht. Wärend automatesch Synchroniséierung besser ass fir Redundanz, wéi beaflosst et d'Datesécherheet? Natierlech, mat enger besserer Redundanz, RabbitMQ ass manner wahrscheinlech existéierend Messagen ze verléieren, awer wat iwwer nei Messagen vu Verëffentlechen?
Hei musst Dir déi folgend berücksichtegen:
- Konnt de Verlag einfach e Feeler zréckginn an den Upstream Service oder de Benotzer méi spéit nach eng Kéier probéieren?
- Kann de Verlag de Message lokal oder an enger Datebank späicheren fir spéider nach eng Kéier ze probéieren?
Wann de Verlag nëmmen d'Botschaft kann ofleeën, da verbessert d'Verbesserung vun der Accessibilitéit och d'Datesécherheet.
Dofir muss e Gläichgewiicht gesicht ginn, an d'Léisung hänkt vun der spezifescher Situatioun of.
Problemer mat ha-promote-on-failure=wann synchroniséiert
Idea ha-förderen-op-Feele= wann synchroniséiert ass, datt mir verhënneren op en unsynchronized Spigel Wiesselen an domat Daten Verloscht vermeiden. D'Schlaang bleift onliesbar oder schreiwenbar. Amplaz probéieren mir den ofgebrach Broker mat sengen Donnéeën intakt ze recuperéieren, sou datt et erëm kann als Meeschter funktionnéieren ouni Datenverloscht.
Awer (an dëst ass e groussen awer) wann de Broker seng Donnéeën verluer huet, dann hu mir e grousse Problem: d'Schlaang ass verluer! All Daten sinn fort! Och wann Dir Spigelen hutt déi meeschtens mat der Haaptschlaang ophalen, ginn déi Spigelen och verworf.
Fir en Node mam selwechten Numm erëm derbäizefügen, soen mir dem Cluster de verluerene Node ze vergiessen (mam Kommando rabbitmqctl forget_cluster_node) a fänkt en neie Broker mam selwechte Hostnumm un. Wärend de Stärekoup de verluerene Node erënnert, erënnert et un déi al Schlaang an onsynchroniséiert Spigelen. Wann e Stärekoup gesot gëtt en verwaistem Node ze vergiessen, gëtt déi Schlaang och vergiess. Elo musse mir et nei deklaréieren. Mir hunn all d'Donnéeë verluer, obwuel mir Spigelen mat engem deelweise Satz vun Donnéeën haten. Et wier besser op en net-synchroniséierte Spigel ze wiesselen!
Dofir manuell Synchroniséierung (an Echec Synchroniséierung) a Kombinatioun mat ha-promote-on-failure=when-synced, menger Meenung no, ganz riskant. D'Dokteren soen datt dës Optioun existéiert fir Datesécherheet, awer et ass en duebelschneitem Messer.
Meeschtesch rebalancing
Wéi versprach, gi mir zréck op de Problem vun der Akkumulation vun all Meeschter op een oder e puer Wirbelen. Dëst ka souguer geschéien als Resultat vun engem Rolling Cluster Update. An engem Drei-Node-Cluster sammelen all Master-Schlaangen op een oder zwee Wirbelen.
Rebalancing Masters kënnen aus zwee Grënn problematesch sinn:
- Et gi keng gutt Tools fir Rebalanzéierung ze maachen
- Schlaang Synchroniséierung
Et gëtt eng drëtt Partei fir d'Rebalancing , déi net offiziell ënnerstëtzt gëtt. Betreffend Drëtt Partei Plugins am RabbitMQ Handbuch : "De Plugin bitt e puer zousätzlech Konfiguratiouns- a Berichtungsinstrumenter, awer gëtt net vum RabbitMQ Team ënnerstëtzt oder verifizéiert. Benotzt op Ären eegene Risiko."
Et gëtt en aneren Trick fir d'Haaptschlaang duerch HA Politik ze réckelen. D'Handbuch ernimmt dofir. Et funktionnéiert esou:
- Ewechzehuelen all Spigel mat enger temporärer Politik déi eng méi héich Prioritéit wéi déi bestehend HA Politik huet.
- Ännert d'HA temporär Politik fir den Node Modus ze benotzen, spezifizéiert den Node op deen d'Masterschlaang transferéiert soll ginn.
- Synchroniséiert d'Schlaang fir Push Migratioun.
- Nodeems d'Migratioun fäerdeg ass, läscht déi temporär Politik. Déi initial HA-Politik trëtt a Kraaft an déi erfuerderlech Unzuel u Spigelen gëtt erstallt.
De Nodeel ass datt dës Approche vläicht net funktionnéiert wann Dir grouss Schlaangen oder strikt Redundanzfuerderunge hutt.
Loosst eis elo kucken wéi RabbitMQ Cluster mat Netzwierkpartitionen funktionnéieren.
Verloscht vun Konnektivitéit
D'Node vun engem verdeelt System sinn duerch Reseau Linken ugeschloss, an Reseau Linken kann a wäert disconnected ginn. D'Frequenz vun Ausfall hänkt vun der lokaler Infrastruktur oder der Zouverlässegkeet vun der gewielter Wollek of. Op jidde Fall musse verdeelt Systemer mat hinnen ausgoen. Nach eng Kéier hu mir e Choix tëscht Disponibilitéit a Konsequenz, an erëm ass d'Gutt Noriicht datt RabbitMQ béid Optiounen ubitt (just net zur selwechter Zäit).
Mat RabbitMQ hu mir zwou Haaptoptiounen:
- Erlaabt logesch Divisioun (Split-Gehir). Dëst garantéiert Disponibilitéit, awer kann Datenverloscht verursaachen.
- Logesch Trennung auszeschalten. Kann zu kuerzfristeg Verloscht vun Disponibilitéit Resultat ofhängeg vun wéi Clienten un de Stärekoup konnektéieren. Kann och zu enger kompletter Onverfügbarkeet an engem Zwee-Node-Cluster féieren.
Awer wat ass logesch Trennung? Dëst ass wann e Stärekoup an zwee trennt wéinst Verloscht vun Netzwierkverbindungen. Op all Säit ginn d'Spigelen zu engem Meeschter gefördert, sou datt et schlussendlech e puer Meeschter pro Tour gëtt.
Reis. 17. Haaptrei an zwee Spigelen, all op engem separat Node. Da geschitt en Netzfehler an ee Spigel gëtt ofgetrennt. De getrennten Node gesäit datt déi aner zwee ofgefall sinn a fördert seng Spigelen zum Master. Mir hunn elo zwou Haaptschlaangen, souwuel schrëftlech a liesbar.
Wann d'Verëffentlecher Daten un béid Meeschteren schécken, komme mir mat zwee divergente Kopien vun der Schlaang.
RabbitMQ verschidde Modi bidden entweder Disponibilitéit oder Konsistenz.
Ignoréieren Modus (Standard)
Dëse Modus garantéiert Accessibilitéit. Nom Verloscht vun der Konnektivitéit geschitt eng logesch Trennung. Nodeems d'Konnektivitéit restauréiert ass, muss den Administrator entscheeden wéi eng Partition Prioritéit gëtt. D'Verléierer Säit gëtt nei gestart an all akkumuléiert Donnéeën op där Säit ginn verluer.
Reis. 18. Dräi Verëffentleche si mat dräi Courtiere verbonnen. Intern féiert de Cluster all Ufroen an d'Haaptschlaang um Broker 2.
Elo verléiere mir Broker 3. Hie gesäit datt aner Broker ofgefall sinn a fördert säi Spigel zum Meeschter. Dëst ass wéi eng logesch Trennung geschitt.
Reis. 19. Logesch Divisioun (Split-Gehir). Records ginn an zwou Haaptschlaangen, an déi zwee Exemplare divergéieren.
Konnektivitéit gëtt restauréiert, awer logesch Trennung bleift. Den Administrateur muss d'Verléierer Säit manuell auswielen. Am Fall hei drënner, den Administrator reboots Broker 3. All Messagen, déi hien net fäerdeg bruecht huet ze vermëttelen, ginn verluer.
Reis. 20. Den Administrator deaktivéiert Broker 3.
Reis. 21. Den Administrateur fänkt Broker 3 un an et trëtt an de Stärekoup, verléiert all Messagen déi do hannerlooss goufen.
Wärend dem Verléiere vun der Konnektivitéit an no senger Restauratioun waren de Cluster an dës Schlaang verfügbar fir ze liesen a schreiwen.
Autoheal Modus
Wierker ähnlech wéi Ignoréieren Modus, ausser datt de Stärekoup selwer automatesch d'Verléierer Säit wielt no Spaltung a Konnektivitéit restauréiert. D'Verléierer Säit geet zréck an de Stärekoup eidel, an d'Schlaang verléiert all Messagen, déi nëmmen op dës Säit geschéckt goufen.
Paus Minoritéitsmodus
Wa mir keng logesch Partitionéierung wëllen erlaben, dann ass eis eenzeg Optioun d'Liesen a Schreiwen op der méi klenger Säit no der Clusterpartition ofzeginn. Wann de Broker gesäit datt et op der méi klenger Säit ass, suspendéiert hien d'Aarbecht, dat heescht, et mécht all existent Verbindungen zou a refuséiert nei. Eemol pro Sekonn kontrolléiert et fir d'Konnektivitéit Restauratioun. Wann d'Konnektivitéit restauréiert ass, setzt se d'Operatioun erëm a schléisst sech an de Cluster.
Reis. 22. Dräi Verëffentleche si mat dräi Courtiere verbonnen. Intern féiert de Cluster all Ufroen an d'Haaptschlaang um Broker 2.
D'Broker 1 an 2 hunn sech dann vum Broker 3 gespléckt. Amplaz hire Spigel op Meeschter ze promoten, suspendéiert de Broker 3 a gëtt net verfügbar.
Reis. 23. Broker 3 pauses, trennt all Clienten a refuséiert Verbindungsufroen.
Wann d'Konnektivitéit restauréiert ass, geet et zréck an de Cluster.
Loosst eis en anert Beispill kucken wou d'Haaptschlaang um Broker 3 ass.
Reis. 24. Main Schlaang op Broker 3.
Da geschitt dee selwechte Verloscht vu Konnektivitéit. Broker 3 pauses well et op der méi klenger Säit ass. Op der anerer Säit gesinn d'Node datt de Broker 3 ofgefall ass, sou datt den eelere Spigel vu Brokers 1 an 2 op Meeschter gefördert gëtt.
Reis. 25. Iwwergang zu Broker 2 wann Broker 3 net verfügbar ass.
Wann d'Konnektivitéit restauréiert ass, wäert de Broker 3 de Cluster bäitrieden.
Reis. 26. De Stärekoup ass zréck an normal Operatioun.
Déi wichteg Saach hei ze verstoen ass datt mir Konsequenz kréien, awer mir kënnen och Disponibilitéit kréien, wann Mir wäerten erfollegräich Clienten op déi meescht vun der Rubrik Transfert. Fir déi meescht Situatiounen géif ech perséinlech de Pause Minority Modus wielen, awer et hänkt wierklech vum individuellen Fall of.
Fir Disponibilitéit ze garantéieren, ass et wichteg ze garantéieren datt Clienten erfollegräich mam Host verbannen. Loosst eis eis Optiounen kucken.
Assuréieren Client Konnektivitéit
Mir hunn e puer Méiglechkeeten fir wéi Dir Clienten op den Haaptdeel vum Stärekoup riicht oder op d'Aarbechtsknäppchen (no engem Node feelt) no engem Verloscht vun der Konnektivitéit. Loosst eis als éischt drun erënneren datt eng spezifesch Schlaang op engem spezifesche Node gehost gëtt, awer Routing a Politik ginn iwwer all Node replizéiert. D'Clientë kënnen op all Node konnektéieren, an intern Routing wäert se dirigéieren wou se higoe mussen. Awer wann en Node suspendéiert ass, refuséiert et Verbindungen, sou datt d'Clientë mat engem aneren Node verbannen. Wann de Node fällt, ass et wéineg wat hien iwwerhaapt maache kann.
Eis Optiounen:
- De Cluster gëtt zougänglech mat engem Laaschtbalancer deen einfach duerch d'Knäppchen zyklen an d'Clientë probéieren ze verbannen bis et erfollegräich ass. Wann en Node erof ass oder suspendéiert ass, da wäert d'Versuche fir mat deem Node ze verbannen, falen, awer spéider Versuche ginn op aner Serveren (op eng Ronn-Robin Manéier). Dëst ass gëeegent fir e kuerzfristeg Konnektivitéitsverloscht oder e erofgefallene Server dee séier erëm opgebaut gëtt.
- Zougrëff op de Stärekoup duerch e Laaschtbalancer an ewechzehuelen suspendéiert / gescheitert Noden aus der Lëscht soubal se festgestallt ginn. Wa mir dat séier maachen, a wann d'Cliente kënnen d'Verbindung erëm probéieren, da wäerte mir konstant Disponibilitéit erreechen.
- Gëff all Client eng Lëscht vun all Wirbelen, an de Client wielt zoufälleg ee vun hinnen wann Verbindung. Wann et e Feeler kritt wann Dir probéiert ze verbannen, geet et op den nächsten Node an der Lëscht bis et verbënnt.
- Ewechzehuelen Traffic vun engem gescheitert / suspendéiert Node benotzt DNS. Dëst gëtt mat engem klengen TTL gemaach.
Conclusiounen
RabbitMQ Clustering huet seng Virdeeler an Nodeeler. Déi sérieux Nodeeler sinn:
- wann Dir e Stärekoup bäitrieden, verwerfen Noden hir Donnéeën;
- Synchroniséierung blockéieren verursaacht d'Schlaang net verfügbar.
All schwiereg Entscheedunge kommen aus dësen zwee architektonesche Fonctiounen. Wann RabbitMQ Daten späichere kéint wann de Stärekoup erëm ugeschloss ass, da wier d'Synchroniséierung méi séier. Wann et fäeg wier fir Synchroniséierung net ze blockéieren, géif et besser grouss Schlaangen ënnerstëtzen. Dës zwee Themen ze fixéieren géif dem RabbitMQ seng Leeschtung als Feeler-tolerant an héich verfügbar Messagerie Technologie staark verbesseren. Ech wier zéckt fir RabbitMQ mat Clustering an de folgende Situatiounen ze recommandéieren:
- Onverlässeg Netzwierk.
- Onverlässeg Stockage.
- Ganz laang Schlaangen.
Wann et ëm héich Disponibilitéit Astellunge kënnt, betruecht déi folgend:
ha-promote-on-failure=alwaysha-sync-mode=manualcluster_partition_handling=ignore(oderautoheal)- persistent Messagen
- suergen datt Cliente mam aktive Node verbannen wann e puer Node feelt
Fir Konsistenz (Datesécherheet), betruecht déi folgend Astellungen:
- Verlag bestätegt a manuell Unerkennung op der Konsument Säit
ha-promote-on-failure=when-synced, wann d'Verëffentleche spéider nach eng Kéier probéieren a wann Dir ganz zouverlässeg Späichere hutt! Soss setzen=always.ha-sync-mode=automatic(awer fir grouss inaktiv Schlaangen kann de manuelle Modus erfuerderlech sinn; betruecht och ob d'Onverfügbarkeet Messagen verluer geet)- Paus Minoritéitsmodus
- persistent Messagen
Mir hunn nach net all Themen vun Feeler Toleranz an héich Disponibilitéit Daach; zum Beispill,, wéi sécher administrativ Prozeduren ze Leeschtunge (wéi Rolling Aktualiséierungen). Mir mussen och iwwer Federatioun an de Shovel Plugin schwätzen.
Wann ech nach eppes verpasst hunn, soot mir w.e.g. Bescheed.
Kuckt och meng , wou ech en Havoc op engem RabbitMQ Cluster maachen mat Docker a Blockade fir e puer vun de Message Verloscht Szenarien ze testen, déi an dësem Artikel beschriwwe ginn.
Virdrun Artikelen an der Serie:
Nummer 1 -
Nummer 2 -
Nummer 3 -
Source: will.com