A tolleranza à i difetti è l'alta dispunibilità sò temi grandi, cusì dedicheremu articuli separati à RabbitMQ è Kafka. Questu articulu hè nantu à RabbitMQ, è u prossimu hè di Kafka, in paragone cù RabbitMQ. Questu hè un articulu longu, cusì fatevi còmode.
Fighjemu a tolleranza à i difetti, a coerenza è e strategie di alta dispunibilità (HA) è i compromessi chì ogni strategia face. RabbitMQ pò eseguisce nantu à un cluster di nodi - è dopu hè classificatu cum'è un sistema distribuitu. Quandu si tratta di sistemi distribuiti, spessu parlemu di cunsistenza è dispunibilità.
Questi cuncetti descrizanu cumu si cumporta un sistema quandu falla. Fiascu di cunnessione di a rete, fallimentu di u servitore, fallimentu di u discu duru, indisponibilità temporale di u servitore per via di raccolta di rifiuti, perdita di pacchetti, o rallentazione di a cunnessione di a rete. Tuttu chistu pò purtà à a perdita di dati o cunflitti. Risulta chì hè praticamenti impussibile di mette un sistema chì sia cumplettamente coherente (senza perdita di dati, senza divergenza di dati) è dispunibule (accettarà leghje è scrive) per tutti i scenarii di fallimentu.
Videremu chì a coherenza è a dispunibilità sò in l'estremità opposte di u spettru, è avete bisognu di sceglie quale modu per ottimisimu. A bona nutizia hè chì cù RabbitMQ sta scelta hè pussibule. Avete stu tipu di leve "nerdy" per trasfurmà l'equilibriu versu una più grande coerenza o più accessibilità.
Avemu da pagà una attenzione particulari à quali cunfigurazioni portanu a perdita di dati per via di i registri cunfirmati. Ci hè una catena di rispunsabilità trà editori, brokers è cunsumatori. Una volta chì u missaghju hè trasmessu à u broker, hè u so travagliu per ùn perde u missaghju. Quandu u broker ricunnosce u ricivutu di l'editore di u missaghju, ùn aspettemu micca persu. Ma videremu chì questu pò accade veramente secondu a vostra cunfigurazione di broker è editore.
Primitivi di Resilienza di un Nodu Unicu
Coda/Routing Resiliente
Ci hè dui tipi di fila in RabbitMQ: durable è micca durable. Tutte e file sò salvate in a basa di dati Mnesia. Queues durables sò ripubblicati à l'iniziu di u nodu è cusì sopravvive à riavvii, crashes di u sistema, o crashes di u servitore (finu chì i dati sò persistenti). Questu significa chì, finu à chì dichjarà u routing (scambiu) è a fila per esse resiliente, l'infrastruttura di fila / routing tornerà in linea.
A fila volatile è u routing sò eliminati quandu u node hè riavviatu.
missaghji persistenti
Solu perchè una fila hè durable ùn significa micca chì tutti i so messagi sopravviveranu à un riavviu di node. Solu i missaghji stabilitu da l'editore cum'è resistente (persistente). I missaghji persistenti creanu una carica supplementaria nantu à u broker, ma se a perdita di messagiu hè inacceptable, ùn ci hè micca altra opzione.
Risu. 1. Matrice di sustenibilità
Clustering cù mirroring di fila
Per sopravvive à a perdita di un broker, avemu bisognu di redundancy. Pudemu cunghjuntà parechji nodi RabbitMQ in un cluster, è dopu aghjunghje una redundanza supplementaria riplichendu file trà parechji nodi. In questu modu, se un node falla, ùn perdemu micca dati è restanu dispunibili.
Mirroring di fila:
- una fila principale (maestru), chì riceve tutti i cumandamenti di scrittura è lettura
- unu o più specchi chì ricevenu tutti i missaghji è metadata da a fila principale. Questi specchi ùn sò micca per scala, ma solu per a redundanza.
Risu. 2. Queue mirroring
Mirroring hè stabilitu da a pulitica adatta. In questu pudete selezziunate u coefficient di replicazione è ancu i nodi nantu à quale a fila deve esse situata. Esempii:
ha-mode: allha-mode: exactly, ha-params: 2(un maestru è un specchiu)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
Cunferma di l'editore
Per ottene una registrazione coherente, i Cunfirmazioni di l'Editore sò necessarii. Senza elli, ci hè un risicu di missaghji esse persu. Una cunferma hè mandata à l'editore dopu chì u messagiu hè scrittu à u discu. RabbitMQ scrive messagi à u discu micca nantu à u ricivutu, ma nantu à una basa periodica, in a regione di parechji centu millisecondi. Quandu una fila hè mirrored, un ricunniscenza hè mandatu solu dopu chì tutti i specchi anu scrittu ancu a so copia di u messagiu à u discu. Questu significa chì l'usu di cunferma aghjunghjenu a latenza, ma se a sicurità di dati hè impurtante, allora sò necessarii.
Fila di failover
Quandu un broker si abbanduneghja o si crash, tutti i capi di fila (maestri) nantu à quellu nodu si scontranu cun ellu. U cluster poi selezziunate u specchiu più anticu di ogni maestru è prumove cum'è u novu maestru.
Risu. 3. Multiple queues mirrored è e so pulitiche
Broker 3 fala. Nota chì u specchiu di Queue C in Broker 2 hè prumuvutu à maestru. Innota ancu chì un novu specchiu hè statu creatu per a Queue C in Broker 1. RabbitMQ sempre prova di mantene u fattore di replicazione specificatu in i vostri pulitiche.
Risu. 4. Broker 3 falla, facennu chì a fila C falla
U prossimu Broker 1 cade! Ci hè solu un broker. U specchiu Queue B hè prumuvutu à maestru.
Fig. 5
Avemu vultatu Broker 1. Indipendentemente da quantu i dati sopravvive à a perdita è a ricuperazione di u broker, tutti i missaghji di fila di specchi sò scartati dopu à riavvia. Questu hè impurtante per nutà perchè ci saranu cunsequenze. Fighjemu à sti implicazioni prestu. Allora Broker 1 hè avà un membru di u cluster di novu, è u cluster prova di rispettà e pulitiche è dunque crea specchi nantu à Broker 1.
In questu casu, a perdita di Broker 1 hè stata cumpleta, cum'è i dati, cusì a Coda B unmirrored hè stata completamente persa.
Risu. 6. Broker 1 torna à u serviziu
Broker 3 hè torna in linea, cusì e file A è B ripiglià i specchi creati nantu à ellu per suddisfà e so pulitiche HA. Ma avà tutte e file principali sò in un node! Questu hè micca ideale, una distribuzione uniforme trà i nodi hè megliu. Sfortunatamente, ùn ci sò micca assai opzioni quì per riequilibrà i maestri. Riturneremu à questu prublema dopu perchè avemu bisognu di guardà prima a sincronizazione di a fila.
Risu. 7. Broker 3 torna à u serviziu. Tutte e file principali nantu à un node!
Allora avà duvete avè una idea di cumu i specchi furnisce ridondanza è tolleranza à i difetti. Questu assicura a dispunibilità in casu di fallimentu di un unicu node è prutegge da a perdita di dati. Ma ùn avemu micca finitu ancu, perchè in realtà hè assai più cumplicatu.
Sincronizà
Quandu creanu un novu specchiu, tutti i novi messagi seranu sempre replicati à questu specchiu è qualsiasi altri. In quantu à i dati esistenti in a fila maestru, pudemu riplicà à un novu specchiu, chì diventa una copia completa di u maestru. Pudemu ancu sceglie micca di riplicà i missaghji esistenti è lascià a fila principale è u novu specchiu cunvergenu in u tempu, cù novi messagi chì arrivanu à a cuda è i missaghji esistenti abbandunendu u capu di a fila principale.
Questa sincronizazione hè realizata automaticamente o manualmente è hè gestita cù una pulitica di fila. Fighjemu un esempiu.
Avemu duie file di specchi. Queue A hè sincronizatu automaticamente, è Queue B hè sincronizatu manualmente. E duie file cuntenenu dece missaghji.
Risu. 8. Dui fila cù diversi modi di sincronizazione
Avà perdemu Broker 3.
Risu. 9. Broker 3 cascò
Broker 3 torna in serviziu. U cluster crea un specchiu per ogni fila nantu à u novu node è sincronizza automaticamente a nova Queue A cù u maestru. Tuttavia, u specchiu di a nova Queue B ferma viotu. In questu modu avemu a redundanza cumpleta nantu à a Fila A è solu un specchiu per i missaghji esistenti di a Fila B.
Risu. 10. U novu specchiu di Queue A riceve tutti i missaghji esistenti, ma u novu specchiu di Queue B ùn hè micca.
Dece messagi più arrivanu in e duie file. Broker 2 poi crashes è Queue A rolls daretu à u specchiu più anticu, chì hè nantu Broker 1. Ùn ci hè micca perdita di dati quandu si fiasca. In Queue B, ci sò vinti missaghji in u maestru è solu dece in u specchiu perchè sta fila ùn hà mai riplicatu i deci missaghji originali.
Risu. 11. Queue A rolls back to Broker 1 senza perde missaghji
Dece messagi più arrivanu in e duie file. Avà Crash Broker 1. Queue A cambia facilmente à u specchiu senza perde missaghji. Tuttavia, Queue B hà prublemi. À questu puntu pudemu ottimisà a dispunibilità o a cunsistenza.
Se vulemu ottimisà l'accessibilità, allora a pulitica ha-promuove-su-fallimentu deve esse stallatu in sempri. Questu hè u valore predeterminatu, perchè ùn pudete micca solu specificà a pulitica in tuttu. In questu casu, simu essenzialmente chì permettenu fallimenti in specchi micca sincronizati. Questu pruvucarà i missaghji per esse persu, ma a fila resterà leggibile è scrivibile.
Risu. 12. Queue A hè ritruvatu à Broker 3 senza perde missaghji. Queue B torna à Broker 3 cù dece missaghji persi
Pudemu ancu installà ha-promote-on-failure in significatu when-synced. In questu casu, invece di vultà in u specchiu, a fila aspittàrà finu à chì u Broker 1 cù i so dati torna in modu online. Dopu chì torna, a fila principale hè tornata nantu à Broker 1 senza perdita di dati. A dispunibilità hè sacrificata per a sicurità di dati. Ma questu hè un modu risicatu chì pò ancu purtà à a perdita di dati cumpleta, chì avemu da fighjà prestu.
Risu. 13. Queue B resta indisponibile dopu avè persu Broker 1
Pudete dumandà: "Hè megliu ùn mai aduprà a sincronizazione automatica?" A risposta hè chì a sincronizazione hè una operazione di bloccu. Durante a sincronizazione, a fila principale ùn pò micca fà operazioni di lettura o scrittura!
Fighjemu un esempiu. Avà avemu una fila assai longa. Cumu ponu cresce à una tale dimensione? Per parechje ragioni:
- Queues ùn sò micca aduprate attivamente
- Quessi sò file d'alta veloce, è avà i cunsumatori sò lenti
- Si tratta di file d'alta velocità, ci hè statu un glitch è i cunsumatori si ritrovanu
Risu. 14. Dui fila grande cù diversi modi di sincronizazione
Avà Broker 3 cade.
Risu. 15. Broker 3 casca, lassannu un maestru è specchiu in ogni fila
Broker 3 torna in linea è sò creati novi specchi. A Coda Principale A cumencia à riplicà i missaghji esistenti à u novu specchiu, è in questu tempu a Coda ùn hè micca dispunibule. Ci hè bisognu di duie ore per riplicà e dati, chì si traduce in duie ore di downtime per questa fila!
Tuttavia, Queue B resta dispunibule per tuttu u periodu. Ella sacrificò una certa redundanza per l'accessibilità.
Risu. 16. Queue resta indisponibile durante a sincronizazione
Dopu duie ore, a Fila A diventa ancu dispunibule è pò cumincià à accettà di novu letture è scrive.
Updi
Stu cumpurtamentu di bloccu durante a sincronizazione rende difficiuli di aghjurnà clusters cù fila assai grande. À un certu puntu, u node maestru deve esse riavviatu, chì significa o cambià à un specchiu o disattivà a fila mentre u servitore hè aghjurnatu. Sè avemu sceglie a transizione, avemu da perde missaghji s'è i specchi ùn sò synchronized. Per automaticamente, durante l'interruzione di un broker, un failover à un specchiu micca sincronizatu ùn hè micca realizatu. Questu significa chì quandu u broker torna, ùn perdemu micca messagi, l'unicu dannu era una fila simplice. E regule di cumpurtamentu quandu un broker hè disconnected sò stabilite da a pulitica ha-promote-on-shutdown. Pudete stabilisce unu di dui valori:
always= a transizione à i specchi micca sincronizzati hè attivatawhen-synced= transizione à un specchiu sincronizatu solu, altrimenti a fila diventa illegibile è inscrivibile. A fila torna in serviziu appena u broker torna
Un modu o un altru, cù grande fila avete à sceglie trà a perdita di dati è indisponibilità.
Quandu a Disponibilità Impruva a Sicurezza di Dati
Ci hè una complicazione più à cunsiderà prima di piglià una decisione. Mentre a sincronizazione automatica hè megliu per a redundanza, cumu impacta a sicurità di e dati? Di sicuru, cù una redundanza megliu, RabbitMQ hè menu prubabile di perde i missaghji esistenti, ma chì ne di i missaghji novi da l'editori?
Quì avete bisognu di cunsiderà i seguenti:
- Puderia l'editore solu vultà un errore è avè u serviziu upstream o l'utilizatori pruvate di novu dopu?
- L'editore pò salvà u messagiu in u locu o in una basa di dati per pruvà più tardi?
Se l'editore pò solu scaccià u messagiu, allora in fattu, a migliurà l'accessibilità ancu migliurà a sicurità di dati.
Cusì, deve esse cercatu un equilibriu, è a suluzione dipende di a situazione specifica.
Prublemi cù ha-promote-on-failure = quandu-sync
Idea ha-promuove-su-fallimentu= quandu-sincronizatu hè chì impediscemu di passà à un specchiu unsynchronized è cusì evitemu a perdita di dati. A fila resta illegibile o scrivibile. Invece, avemu pruvatu à ritruvà u broker crashed cù i so dati intactu cusì chì si pò ripiglià funziunamentu cum'è un maestru senza perdita di dati.
Ma (è questu hè un grande ma) se u broker hà persu i so dati, allora avemu un grande prublema: a fila hè persa! Tutti i dati sò andati! Ancu s'è vo avete specchi chì soprattuttu catturà cù a fila principale, quelli specchi sò ancu scartati.
Per aghjunghje un node cù u stessu nome, dicemu à u cluster per scurdà u node persu (cù u cumandimu rabbitmqctl forget_cluster_node) è principià un novu broker cù u stessu hostname. Mentre u cluster si ricorda di u node persu, si ricorda di a vechja fila è specchi non sincronizati. Quandu un cluster hè dettu di scurdà un node orfanu, quella fila hè ancu scurdata. Avà avemu bisognu di ridichjarà. Avemu persu tutti i dati, ancu s'è avemu avutu specchi cù un settore parziale di dati. Saria megliu cambià à un specchiu micca sincronizatu !
Dunque, a sincronizazione manuale (è fallimentu di sincronizà) in cumminazione cù ha-promote-on-failure=when-synced, in my opinion, abbastanza risicatu. I documenti dicenu chì sta opzione esiste per a sicurità di dati, ma hè un cuteddu à doppia tagliu.
Maestru riequilibriu
Comu prumessu, turnemu à u prublema di l'accumulazione di tutti i maestri nantu à unu o parechji nodi. Questu pò ancu accade com'è u risultatu di una aghjurnazione di cluster rolling. In un cluster di trè nodi, tutte e file maestri s'acumuleranu nantu à unu o dui nodi.
I maestri di reequilibriu pò esse problematicu per dui motivi:
- Ùn ci sò micca boni strumenti per fà u rebalancing
- Sincronizazione di a fila
Ci hè un terzu per rebalancing , chì ùn hè micca supportatu ufficialmente. In quantu à i plugins di terzu in u manuale di RabbitMQ : "U plugin furnisce alcune cunfigurazioni supplementari è strumenti di rapportu, ma ùn hè micca supportatu o verificatu da a squadra RabbitMQ. Aduprate à u vostru propiu risicu ".
Ci hè un altru truccu per spustà a fila principale attraversu e pulitiche HA. U manuale menziona per questu. Funziona cusì:
- Elimina tutti i specchi utilizendu una pulitica temporale chì hà una priorità più altu ch'è a pulitica HA esistente.
- Cambia a pulitica temporale HA per utilizà u modu di node, specificendu u node à quale a fila maestra deve esse trasferita.
- Sincronizza a fila per a migrazione push.
- Dopu chì a migrazione hè cumpleta, sguassate a pulitica temporale. A pulitica iniziale di HA entra in vigore è u numeru necessariu di specchi hè creatu.
U svantaghju hè chì questu approcciu ùn pò micca travaglià s'è vo avete grandi file o esigenze strette di redundancy.
Avà vedemu cumu i clusters RabbitMQ funzionanu cù partizioni di rete.
Disrupzione di a cunnessione
I nodi di un sistema distribuitu sò cunnessi da i ligami di a rete, è i ligami di a rete ponu è seranu disconnected. A frequenza di l'outages dipende da l'infrastruttura lucale o l'affidabilità di u nuvulu sceltu. In ogni casu, i sistemi distribuiti devenu esse capaci di affruntà cun elli. Una volta avemu una scelta trà dispunibilità è cunsistenza, è dinò a bona nutizia hè chì RabbitMQ furnisce e duie opzioni (solu micca à u stessu tempu).
Cù RabbitMQ avemu duie opzioni principali:
- Permette a divisione logica (split-brain). Questu assicura a dispunibilità, ma pò causà a perdita di dati.
- Disattivà a separazione logica. Pò esse risultatu in una perdita di dispunibilità à cortu termine, secondu cumu i clienti cunnettanu à u cluster. Pò ancu purtà à una indisponibilità cumpleta in un cluster di dui nodi.
Ma chì hè a separazione logica? Questu hè quandu un cluster split in dui per a perdita di cunnessione di a rete. Da ogni latu, i specchi sò prumuvuti à un maestru, perchè ci sò eventualmente parechji maestri per turnu.
Risu. 17. Fila principale è dui specchi, ognunu nantu à un node separatu. Allora un fallimentu di a rete si trova è un specchiu diventa staccatu. U node separatu vede chì l'altri dui sò cascati è prumove i so specchi à u maestru. Avemu avà duie file principali, sia scrivibili sia leghjite.
Se l'editori mandanu dati à i dui maestri, finisci cù duie copie divergenti di a fila.
I diversi modi di RabbitMQ furniscenu dispunibilità o cunsistenza.
Ignora u modu (predeterminatu)
Stu modu assicura l'accessibilità. Dopu à a perdita di cunnessione, si faci una separazione logica. Dopu chì a cunnessione hè restaurata, l'amministratore deve decide quale partizione dà priorità. U latu pèrdite sarà riiniziata è tutti i dati accumulate nant'à chì latu sarà persu.
Risu. 18. Trè editori sò assuciati cù trè brokers. Internamente, u cluster indirizza tutte e dumande à a fila principale in Broker 2.
Avà perdemu Broker 3. Vide chì altri brokers sò cascati è prumove u so specchiu à u maestru. Questu hè cumu si faci una separazione logica.
Risu. 19. Divisione logica (split-brain). I registri entranu in duie file principali, è e duie copie divergenu.
A cunnessione hè restaurata, ma a separazione logica resta. L'amministratore deve selezziunà manualmente u latu perde. In u casu sottu, l'amministratore reboots Broker 3. Tutti i missaghji chì ùn hà micca riesciutu à trasmette sò persi.
Risu. 20. L'amministratore disattiva Broker 3.
Risu. 21. L'amministratore principia Broker 3 è si unisce à u cluster, perde tutti i missaghji chì sò stati lasciati.
Durante a perdita di cunnessione è dopu a so risturazione, u cluster è sta fila eranu dispunibili per leghje è scrive.
Modu autoheal
Funziona in modu simile à Ignore, salvu chì u cluster stessu sceglie automaticamente u latu persu dopu a splitting and restauration connectivity. U latu perde torna à u cluster viotu, è a fila perde tutti i missaghji chì sò stati mandati solu à quellu latu.
Pause Mode Minorità
Se ùn vulemu micca permette a partizione logica, allora a nostra unica opzione hè di scaccià leghje è scrive nantu à u latu più chjucu dopu a partizione di cluster. Quandu u broker vede chì hè in u latu più chjucu, sospende u travagliu, vale à dì, chjude tutte e cunnessione esistenti è ricusa qualsiasi novi. Una volta per seconda verifica a risturazione di a cunnessione. Una volta a cunnessione hè restaurata, ripiglià l'operazione è si unisce à u cluster.
Risu. 22. Trè editori sò assuciati cù trè brokers. Internamente, u cluster indirizza tutte e dumande à a fila principale in Broker 2.
I Brokers 1 è 2 sò spartuti da Broker 3. Invece di prumove u so specchiu à maestru, Broker 3 suspende è diventa indisponibile.
Risu. 23. Broker 3 mette in pausa, disconnects all clients, è rifiuta e dumande di cunnessione.
Una volta a cunnessione hè restaurata, torna à u cluster.
Fighjemu un altru esempiu induve a fila principale hè in Broker 3.
Risu. 24. Fila principale nantu à u Broker 3.
Allora a stessa perdita di cunnessione si trova. U broker 3 si mette in pausa perchè hè in u latu più chjucu. Da l'altra parte, i nodi vedenu chì u Broker 3 hè cascatu, cusì u specchiu più vechju di Brokers 1 è 2 hè prumuvutu à maestru.
Risu. 25. Transizione à Broker 2 se Broker 3 ùn hè micca dispunibule.
Quandu a cunnessione hè restaurata, Broker 3 uniscerà à u cluster.
Risu. 26. U cluster hè tornatu à u funziunamentu normale.
L'impurtante di capisce quì hè chì avemu a coerenza, ma pudemu ancu ottene dispunibilità, si Trasferiremu bè i clienti à a maiò parte di a sezione. Per a maiò parte di e situazioni, personalmente sceglieraghju u modu Pause Minority, ma veramente dipende da u casu individuale.
Per assicurà a dispunibilità, hè impurtante per assicurà chì i clienti cunnetta bè cù l'ospite. Fighjemu e nostre opzioni.
Assicurendu a Connettività di u Cliente
Avemu parechje opzioni per cumu dirighjenu i clienti à a parte principale di u cluster o à i nodi di travagliu (dopu chì un node falla) dopu una perdita di cunnessione. Prima, ricurdatemu chì una fila specifica hè ospitata nantu à un node specificu, ma u routing è e pulitiche sò replicati in tutti i nodi. I clienti ponu cunnette à qualsiasi nodu, è u routing internu li dirigerà induve anu bisognu à andà. Ma quandu un node hè suspesu, rifiuta e cunnessione, cusì i clienti devenu cunnette à un altru node. Se u node cascà, ci hè pocu chì pò fà in tuttu.
Le nostre opzioni:
- U cluster hè accessatu utilizendu un equilibratore di carica chì simpricimenti ciculi attraversu i nodi è i clienti riprovanu a cunnessione finu à successu. Se un node hè chjusu o suspesu, allora i tentativi di cunnette à quellu node fallenu, ma i tentativi successivi andaranu à altri servitori (in una moda round-robin). Questu hè adattatu per una perdita di cunnessione à cortu termine o un servitore abbattutu chì serà rimbursatu rapidamente.
- Accede à u cluster attraversu un balancer di carica è sguassate i nodi suspesi / falluti da a lista appena sò rilevati. Se facemu questu rapidamente, è se i clienti sò capaci di ripruvà a cunnessione, allora avemu da ottene una dispunibilità constante.
- Dà à ogni cliente una lista di tutti i nodi, è u cliente sceglie in modu aleatoriu unu di elli quandu si cunnetta. Se riceve un errore quandu prova di cunnette, si move à u prossimu node in a lista finu à ch'ellu si cunnetta.
- Eliminate u trafficu da un nodu fallutu / sospesu utilizendu DNS. Questu hè fattu cù un picculu TTL.
scuperti
RabbitMQ clustering hà i so vantaghji è svantaghji. I svantaghji più serii sò chì:
- quandu si uniscenu à un cluster, i nodi scartanu i so dati;
- bluccà a sincronizazione face chì a fila ùn sia micca dispunibule.
Tutte e decisioni difficili derivanu da queste duie caratteristiche architettoniche. Se RabbitMQ puderia salvà dati quandu u cluster hè riunitu, allora a sincronizazione seria più veloce. S'ellu era capace di sincronizazione senza bloccu, saria megliu sustene e fila grande. A correzione di sti dui prublemi hà da migliurà assai u rendiment di RabbitMQ cum'è una tecnulugia di messageria tollerante à i difetti è altamente dispunibuli. Saria esitante à ricumandà RabbitMQ cù clustering in e seguenti situazioni:
- Rete inaffidabile.
- Almacenamiento inaffidabile.
- Fila assai longa.
Quandu si tratta di paràmetri di alta dispunibilità, cunzidira i seguenti:
ha-promote-on-failure=alwaysha-sync-mode=manualcluster_partition_handling=ignore(oautoheal)- missaghji persistenti
- assicuratevi chì i clienti cunnettanu à u node attivu quandu qualchì nodu falla
Per a coerenza (securità di dati), cunzidira i seguenti paràmetri:
- L'editore cunfirma è ricunniscenza manuale da u latu di u cunsumadore
ha-promote-on-failure=when-synced, Se l'editori ponu pruvà di novu dopu è si avete un almacenamentu assai affidabile! Altrimenti mette=always.ha-sync-mode=automatic(ma per grandi file inattive u modu manuale pò esse necessariu; cunsiderà ancu se a indisponibilità pruvucarà a perdita di i missaghji)- Pausa u modu Minuritariu
- missaghji persistenti
Ùn avemu micca cupertu tutti i prublemi di tolleranza di difetti è alta dispunibilità; per esempiu, cumu fà in modu sicuru e prucedure amministrative (cum'è l'aghjurnamenti rolling). Avemu ancu bisognu di parlà di a federazione è di u plugin Shovel.
Sè aghju mancatu qualcosa d'altru, fatemi sapè.
Vede ancu u mo , induve aghju realizatu un caos in un cluster RabbitMQ cù Docker è Blockade per pruvà alcuni di i scenarii di perdita di missaghju descritti in questu articulu.
Articuli precedenti in a serie:
No. 1 -
No. 2 -
No. 3 -
Source: www.habr.com