Fouttolerânsje en hege beskikberens binne grutte ûnderwerpen, dus wy sille aparte artikels wije oan RabbitMQ en Kafka. Dit artikel giet oer RabbitMQ, en it folgjende giet oer Kafka, yn ferliking mei RabbitMQ. Dit is in lang artikel, dus meitsje josels noflik.

Litte wy nei de fouttolerânsje, konsistinsje en strategyen mei hege beskikberens (HA) sjen en de ôfwikselingen dy't elke strategy makket. RabbitMQ kin rinne op in kluster fan knopen - en wurdt dan klassifisearre as in ferspraat systeem. As it giet om ferdielde systemen, prate wy faak oer konsistinsje en beskikberens.

Dizze begripen beskriuwe hoe't in systeem him gedraacht as it mislearret. Netwurkferbining mislearre, tsjinner mislearring, hurde skiif mislearring, tydlike net-beskikberens fan tsjinner fanwege garbage collection, pakketferlies, of fertraging fan netwurkferbining. Dit alles kin liede ta gegevensferlies of konflikten. It docht bliken dat it praktysk ûnmooglik is om in systeem op te setten dat sawol folslein konsekwint is (gjin gegevensferlies, gjin gegevensdiverginsje) en beskikber is (lêzen en skriuwt akseptearje sil) foar alle mislearre senario's.

Wy sille sjen dat konsistinsje en beskikberens op tsjinoerstelde einen fan it spektrum binne, en jo moatte kieze hokker manier om te optimalisearjen. It goede nijs is dat mei RabbitMQ dizze kar mooglik is. Jo hawwe dit soarte fan "nerdy" levers om it lykwicht te ferskowen nei gruttere konsistinsje of gruttere tagonklikens.

Wy sille spesjaal omtinken jaan oan hokker konfiguraasjes liede ta gegevensferlies troch befêstige records. D'r is in keatling fan ferantwurdlikens tusken útjouwers, makelders en konsuminten. Sadree't it berjocht is oerbrocht nei de makelder, it is syn taak om it berjocht net te ferliezen. As de brokker de ûntfangst fan it berjocht troch de útjouwer erkent, ferwachtsje wy net dat it ferlern giet. Mar wy sille sjen dat dit feitlik kin barre ôfhinklik fan jo konfiguraasje fan jo broker en útjouwer.

Single Node Resilience Primitives

Resilient Queuing / Routing

D'r binne twa soarten wachtrigen yn RabbitMQ: duorsum en net-duorsum. Alle wachtrijen wurde bewarre yn 'e Mnesia-database. Duorsume wachtrijen wurde opnij advertearre by it opstarten fan knooppunten en oerlibje sa opnij starte, systeemcrashes, of servercrashes (salang't de gegevens oanhâlde). Dit betsjut dat salang't jo routing (útwikseling) en wachtrige ferklearje as resilint, sil de wachtrige / routing-ynfrastruktuer wer online komme.

Flechtige wachtrijen en routing wurde fuortsmiten as it knooppunt wurdt opnij starte.

Persistente berjochten

Krekt om't in wachtrige duorsum is, betsjut net dat al syn berjochten in knooppunt opnij starte sille oerlibje. Allinnich berjochten ynsteld troch de útjouwer as geweldich (oanhâldend). Persistente berjochten meitsje ekstra lêst op 'e makelder, mar as berjochtferlies net akseptabel is, dan is der gjin oare opsje.

Rys. 1. Duorsumens matrix

Clustering mei wachtrige spegeljen

Om it ferlies fan in makelder te oerlibjen, hawwe wy redundans nedich. Wy kinne meardere RabbitMQ-knooppunten kombinearje yn in kluster, en dan ekstra redundânsje tafoegje troch wachtrijen te replikearjen tusken meardere knopen. Op dizze manier, as ien knooppunt mislearret, ferlieze wy gjin gegevens en bliuwe wy beskikber.

Wachtrige spegeljen:

• ien haadwachtrige (master), dy't alle skriuw- en lêskommando's ûntfangt
• ien of mear spegels dy't ûntfange alle berjochten en metadata út de haadwachtrige. Dizze spegels binne der net foar skaalfergrutting, mar suver foar oerstalligens.

Rys. 2. Wachtrige ôfspegeljen

Mirroring wurdt ynsteld troch it passende belied. Dêryn kinne jo de replikaasjekoëffisjint selektearje en sels de knopen wêrop de wachtrige lizze moat. Foarbylden:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (ien master en ien spegel)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Utjouwer befêstiging

Om konsekwinte opname te berikken, binne útjouwersbefêstigingen ferplicht. Sûnder harren is der it risiko dat berjochten ferlern gean. In befêstiging wurdt stjoerd nei de útjouwer nei it berjocht is skreaun op skiif. RabbitMQ skriuwt berjochten op skiif net by ûntfangst, mar op in periodike basis, yn 'e regio fan ferskate hûndert millisekonden. As in wachtrige wurdt spegele, wurdt in erkenning pas ferstjoerd nei't alle spegels ek har kopy fan it berjocht op skiif skreaun hawwe. Dit betsjut dat it brûken fan befêstigings latinsje tafoeget, mar as gegevensfeiligens wichtich is, dan binne se nedich.

Failover wachtrige

As in makelder ophâldt of crasht, crashje alle wachtrigelieders (masters) op dat knooppunt dêrmei. It kluster selekteart dan de âldste spegel fan elke master en befoarderet it as de nije master.

Rys. 3. Meardere spegele wachtrijen en harren belied

Broker 3 giet del. Tink derom dat de Queue C-spegel op Broker 2 wurdt promovearre ta master. Tink derom dat in nije spegel is makke foar Wachtrige C op Broker 1. RabbitMQ besiket altyd de replikaasjefaktor te behâlden dy't yn jo belied oanjûn is.

Rys. 4. Broker 3 mislearret, wêrtroch't wachtrige C mislearret

De folgjende Broker 1 falt! Wy hawwe mar ien makelder oer. De Queue B-spegel wurdt promovearre ta master.

Fig. 5

Wy hawwe werom Broker 1. Nettsjinsteande hoe goed de gegevens oerlibbet it ferlies en herstel fan 'e makelder, alle spegeljende wachtrige berjochten wurde ferwidere by opnij starte. Dit is wichtich om te notearjen, om't d'r gefolgen sille wêze. Wy sille dizze gefolgen ynkoarten besjen. Sa is Broker 1 no wer lid fan it kluster, en it kluster besiket te foldwaan oan it belied en makket dêrom spegels op Broker 1.

Yn dit gefal wie it ferlies fan Broker 1 folslein, lykas de gegevens, sadat de unmirrored Queue B folslein ferlern wie.

Rys. 6. Broker 1 komt werom nei tsjinst

Broker 3 is wer online, dus wachtrijen A en B krije de spegels dy't derop makke binne werom om har HA-belied te befredigjen. Mar no binne alle haadwachtrigen op ien knooppunt! Dit is net ideaal, in even ferdieling tusken knopen is better. Spitigernôch binne d'r hjir net folle opsjes foar herbalancing masters. Wy komme letter op dit probleem werom, om't wy earst nei wachtrigesyngronisaasje moatte sjen.

Rys. 7. Broker 3 komt werom nei tsjinst. Alle haadwachtrige op ien knooppunt!

Dat no moatte jo in idee hawwe fan hoe't spegels redundânsje en fouttolerânsje leverje. Dit soarget foar beskikberens yn it gefal fan ien knooppuntfal en beskermet tsjin gegevensferlies. Mar wy binne noch net klear, want yn werklikheid is it folle yngewikkelder.

Syngronisearje

By it meitsjen fan in nije spegel sille alle nije berjochten altyd wurde replikearre nei dizze spegel en alle oaren. Wat de besteande gegevens yn 'e masterwachtrige oanbelanget, kinne wy ​​it replikearje nei in nije spegel, dy't in folsleine kopy fan' e master wurdt. Wy kinne ek kieze om besteande berjochten net te replikearjen en de haadwachtrige en de nije spegel yn 'e tiid te konvergearjen, mei nije berjochten dy't oan' e sturt komme en besteande berjochten dy't de kop fan 'e haadwachtrige ferlitte.

Dizze syngronisaasje wurdt automatysk of mei de hân útfierd en wurdt beheard mei in wachtrigebelied. Litte wy nei in foarbyld sjen.

Wy hawwe twa spegeljende wachtrigen. Wachtrige A wurdt automatysk syngronisearre, en Wachtrige B wurdt manuell syngronisearre. Beide wachtrigen befetsje tsien berjochten.

Rys. 8. Twa wachtrigen mei ferskillende syngronisaasje modus

No ferlieze wy Broker 3.

Rys. 9. Broker 3 foel

Broker 3 komt werom nei tsjinst. It kluster makket in spegel foar elke wachtrige op it nije knooppunt en syngronisearret automatysk de nije wachtrige A mei de master. De spegel fan de nije Wachtrige B bliuwt lykwols leech. Op dizze manier hawwe wy folsleine oerstalligens op wachtrige A en mar ien spegel foar besteande wachtrige B-berjochten.

Rys. 10. De nije spegel fan Wachtrige A ûntfangt alle besteande berjochten, mar de nije spegel fan Wachtrige B net.

Yn beide wachtrijen komme noch tsien berjochten. Broker 2 dan crashes en Queue A rôlet werom nei de âldste spegel, dat is op Broker 1. Der is gjin gegevens ferlies as it mislearret. Yn wachtrige B binne d'r tweintich berjochten yn 'e master en mar tsien yn' e spegel, om't dizze wachtrige de orizjinele tsien berjochten noait replikearre.

Rys. 11. Wachtrige A rôlet werom nei Broker 1 sûnder berjochten te ferliezen

Yn beide wachtrijen komme noch tsien berjochten. No crasht Broker 1. Wachtrige A skeakelt maklik oer nei de spegel sûnder berjochten te ferliezen. Wachtrige B hat lykwols problemen. Op dit punt kinne wy ​​de beskikberens of konsistinsje optimalisearje.

As wy de berikberens optimalisearje wolle, dan is it belied ha-promote-op-mislearring moatte wurde ynstallearre yn altyd. Dit is de standertwearde, dus jo kinne it belied gewoan net opjaan. Yn dit gefal tastean wy yn essinsje mislearrings ta yn unsyngronisearre spegels. Dit soarget derfoar dat berjochten ferlern gean, mar de wachtrige bliuwt lêsber en skriuwber.

Rys. 12. Wachtrige A wurdt rôle werom nei Broker 3 sûnder ferliezen berjochten. Wachtrige B rôlet werom nei Broker 3 mei tsien berjochten ferlern

Wy kinne ek ynstallearje ha-promote-on-failure yn betsjutting when-synced. Yn dit gefal, ynstee fan werom te rôljen nei de spegel, sil de wachtrige wachtsje oant Broker 1 mei syn gegevens weromkomt nei online modus. Nei't it werom is, is de haadwachtrige werom op Broker 1 sûnder gegevensferlies. Beskikberens wurdt opoffere foar gegevensfeiligens. Mar dit is in risikofolle modus dy't sels liede kin ta folslein gegevensferlies, wêr't wy koart nei sille sjen.

Rys. 13. Wachtrige B bliuwt net beskikber nei it ferliezen fan Broker 1

Jo kinne freegje, "Is it better om nea automatyske syngronisaasje te brûken?" It antwurd is dat syngronisaasje in blokkearjende operaasje is. Tidens syngronisaasje kin de haadwachtrige gjin lês- of skriuwoperaasjes útfiere!

Litte wy nei in foarbyld sjen. No hawwe wy hiel lange wachtrigen. Hoe kinne se groeie ta sa'n grutte? Om ferskate redenen:

• Wachtrige wurde net aktyf brûkt
• Dit binne wachtrijen mei hege snelheid, en op it stuit binne konsuminten stadich
• It binne wachtrijen mei hege snelheid, d'r is in flater west en konsuminten binne ynhelle

Rys. 14. Twa grutte wachtrigen mei ferskillende syngronisaasje modus

No falt Broker 3.

Rys. 15. Broker 3 falt, leaving ien master en spegel yn elke wachtrige

Broker 3 komt werom online en nije spegels wurde makke. Haadwachtrige A begjint besteande berjochten te replikearjen nei de nije spegel, en yn dizze tiid is de wachtrige net beskikber. It duorret twa oeren om de gegevens te replikearjen, wat resulteart yn twa oeren downtime foar dizze wachtrige!

Wachtrige B bliuwt lykwols beskikber yn 'e heule perioade. Se offere wat oerstalligens op foar tagonklikens.

Rys. 16. Wachtrige bliuwt net beskikber tidens syngronisaasje

Nei twa oeren wurdt Wachtrige A ek beskikber en kin wer begjinne mei it akseptearjen fan lêzen en skriuwen.

Updates

Dit blokkearjende gedrach by syngronisaasje makket it lestich om klusters te aktualisearjen mei heul grutte wachtrigen. Op in stuit moat it masterknooppunt opnij starte, wat betsjut dat jo oerskeakelje nei in spegel of de wachtrige útskeakelje wylst de tsjinner opwurdearre wurdt. As wy kieze foar oergong, sille wy berjochten ferlieze as de spegels net syngronisearre binne. Standert, tidens in makelderútfal, wurdt in failover nei in net-syngronisearre spegel net útfierd. Dit betsjut dat sa gau as de makelder weromkomt, wy gjin berjochten ferlieze, de ienige skea wie in ienfâldige wachtrige. Gedrachsregels as in makelder is loskeppele wurde ynsteld troch belied ha-promote-on-shutdown. Jo kinne ien fan twa wearden ynstelle:

• always= oergong nei net-syngronisearre spegels is ynskeakele
• when-synced= oergong nei in syngronisearre spegel allinnich, oars wurdt de wachtrige net lêsber en net skriuwber. De wachtrige komt werom nei tsjinst sa gau as de makelder weromkomt

Op ien of oare manier, mei grutte wachtrigen moatte jo kieze tusken gegevensferlies en ûnbeskikberens.

Wannear't beskikberens gegevensfeiligens ferbettert

D'r is noch ien komplikaasje om te beskôgjen foardat jo in beslút nimme. Wylst automatyske syngronisaasje better is foar redundânsje, hoe hat it ynfloed op gegevensfeiligens? Fansels, mei bettere redundans, is RabbitMQ minder kâns om besteande berjochten te ferliezen, mar hoe sit it mei nije berjochten fan útjouwers?

Hjir moatte jo it folgjende beskôgje:

• Koe de útjouwer gewoan in flater weromjaan en de streamoptsjinst of brûker letter nochris besykje?
• Kin de útjouwer it berjocht lokaal of yn in databank bewarje om it letter nochris te besykjen?

As de útjouwer allinnich it berjocht kin wegerje, dan ferbettert de tagonklikens yn feite ek de gegevensfeiligens.

Sa moat in lykwicht socht wurde, en de oplossing hinget ôf fan de spesifike situaasje.

Problemen mei ha-promote-on-failure=wannear-syngronisearre

Idea ha-promote-op-mislearring= wannear-syngronisearre is dat wy it oerskeakeljen nei in net-syngronisearre spegel foarkomme en dêrmei gegevensferlies foarkomme. De wachtrige bliuwt net lêsber of skriuwber. Ynstee dêrfan besykje wy de ferûngelokke broker te herstellen mei syn gegevens yntakt, sadat it kin wurkje as master sûnder gegevensferlies.

Mar (en dit is in grut mar) as de brokker syn gegevens ferlern hat, dan hawwe wy in grut probleem: de wachtrige is ferlern! Alle gegevens binne fuort! Sels as jo spegels hawwe dy't meast de haadwachtrige ynhelje, wurde dy spegels ek fuorthelle.

Om in knooppunt mei deselde namme opnij ta te foegjen, fertelle wy it kluster de ferlerne knoop te ferjitten (mei it kommando rabbitmqctl forget_cluster_node) en begjinne in nije broker mei deselde hostnamme. Wylst it kluster it ferlerne knooppunt ûnthâldt, ûnthâldt it de âlde wachtrige en unsyngronisearre spegels. As in kluster wurdt ferteld om in weesknooppunt te ferjitten, wurdt dy wachtrige ek fergetten. No moatte wy it opnij ferklearje. Wy ferlearen alle gegevens, hoewol't wy hiene spegels mei in part set fan gegevens. It soe better wêze om te wikseljen nei in net-syngronisearre spegel!

Dêrom, hânmjittich syngronisaasje (en net syngronisearje) yn kombinaasje mei ha-promote-on-failure=when-synced, yn myn miening, frij riskant. De docs sizze dat dizze opsje bestiet foar gegevensfeiligens, mar it is in dûbelsnijd mes.

Master rebalancing

Lykas tasein, geane wy ​​werom nei it probleem fan 'e accumulation fan alle masters op ien of meardere knopen. Dit kin sels barre as gefolch fan in rôljende klusterupdate. Yn in kluster mei trije knooppunten sille alle master-wachtrijen sammelje op ien of twa knooppunten.

Rebalancing masters kin problematysk wêze om twa redenen:

• D'r binne gjin goede ark om rebalancing út te fieren
• Wachtrige syngronisaasje

Der is in tredde partij foar rebalancing ynstekke, dy't net offisjeel stipe wurdt. Oangeande plugins fan tredden yn 'e RabbitMQ-hantlieding sei: "De plugin leveret wat ekstra konfiguraasje- en rapportaazjeark, mar wurdt net stipe of ferifiearre troch it RabbitMQ-team. Brûk op eigen risiko."

D'r is in oare trúk om de haadwachtrige troch HA-belied te ferpleatsen. De hânlieding neamt skrift foar dit. It wurket sa:

• Ferwiderje alle spegels mei in tydlik belied dat in hegere prioriteit hat as it besteande HA-belied.
• Feroaret it tydlike belied fan HA om knooppuntmodus te brûken, en spesifisearret it knooppunt wêrnei't de masterwachtrige moat wurde oerdroegen.
• Syngronisearret de wachtrige foar push-migraasje.
• Neidat migraasje is foltôge, wisket it tydlike belied. It earste HA-belied giet yn en it fereaske oantal spegels wurdt makke.

It neidiel is dat dizze oanpak miskien net wurket as jo grutte wachtrijen hawwe of strange easken foar ûntslach.

Litte wy no sjen hoe't RabbitMQ-klusters wurkje mei netwurkpartysjes.

Ferlies fan ferbining

De knooppunten fan in ferspraat systeem wurde ferbûn troch netwurk keppelings, en netwurk keppelings kinne en wurde loskeppele. De frekwinsje fan ûnderbrekkingen hinget ôf fan 'e lokale ynfrastruktuer of de betrouberens fan' e selektearre wolk. Yn elts gefal moatte ferdielde systemen dêrmei omgean kinne. Nochris hawwe wy in kar tusken beskikberens en konsistinsje, en wer is it goede nijs dat RabbitMQ beide opsjes leveret (krekt net tagelyk).

Mei RabbitMQ hawwe wy twa haadopsjes:

• Tastean logyske ferdieling (split-brain). Dit soarget foar beskikberens, mar kin gegevensferlies feroarsaakje.
• Logyske skieding útskeakelje. Kin resultearje yn koarte termyn ferlies fan beskikberens ôfhinklik fan hoe't kliïnten ferbine mei it kluster. Kin ek liede ta folsleine ûnbeskikberens yn in twa-knooppuntkluster.

Mar wat is logyske skieding? Dit is as in kluster splitst yn twa fanwege ferlies fan netwurkferbiningen. Oan eltse kant wurde de spegels promovearre ta in master, sadat der úteinlik ferskate masters per beurt binne.

Rys. 17. Main wachtrige en twa spegels, elk op in apart knooppunt. Dan bart der in netwurkfout en komt ien spegel los. De skieden knooppunt sjocht dat de oare twa binne fallen ôf en befoarderet syn spegels nei de master. Wy hawwe no twa haadwachtrigen, sawol skriuwber as lêsber.

As útjouwers gegevens nei beide masters stjoere, komme wy út mei twa ôfwikende kopyen fan 'e wachtrige.

De ferskillende modi fan RabbitMQ jouwe beskikberens as konsistinsje.

Negearje modus (standert)

Dizze modus soarget foar tagonklikens. Nei it ferlies fan ferbining komt in logyske skieding foar. Nei't de ferbining wersteld is, moat de behearder beslute hokker partition foarrang te jaan. De ferliezende kant sil opnij starte en alle sammele gegevens op dy kant sille ferlern gean.

Rys. 18. Trije útjouwers binne ferbûn mei trije makelders. Ynterne rûtes it kluster alle oanfragen nei de haadwachtrige op Broker 2.

No binne wy ​​ferlieze Broker 3. Hy sjocht dat oare makelders binne fallen ôf en befoarderet syn spegel oan de master. Dit is hoe't in logyske skieding komt.

Rys. 19. Logyske ferdieling (split-brain). Records geane yn twa wichtichste wachtrigen, en de twa kopyen diverge.

Konnektivität wurdt hersteld, mar logyske skieding bliuwt. De behearder moat de ferliezende kant mei de hân selektearje. Yn it gefal hjirûnder start de behearder Broker 3 op 'e nij. Alle berjochten dy't hy net slagge om te ferstjoeren binne ferlern.

Rys. 20. De behearder skeakelet Broker 3 út.

Rys. 21. De behearder begjint Broker 3 en it slút oan by de kluster, ferlieze alle berjochten dy't wiene oerbleaun dêr.

By it ferlies fan ferbining en nei de restauraasje dêrfan wiene it kluster en dizze wachtrige beskikber foar lêzen en skriuwen.

Autoheal modus

Wurket fergelykber mei negearje modus, útsein dat it kluster sels automatysk kiest de ferliezende kant nei splitsen en weromsette ferbining. De ferliezende kant giet werom nei it kluster leech, en de wachtrige ferliest alle berjochten dy't allinich nei dy kant ferstjoerd binne.

Pause Minority Mode

As wy gjin logyske partitionering wolle tastean, dan is ús iennichste opsje om lêzen en skriuwen op 'e lytsere kant nei de klusterpartition te ferwiderjen. As de makelder sjocht dat it oan 'e lytsere kant is, stopet it wurk, dat is, it slút alle besteande ferbiningen en wegeret alle nije. Ien kear per sekonde kontrolearret it op restauraasje fan ferbining. Sadree't de ferbining is hersteld, ferfetsje it wurk en komt it by it kluster.

Rys. 22. Trije útjouwers binne ferbûn mei trije makelders. Ynterne rûtes it kluster alle oanfragen nei de haadwachtrige op Broker 2.

Brokers 1 en 2 splitst dan út Broker 3. Yn stee fan it befoarderjen fan har spegel ta master, suspendet Broker 3 en wurdt net beskikber.

Rys. 23. Broker 3 pauses, losket alle kliïnten, en fersmyt ferbining fersiken.

Sadree't de ferbining is hersteld, giet it werom nei it kluster.

Litte wy nei in oar foarbyld sjen wêr't de haadwachtrige is op Broker 3.

Rys. 24. Haadwachtrige op Broker 3.

Dan bart itselde ferlies fan ferbining. Broker 3 stopet om't it oan 'e lytsere kant is. Oan 'e oare kant sjogge de knooppunten dat Broker 3 ôffallen is, sadat de âldere spegel fan Brokers 1 en 2 wurdt promovearre ta master.

Rys. 25. Oergong nei Broker 2 as Broker 3 is net beskikber.

As de ferbining wurdt hersteld, sil Broker 3 by it kluster komme.

Rys. 26. It kluster is werom nei normale wurking.

It wichtige ding om hjir te begripen is dat wy konsistinsje krije, mar wy kinne ek beskikberens krije, if Wy sille kliïnten mei súkses oerdrage nei it grutste part fan 'e seksje. Foar de measte situaasjes soe ik persoanlik de Pause Minority-modus kieze, mar it hinget echt ôf fan it yndividuele gefal.

Om beskikberens te garandearjen, is it wichtich om te soargjen dat kliïnten mei súkses ferbine mei de host. Litte wy nei ús opsjes sjen.

It garandearjen fan klantferbining

Wy hawwe ferskate opsjes foar hoe't jo kliïnten rjochtsje nei it haaddiel fan it kluster of nei wurkjende knooppunten (nei't ien knooppunt mislearret) nei in ferlies fan ferbining. Lit ús earst betinke dat in spesifike wachtrige wurdt hosted op in spesifyk knooppunt, mar routing en belied wurde replikearre oer alle knooppunten. Klanten kinne ferbine mei elke knooppunt, en ynterne routing sil har rjochtsje wêr't se hinne moatte. Mar as in knooppunt wurdt ophâlden, wegeret it ferbinings, sadat kliïnten moatte ferbine mei in oare knooppunt. As it knooppunt falt, kin er net folle dwaan.

Us opsjes:

• It kluster wurdt tagonklik makke mei in load balancer dy't gewoan troch de knopen fytst en kliïnten opnij besykje te ferbinen oant suksesfol. As in knooppunt is del of ophâlden, dan besykjen om te ferbinen mei dat knooppunt sil mislearje, mar folgjende besykjen sil gean nei oare tsjinners (yn in round-robin moade). Dit is geskikt foar in koarte termyn ferlies fan Konnektivität as in delsleine tsjinner dy't gau wer omheech brocht wurdt.
• Tagong ta it kluster fia in load balancer en fuortsmite ophongen / mislearre knopen út de list sa gau as se wurde ûntdutsen. As wy dit fluch dogge, en as kliïnten de ferbining opnij kinne besykje, dan sille wy konstante beskikberens berikke.
• Jou elke kliïnt in list fan alle knopen, en de kliïnt kiest willekeurich ien fan har by it ferbinen. As it in flater ûntfangt by it besykjen om te ferbinen, ferpleatst it nei it folgjende knooppunt yn 'e list oant it ferbynt.
• Ferkear fuortsmite fan in mislearre / ophongen knooppunt mei DNS. Dit wurdt dien mei in lyts TTL.

befinings

RabbitMQ-klusterjen hat syn foardielen en neidielen. De meast serieuze neidielen binne dat:

• by it oansluten fan in kluster, knooppunten ferwiderje har gegevens;
• it blokkearjen fan syngronisaasje makket dat de wachtrige net beskikber wurdt.

Alle drege besluten komme út dizze twa arsjitektoanyske funksjes. As RabbitMQ gegevens koe bewarje as it kluster wer byinoar komt, dan soe syngronisaasje rapper wêze. As it yn steat wie om syngronisaasje net te blokkearjen, soe it grutte wachtrigen better stypje. It reparearjen fan dizze twa problemen soe de prestaasjes fan RabbitMQ gâns ferbetterje as in fouttolerante en heul beskikbere messagingtechnology. Ik soe wifkjend wêze om RabbitMQ oan te rieden mei klustering yn 'e folgjende situaasjes:

• Unbetrouber netwurk.
• Unbetroubere opslach.
• Hiel lange wachtrigen.

As it giet om ynstellings foar hege beskikberens, beskôgje dan it folgjende:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (of autoheal)
• oanhâldende berjochten
• soargje dat kliïnten ferbine mei it aktive knooppunt as guon knooppunt mislearret

Foar konsistinsje (gegevensfeiligens), beskôgje de folgjende ynstellings:

• Utjouwer befêstiget en hantlieding oan 'e konsumintkant
• ha-promote-on-failure=when-synced, as de útjouwers letter nochris besykje kinne en as jo tige betroubere opslach hawwe! Oars set =always.
• ha-sync-mode=automatic (mar foar grutte ynaktive wachtrijen kin hânmjittige modus ferplicht wurde; besjoch ek oft net-beskikberens berjochten ferlern gean sil)
• Pause Minority modus
• oanhâldende berjochten

Wy hawwe noch net alle problemen fan skuldtolerânsje en hege beskikberens behannele; bygelyks, hoe't jo feilich útfiere bestjoerlike prosedueres (lykas rolling updates). Wy moatte ek prate oer federaasje en de Shovel-plugin.

As ik noch wat mist haw, lit it my dan witte.

Sjoch ek myn post, wêr't ik in ferneatiging útfiere op in RabbitMQ-kluster mei Docker en Blockade om guon fan 'e senario's foar berjochtferlies te testen beskreaun yn dit artikel.

Foarige artikels yn 'e searje:
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

Boarne: www.habr.com