В ultimu articulu avemu guardatu à u clustering RabbitMQ per a tolleranza di difetti è alta dispunibilità. Avà scavamu in profondità in Apache Kafka.

Quì l'unità di replicazione hè a partizione. Ogni tema hà una o più sezzioni. Ogni sezione hà un capu cù o senza seguitori. Quandu crea un tema, specificate u numeru di partizioni è u coefficient di replicazione. U valore abituale hè 3, chì significa trè rèpliche: un capu è dui seguitori.

Risu. 1. Quattru sezzioni sò distribuiti trà trè brokers

Tutte e dumande di lettura è scrittura vanu à u capu. I seguitori periodicamente mandanu dumande à u capu per riceve l'ultimi messagi. I cunsumatori ùn si giranu mai à i seguitori; l'ultimi esistenu solu per a redundanza è a tolleranza di difetti.

fallimentu di partition

Quandu un broker falla, i capi di parechje sezioni spessu fallenu. In ognunu di elli, un seguitore da un altru node diventa u capu. In fatti, questu ùn hè micca sempre u casu, postu chì u fattore di sincronizazione influenza ancu: s'ellu ci sò seguitori sincronizati, è s'ellu ùn hè micca, allora s'ellu hè permessu di cambià à una replica non sincronizata. Ma ùn complichemu micca e cose per avà.

Broker 3 lascia a reta, è un novu capu hè elettu per a sezione 2 à u broker 2.

Risu. 2. Broker 3 mori è u so seguitore nantu à u broker 2 hè elettu cum'è u novu capu di a partizione 2

Allora u broker 1 parte è a sezione 1 perde ancu u so capu, chì u so rolu passa à u broker 2.

Risu. 3. Ci hè un broker left. Tutti i capi sò nantu à un broker cù zero redundancy

Quandu u broker 1 torna in linea, aghjunghje quattru seguitori, furnisce una certa redundanza à ogni partizione. Ma tutti i capi sò sempre stati nantu à u broker 2.

Risu. 4. I dirigenti restanu nantu à u broker 2

Quandu u broker 3 vene, simu di ritornu à trè repliche per partizione. Ma tutti i capi sò sempre nantu à u broker 2.

Risu. 5. U piazzamentu sbilanciatu di i capi dopu a risturazione di i brokers 1 è 3

Kafka hà un strumentu per un megliu riequilibriu di u capu di RabbitMQ. Quì, avete avutu aduprà un plugin o script di terzu chì hà cambiatu e pulitiche per a migrazione di u nodu maestru riducendu a redundanza durante a migrazione. Inoltre, per e fila grande avemu avutu à accettà indisponibilità durante a sincronizazione.

Kafka hà u cuncettu di "repliche preferite" per u rolu di capu. Quandu si creanu partizioni tematiche, Kafka prova di distribuisce i capi in modu uniforme trà i nodi è marca quelli primi capi cum'è preferiti. À u tempu, per via di reboots di u servitore, fallimenti è rotture di cunnessione, i dirigenti ponu finisce in altri nodi, cum'è in u casu estremu descrittu sopra.

Per risolve questu, Kafka offre duie opzioni:

• Opzione auto.leader.rebalance.enable=true permette à u nodu di cuntrollu di riassignà automaticamente i dirigenti in repliche preferite è cusì restaurà a distribuzione uniforme.
• L'amministratore pò eseguisce u script kafka-preferred-replica-election.sh per riassegnazione manuale.

Risu. 6. Replicas after rebalancing

Questa era una versione simplificata di u fallimentu, ma a realità hè più cumplessa, ancu s'ellu ùn ci hè nunda troppu cumplicatu quì. Tuttu vene à repliche sincronizate (In-Sync Replicas, ISR).

Repliche sincronizzate (ISR)

Un ISR hè un inseme di repliche di una partizione chì hè cunsiderata "sincronizzata" (in-sync). Ci hè un capu, ma ùn pò esse micca seguitori. Un seguitore hè cunsideratu sincronizatu s'ellu hà fattu copie esatti di tutti i missaghji di u capu prima chì l'intervallu scade replica.lag.time.max.ms.

Un seguitore hè eliminatu da u set ISR s'ellu:

• ùn hà micca fattu una dumanda per selezziunà per l'intervallu replica.lag.time.max.ms (présumé mort)
• ùn hà micca riesciutu à aghjurnà durante l'intervallu replica.lag.time.max.ms (consideratu lento)

I seguitori facenu dumande di campionamentu in l'intervallu replica.fetch.wait.max.ms, chì hè predeterminatu à 500 ms.

Per spiegà chjaramente u scopu di l'ISR, avemu bisognu di guardà cunferma da u pruduttore è certi scenarii di fallimentu. I pruduttori ponu sceglie quandu u broker manda cunferma:

• acks=0, a cunferma ùn hè micca mandata
• acks=1, a cunferma hè mandata dopu chì u capu hà scrittu un missaghju à u so logu lucale
• acks=all, a cunferma hè mandata dopu chì tutte e rèpliche in l'ISR anu scrittu u messagiu à i logs lucali

In a terminologia Kafka, se l'ISR hà salvatu un missaghju, hè "impegnu". Acks=all hè l'opzione più sicura, ma aghjunghje ancu ritardu supplementu. Fighjemu dui esempi di fallimentu è cumu e diverse opzioni "acks" interagiscenu cù u cuncettu ISR.

Acks=1 è ISR

In questu esempiu, avemu da vede chì s'è u capimachja ùn aspittà ogni missaghju da tutti i seguitori à esse salvatu, allura a perdita di dati hè pussibili s'è u capu falla. A navigazione à un seguitore micca sincronizatu pò esse attivatu o disattivatu da a paràmetra unclean.leader.election.enable.

In questu esempiu, u fabricatore hà u valore acks = 1. A sezione hè distribuita in tutti i trè brokers. Broker 3 hè daretu, hè sincronizatu cù u capu ottu seconde fà è hè avà 7456 missaghji daretu. Broker 1 era solu un secondu daretu. U nostru pruduttore manda un missaghju è riceve rapidamente un ack back, senza u sopratuttu di seguitori lenti o morti chì u capu ùn aspetta micca.

Risu. 7. ISR cù trè repliche

Broker 2 falla è u pruduttore riceve un errore di cunnessione. Dopu chì a dirigenza passa à u broker 1, perdemu 123 missaghji. U seguitu nantu à u broker 1 era parti di l'ISR, ma ùn era micca cumpletamente sincronizatu cù u capu quandu hè cascatu.

Risu. 8. I missaghji sò persu quandu si crashes

In cunfigurazione bootstrap.servers U fabricatore hà parechji brokers listati è ponu dumandà à un altru broker chì hè u novu capu di a sezione. Dopu stabilisce una cunnessione à u broker 1 è cuntinueghja à mandà missaghji.

Risu. 9. Mandatu missaghji riprende dopu à una breve pausa

Broker 3 hè ancu più daretu. Face richieste di ricuperazione ma ùn pò micca sincronizà. Questu pò esse dovutu à a cunnessione di rete lenta trà i brokers, u prublema di almacenamiento, etc. Hè sguassatu da l'ISR. Avà l'ISR hè custituitu da una replica - u capu! U fabricatore cuntinueghja à mandà missaghji è riceve cunferma.

Risu. 10. Follower on broker 3 hè sguassatu da l'ISR

U broker 1 scende è u rolu di dirigenza passa à u broker 3 cù a perdita di 15286 missaghji! U fabricatore riceve un missaghju d'errore di cunnessione. A transizione à un capu fora di l'ISR era pussibule solu per via di l'ambientazione unclean.leader.election.enable=veru. S'ellu hè stallatu in sbagliate, tandu a transizione ùn accade micca è tutte e dumande di lettura è scrittura seranu rifiutate. In questu casu, aspittemu chì u broker 1 torna cù i so dati intactu in a replica, chì ripiglià di novu a dirigenza.

Risu. 11. Broker 1 cascà. Quandu si faci un fallimentu, un gran numaru di missaghji sò persi

U pruduttori stabilisce una cunnessione cù l'ultimu broker è vede chì avà hè u capu di a sezione. Cumincia à mandà missaghji à u broker 3.

Risu. 12. Dopu à una breve pausa, i missaghji sò mandati di novu à a rùbbrica 0

Avemu vistu chì, fora di brevi interruzzioni per stabilisce novi cunnessione è circà un novu capu, u fabricatore mandava constantemente missaghji. Sta cunfigurazione assicura a dispunibilità à a spesa di a coerenza (securità di dati). Kafka hà persu millaie di missaghji, ma hà cuntinuatu à accettà novi scritti.

Acks = tutti è ISR

Ripitemu dinò stu scenariu, ma cun acks = tutti. Broker 3 hà una latenza media di quattru seconde. U fabricatore manda un missaghju cù acks = tutti, è avà ùn riceve micca una risposta rapida. U capu aspetta chì u messagiu sia salvatu da tutte e rèpliche in l'ISR.

Risu. 13. ISR cù trè repliche. Unu hè lento, risultatu in ritardu di registrazione

Dopu quattru seconde di ritardu supplementu, u broker 2 manda un ack. Tutte e repliche sò avà cumplettamente aghjurnati.

Risu. 14. All replicas salvà missaghji è mandà ack

Broker 3 hè avà più in daretu è hè sguassatu da l'ISR. A latenza hè significativamente ridutta perchè ùn ci sò micca rèpliche lente in l'ISR. Broker 2 avà aspetta solu per u broker 1, è hà un lag mediu di 500 ms.

Risu. 15. A replica nantu à u broker 3 hè eliminata da l'ISR

Allora u broker 2 casca è a dirigenza passa à u broker 1 senza perdita di missaghji.

Risu. 16. Broker 2 cascà

U fabricatore trova un novu capu è cumencia à mandà missaghji à ellu. A latenza hè più ridutta perchè l'ISR hè avà custituitu da una replica! Dunque l'opzione acks = tutti ùn aghjunghje micca a redundanza.

Risu. 17. Replica nantu à u broker 1 piglia a guida senza perde i missaghji

Allora u broker 1 crashs and the lead goes to broker 3 cù una perdita di 14238 missaghji!

Risu. 18. Broker 1 mori è a transizione di dirigenza cù l'ambienti impuri risultati in una larga perdita di dati

Ùn pudemu micca installà l'opzione unclean.leader.election.enable in significatu vera. Per automaticamente, hè uguale à sbagliate. Settings acks = tutti с unclean.leader.election.enable=veru furnisce l'accessibilità cù una certa sicurezza di dati aghjuntu. Ma comu si pò vede, si pò sempre perde missaghji.

Ma chì si vulemu aumentà a sicurità di dati? Pudete mette unclean.leader.election.enable = falsu, ma questu ùn hà micca bisognu di prutezzione di a perdita di dati. Se u capu hè cascatu duramente è hà pigliatu i dati cun ellu, i missaghji sò sempre persi, più a dispunibilità hè persa finu à chì l'amministratore restaurà a situazione.

Hè megliu per assicurà chì tutti i missaghji sò redundant, è altrimenti scartà a registrazione. Allora, almenu da u puntu di vista di u broker, a perdita di dati hè pussibule solu in casu di dui o più fallimenti simultanei.

Acks=all, min.insync.replicas è ISR

Cù cunfigurazione tematica min.insync.replicas Aumentemu u livellu di sicurità di dati. Andemu per l'ultima parte di u scenariu precedente di novu, ma sta volta cun min.insync.replicas=2.

Allora u broker 2 hà un capu di replica è u seguitore nantu à u broker 3 hè eliminatu da l'ISR.

Risu. 19. ISR da dui replicati

U broker 2 casca è a dirigenza passa à u broker 1 senza perdita di missaghji. Ma avà l'ISR hè custituitu da una sola replica. Questu ùn scontra micca u numeru minimu per riceve i registri, è per quessa u broker risponde à u tentativu di scrittura cù un errore Not EnoughReplicas.

Risu. 20. U numaru di ISR ​​hè unu più bassu di ciò chì specifica in min.insync.replicas

Questa cunfigurazione sacrifica a dispunibilità per a coerenza. Prima di ricunnosce un missaghju, avemu assicuratu chì hè scrittu à almenu duie rèpliche. Questu dà u fabricatore assai più fiducia. Quì, a perdita di missaghju hè pussibule solu se duie rèpliche fallenu simultaneamente in un cortu intervallu finu à chì u messagiu hè replicatu à un seguitore supplementu, chì hè improbabile. Ma sè site super paranoico, pudete stabilisce u fattore di replicazione à 5, è min.insync.replicas da 3. Quì trè brokers deve falà à tempu à perde u record! Di sicuru, paghete per questa affidabilità in latenza supplementu.

Quandu l'accessibilità hè necessariu per a sicurità di dati

Cum'è in casu cù RabbitMQ, à volte l'accessibilità hè necessariu per a sicurità di dati. Eccu ciò chì avete bisognu di pensà:

• L'editore pò solu rinvià 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 a risposta hè no, allora l'ottimisazione di a dispunibilità migliurà a sicurità di e dati. Perdite menu dati se sceglite a dispunibilità invece di ùn arregistrà micca. Cusì, tuttu vene à truvà un equilibriu, è a decisione dipende da a situazione specifica.

U significatu di ISR

A suite ISR permette di sceglie l'equilibriu ottimale trà a sicurità di dati è a latenza. Per esempiu, assicuratevi a dispunibilità in casu di fallimentu di a maiò parte di e rèpliche, minimizendu l'impattu di rèplichi morti o lenti in termini di latenza.

Avemu sceltu u significatu noi stessi replica.lag.time.max.ms secondu i vostri bisogni. Essenzialmente, stu paràmetru significa quantu ritardu simu disposti à accettà quandu acks = tutti. U valore predeterminatu hè dece seconde. Se questu hè troppu longu per voi, pudete riduce. Allora a freccia di i cambiamenti in l'ISR aumenterà, postu chì i seguitori seranu eliminati è aghjunghje più spessu.

RabbitMQ hè solu un inseme di specchi chì deve esse replicatu. I specchi lenti introducenu una latenza supplementaria, è i specchi morti ponu aspittà finu à chì i pacchetti chì verificanu a dispunibilità di ogni nodu (tick net) per risponde. ISR hè un modu interessante per evità questi prublemi di latenza. Ma risichemu di perde a redundanza postu chì l'ISR pò solu riduzzione à u capu. Per evitari stu risicu, utilizate u paràmetru min.insync.replicas.

Garanzia di cunnessione di u cliente

In impostazioni bootstrap.servers U pruduttore è u cunsumadore ponu specificà parechji brokers per cunnette i clienti. L'idea hè chì quandu un node scende, ci sò parechji spare left cù quale u cliente pò apre una cunnessione. Questi ùn sò micca necessariamente capi di sezione, ma solu un trampolinu per a carica iniziale. U cliente pò dumandà à quale nodu ospita u capu di partizioni di lettura / scrittura.

In RabbitMQ, i clienti ponu cunnette à qualsiasi nodu, è u routing internu manda a dumanda à induve deve andà. Questu significa chì pudete installà un balancer di carica davanti à RabbitMQ. Kafka richiede à i clienti di cunnette cù u node chì ospita u capu di partizione currispundente. In una tale situazione, ùn pudete micca installà un balancer di carica. Lista bootstrap.servers Hè criticu chì i clienti ponu accede è truvà i nodi curretti dopu un fallimentu.

Kafka Consensus Architecture

Finu à avà, ùn avemu micca cunsideratu cumu u cluster ampara nantu à a caduta di u broker è cumu un novu capu hè elettu. Per capiscenu cumu Kafka travaglia cù partizioni di rete, avete prima bisognu di capiscenu l'architettura di cunsensu.

Ogni cluster Kafka hè implementatu inseme à un cluster Zookeeper, chì hè un serviziu di cunsensu distribuitu chì permette à u sistema di ghjunghje à u cunsensu annantu à un statu determinatu, priurità a coerenza nantu à a dispunibilità. U cunsensu di a maiò parte di i nodi Zookeeper hè necessariu per appruvà l'operazioni di lettura è scrittura.

Zookeeper guarda u statu di u cluster:

• Lista di temi, rùbbriche, cunfigurazione, rèpliche di capu attuale, rèpliche preferite.
• I membri di u cluster. Ogni broker ping u cluster Zookeeper. Se ùn riceve micca un ping in un periudu di tempu specificu, Zookeeper registra u broker cum'è indisponibile.
• Selezziunà i nodi principali è spare per u controller.

U node di cuntrollu hè unu di i brokers Kafka chì hè rispunsevule per l'elezzione di i capi di replica. Zookeeper manda notifiche à u controller nantu à l'appartenenza à u cluster è i cambiamenti di u tema, è u controller deve agisce nantu à questi cambiamenti.

Per esempiu, pigliemu un novu tema cù deci partizioni è un fattore di replicazione di 3. U controller deve elettu un capu per ogni partizione, pruvatu à distribuisce ottimali i capi trà i brokers.

Per ogni controller di sezione:

• aghjurnà l'infurmazioni in Zookeeper nantu à ISR è capu;
• Manda un LeaderAndISRCommand à ogni broker chì ospita una replica di sta partizione, informendu i brokers nantu à l'ISR è u capu.

Quandu un broker cun un capu cascà, Zookeeper manda una notificazione à u controller, è elege un novu capu. In novu, u controller prima aghjurnà Zookeeper è poi manda un cumandamentu à ogni broker chì li notificà u cambiamentu di dirigenza.

Ogni capu hè rispunsevule per reclutà ISR. Settings replica.lag.time.max.ms determina quale entrerà quì. Quandu l'ISR cambia, u capu trasmette nova infurmazione à Zookeeper.

Zookeeper hè sempre infurmatu di ogni cambiamentu in modu chì in casu di fallimentu, a gestione transizione liscia à un novu capu.

Risu. 21. Consensus Kafka

Protokollu di replicazione

Capisce i dettagli di a replicazione vi aiuta à capisce megliu i scenarii potenziali di perdita di dati.

Domande di campionamentu, Log End Offset (LEO) è Highwater Mark (HW)

Avemu cunsideratu chì i seguitori mandanu periodicamente richieste di ricerca à u capu. L'intervallu predeterminatu hè 500 ms. Questu differisce da RabbitMQ in chì in RabbitMQ a replicazione ùn hè micca iniziata da u specchiu di fila ma da u maestru. U maestru spinge cambiamenti à i specchi.

U capu è tutti i seguitori salvanu u Log End Offset (LEO) è l'etichetta Highwater (HW). A marca LEO guarda l'offset di l'ultimu messagiu in a replica lucale, è u HW mantene l'offset di l'ultimu commit. Ricurdativi chì per u statutu di cummissione, u missaghju deve esse persistente in tutte e repliche ISR. Questu significa chì LEO hè di solitu ligeramente davanti à HW.

Quandu u capu riceve un missaghju, u almacena in u locu. U seguitore face una dumanda di ricerca trasmettendu u so LEO. U capu poi manda un batch di missaghji partendu da stu LEO è trasmette ancu u HW attuale. Quandu u capu riceve infurmazione chì tutte e rèpliche anu guardatu u messagiu à l'offset datu, move a marca HW. Solu u capu pò spustà u HW, è cusì tutti i seguitori cunnosceranu u valore attuale in e risposte à a so dumanda. Questu significa chì i seguitori ponu ritardà u capu in u missaghju è in a cunniscenza HW. I cunsumatori ricevenu missaghji solu finu à u HW attuale.

Nota chì "persiste" significa scrittu à a memoria, micca à u discu. Per u rendiment, Kafka sincronizza à u discu à un intervallu specificu. RabbitMQ hà ancu un tali intervallu, ma mandarà un ricunniscenza à l'editore solu dopu chì u maestru è tutti i specchi anu scrittu u messagiu à u discu. I sviluppatori di Kafka, per ragioni di rendiment, anu decisu di mandà un ack appena u messagiu hè scrittu in memoria. Kafka scumette chì a redundanza compensa u risicu di guardà brevemente i missaghji ricunnisciuti solu in memoria.

fallimentu di u capu

Quandu un capu cade, Zookeeper notifica à u controller, è selezziunate una nova replica di capu. U novu capu stabilisce una nova marca HW secondu u so LEO. I seguitori ricevenu infurmazioni nantu à u novu capu. Sicondu a versione di Kafka, u seguitore sceglie unu di dui scenarii:

1. Truncarà u logu lucale à un HW cunnisciutu è mandà una dumanda à u novu capu per i missaghji dopu à sta marca.
2. Mandarà una dumanda à u capu per sapè u HW à u mumentu ch'ellu hè statu elettu capu, è dopu truncate u log à questu offset. Dopu cumminciarà à fà richieste di ricuperazione periodiche partendu da questu offset.

Un seguitore pò avè bisognu di truncà u log per i seguenti motivi:

• Quandu un capu falla, u primu seguitore in u settore ISR registratu cù Zookeeper vince l'elezzione è diventa u capu. Tutti i seguitori nantu à l'ISR, ancu s'ellu hè cunsideratu "in sincronia", ùn anu micca ricevutu copie di tutti i missaghji da l'anzianu capu. Hè interamente pussibule chì u seguitore presentatu ùn hà micca a copia più aghjurnata. Kafka assicura chì ùn ci hè micca divergenza trà e rèpliche. Cusì, per evità discrepanze, ogni seguitore deve truncate u so logu à u valore HW di u novu capu à u mumentu di a so elezzione. Questu hè un altru mutivu per quessa l'impostazione acks = tutti cusì impurtante per a coerenza.
• I missaghji sò scritti periodicamente à u discu. Se tutti i nodi di cluster fallenu à u stessu tempu, allora e repliche cù diverse offsets seranu guardati nantu à i dischi. Hè pussibule chì quandu i brokers tornanu in linea, u novu capu chì hè elettu serà daretu à i so seguitori perchè hè statu salvatu à u discu prima di l'altri.

Reunion with the cluster

Quandu si riuniscenu à u cluster, i rèplichi facenu u listessu cum'è quandu un capu falli: verificanu a replica di u capu è truncanu u so logu à u so HW (à u mumentu di l'elezzione). In paragone, RabbitMQ tratta ugualmente i nodi riuniti cum'è completamente novi. In i dui casi, u broker scarta ogni statu esistenti. Se a sincronizazione automatica hè aduprata, u maestru deve riplicà assolutamente tuttu u cuntenutu attuale à u novu specchiu in un metudu di "lascia chì u mondu sanu aspittà". U maestru ùn accetta micca operazioni di lettura o scrittura durante questa operazione. Stu approcciu crea prublemi in grande fila.

Kafka hè un logu distribuitu è ​​in generale guarda più messagi cà una fila RabbitMQ, induve e dati sò sguassati da a fila dopu à leghje. A fila attiva deve esse relativamente chjuca. Ma Kafka hè un logu cù a so propria pulitica di retenzioni, chì pò stabilisce un periodu di ghjorni o settimane. U bloccu di fila è l'approcciu di sincronizazione cumpleta hè assolutamente inaccettabile per un log distribuitu. Invece, i seguitori di Kafka simpricimenti truncate u so logu à u HW di u capu (à u mumentu di a so elezzione) se a so copia hè davanti à u capu. In u casu più prubabile, quandu u seguitore hè daretu, simpricimenti principia à fà richieste di ricuperazione cuminciendu cù u so LEO attuale.

I seguitori novi o riuniti cumincianu fora di l'ISR è ùn participanu micca à l'impegni. Simpricamente travaglianu à fiancu à u gruppu, ricevenu missaghji u più prestu pussibule finu à ch'elli ghjunghjenu à u capu è entre in l'ISR. Ùn ci hè micca serratura-in è ùn ci hè bisognu di scaccià tutti i vostri dati.

Disrupzione di a cunnessione

Kafka hà più cumpunenti di RabbitMQ, cusì hà un inseme più cumplessu di cumpurtamenti quandu u cluster hè disconnected. Ma Kafka hè stata urigginariamente pensata per i clusters, cusì e soluzioni sò assai ben pensate.

Quì sottu sò parechji scenarii di fallimentu di cunnessione:

• Scenariu 1: U seguitore ùn vede micca u capu, ma vede ancu u Zookeeper.
• Scenariu 2: U capu ùn vede micca seguitori, ma vede ancu Zookeeper.
• Scenariu 3: U seguitore vede u capu, ma ùn vede u Zookeeper.
• Scenariu 4: U capu vede i seguitori, ma ùn vede u Zookeeper.
• Scenariu 5: U seguitore hè completamente separatu da l'altri nodi Kafka è Zookeeper.
• Scenariu 6: U capu hè completamente separatu da l'altri nodi Kafka è Zookeeper.
• Scenariu 7: U node di cuntrollu Kafka ùn pò micca vede un altru node Kafka.
• Scenariu 8: U controller Kafka ùn vede micca Zookeeper.

Ogni scenariu hà u so propiu cumpurtamentu.

Scenariu 1: Follower ùn vede micca u capu, ma vede ancu Zookeeper

Risu. 22. Scenariu 1: ISR di trè rèpliche

U fallimentu di cunnessione separa u broker 3 da i brokers 1 è 2, ma micca da Zookeeper. Broker 3 ùn pò più mandà richieste di ricuperazione. Dopu chì u tempu hè passatu replica.lag.time.max.ms hè sguassatu da l'ISR è ùn participa micca à l'impegni di missaghju. Una volta chì a connettività hè restaurata, ripiglià e richieste di ricuperazione è unisce à l'ISR quandu si mette à u capu. Zookeeper continuarà à riceve pings è assume chì u broker hè vivu è bè.

Risu. 23. Scenariu 1: U broker hè sguassatu da l'ISR s'ellu ùn hè micca ricevutu una dumanda di ricuperazione in l'intervallu replica.lag.time.max.ms.

Ùn ci hè nè split-brain o sospensione node cum'è in RabbitMQ. Invece, a redundanza hè ridutta.

Scenariu 2: Leader ùn vede micca seguitori, ma vede ancu Zookeeper

Risu. 24. Scenariu 2. Leader è dui seguitori

Una rottura in a cunnessione di a rete separa u capu da i seguitori, ma u broker pò ancu vede Zookeeper. Cum'è in u primu scenariu, l'ISR si riduce, ma sta volta solu à u capu postu chì tutti i seguitori cessanu di mandà richieste di ricerca. In novu, ùn ci hè micca una divisione logica. Invece, ci hè una perdita di redundanza per i missaghji novi finu à chì a cunnessione hè restaurata. Zookeeper cuntinueghja à riceve pings è crede chì u broker hè vivu è bè.

Risu. 25. Scenariu 2. L'ISR s'hè ristrettu solu à u capu

Scenariu 3. Follower vede u capu, ma ùn vede u Zookeeper

U seguitore hè siparatu da Zookeeper, ma micca da u broker cù u capu. In u risultatu, u seguitore cuntinueghja à fà e dumande è esse un membru di l'ISR. Zookeeper ùn riceve più ping è registra un crash di broker, ma postu chì hè solu un seguitore, ùn ci hè micca cunsequenze dopu a ricuperazione.

Risu. 26. Scenariu 3: U seguitore cuntinueghja à mandà richieste di piglià à u capu

Scenariu 4. Leader vede seguitori, ma ùn vede Zookeeper

Risu. 27. Scenariu 4. Leader è dui seguitori

U capu hè separatu da Zookeeper, ma micca da i brokers cù seguitori.

Risu. 28. Scenariu 4: Leader isolatu da Zookeeper

Dopu qualchì tempu, Zookeeper hà da registrà un fallimentu di u broker è avvisà u controller nantu à questu. Ellu sceglie un novu capu trà i so seguitori. Tuttavia, u capu uriginale hà da cuntinuà à pensà chì hè u capu è cuntinuà à accettà entrate da acci = 1. I seguitori ùn li mandanu più richieste di caccià, cusì li cunsidererà morti è pruvà à riduce l'ISR à sè stessu. Ma postu chì ùn hà micca una cunnessione cù Zookeeper, ùn puderà micca fà questu, è à quellu puntu ricuserà di accettà più entrate.

Messaggi acks = tutti ùn riceverà micca un ricunniscenza perchè l'ISR accende prima tutte e rèpliche, è i missaghji ùn li ghjunghjenu micca. Quandu u capu uriginale prova di caccià da l'ISR, ùn serà micca pussibule di fà cusì è cesserà di accettà ogni messagiu.

I clienti prestu notanu u cambiamentu di capu è cumincianu à mandà registri à u novu servitore. Una volta a reta hè restaurata, u capimachja uriginale vede chì ùn hè più un capu è truncates u so logu à u valore HW chì u novu capu avia à u mumentu di fallimentu per evitari divergenza di log. Dopu cumminciarà à mandà richieste di ricuperazione à u novu capu. Tutti i registri di u capu originale chì ùn sò micca replicati à u novu capu sò persi. Vale à dì, i missaghji chì ùn eranu micca ricunnisciuti da u capu originale in quelli pochi sicondi quandu dui dirigenti travagliavanu seranu persi.

Risu. 29. Scenariu 4. U capu nantu à u broker 1 diventa un seguitore dopu chì a reta hè restaurata

Scenariu 5: U seguitore hè completamente separatu da l'altri nodi Kafka è Zookeeper

U seguitore hè cumpletamente isolatu da i dui altri nodi Kafka è Zookeeper. Simply si sguassate da l'ISR finu à chì a reta hè restaurata, è poi chjappà cù l'altri.

Risu. 30. Scenariu 5: U seguitu isolatu hè eliminatu da ISR

Scenariu 6: U capu hè completamente separatu da l'altri nodi Kafka è Zookeeper

Risu. 31. Scenariu 6. Leader è dui seguitori

U capu hè cumplettamente isolatu da i so seguitori, u cuntrollu è u Zookeeper. Per un cortu periodu continuerà à accettà entrate da acci = 1.

Risu. 32. Scenariu 6: Isulà u capu da altri nodi Kafka è Zookeeper

Ùn avè micca ricevutu richieste dopu a scadenza replica.lag.time.max.ms, Pruvarà di sminuisce l'ISR à sè stessu, ma ùn serà micca capaci di fà perchè ùn ci hè micca cumunicazione cù Zookeeper, allora cesserà di accettà i scritti.

Intantu, Zookeeper marcarà u broker isolatu cum'è mortu è u cuntrollu elegerà un novu capu.

Risu. 33. Scenariu 6. Dui capi

U capu uriginale pò accettà entrate per uni pochi di seconde, ma poi cessà di accettà ogni messagiu. I clienti sò aghjurnati ogni 60 seconde cù l'ultimi metadati. Seranu infurmati di u cambiamentu di capu è cumincianu à mandà entrate à u novu capu.

Risu. 34. Scenariu 6: I pruduttori cambianu à un novu capu

Tutte e entrate cunfirmate fatte da u capu originale postu chì a perdita di cunnessione serà persa. Una volta chì a reta hè restaurata, u capu originale scoprerà attraversu Zookeeper chì ùn hè più u capu. Allora truncarà u so logu à u HW di u novu capu à u mumentu di l'elezzione è cumincià à mandà richieste cum'è seguitore.

Risu. 35. Scenariu 6: U capu originale diventa un seguitore dopu chì a cunnessione di a rete hè restaurata

In questa situazione, a separazione logica pò accade per un cortu periodu, ma solu s'ellu acci = 1 и min.insync.replicas ancu 1. A separazione logica finisce automaticamente sia dopu chì a reta hè restaurata, quandu u capu originale si rende cunzignatu chì ùn hè più u capu, o quandu tutti i clienti capiscenu chì u capu hà cambiatu è cumincianu à scrive à u novu capu - quellu chì succede prima. In ogni casu, qualchi missaghji sarà persu, ma solu cù acci = 1.

Ci hè una altra variante di stu scenariu induve, ghjustu prima di a split network, i seguitori sò cascati in daretu è u capu cumpressa l'ISR à ellu stessu. Allora diventa isolatu per via di a perdita di cunnessione. Un novu capu hè elettu, ma u capu originale cuntinueghja à accettà entrate, ancu acks = tutti, perchè ùn ci hè nimu in ISR fora di ellu. Questi registri seranu persi una volta chì a reta hè restaurata. L'unicu modu per evità sta opzione hè min.insync.replicas = 2.

Scenariu 7: Kafka Controller Node ùn pò micca vede un altru Kafka Node

In generale, una volta chì a cunnessione cù un node Kafka hè persa, u controller ùn serà micca capaci di trasmette alcuna infurmazione di cambiamentu di capu à questu. In u peghju casu, questu portarà à una separazione logica di corta durazione, cum'è in u scenariu 6. Più spessu, u broker ùn diventerà micca solu un candidatu per a dirigenza se l'ultimu falla.

Scenariu 8: U controller Kafka ùn vede micca Zookeeper

Zookeeper ùn riceve micca un ping da u controller cadutu è selezziunate un novu node Kafka cum'è u controller. U controller uriginale pò cuntinuà à presentà cum'è tali, ma ùn riceve micca notificazioni da Zookeeper, cusì ùn avarà micca compiti da fà. Una volta chì a reta hè restaurata, si capisce chì ùn hè più un controller, ma hè diventatu un node Kafka regularmente.

Conclusioni da i scenarii

Avemu vistu chì a perdita di cunnessione di seguitori ùn hà micca risultatu in a perdita di missaghju, ma solu riduce temporaneamente a redundanza finu à chì a reta hè restaurata. Stu, sicuru, pò purtà à a perdita di dati si unu o più nodi sò persu.

Se u capu diventa separatu da Zookeeper per via di una perdita di cunnessione, questu puderia risultatu in i missaghji persu da acci = 1. A mancanza di cumunicazione cù Zookeeper provoca una brevi divisione logica cù i dui capi. Stu prublema hè risolta da u paràmetru acks = tutti.

Parameter min.insync.replicas in dui o più répliche furnisce una assicurazione supplementaria chì tali scenarii à cortu termine ùn anu micca risultatu in messagi persi cum'è in u Scenariu 6.

Riassuntu di Missaghji Persi

Elenchemu tutti i modi per perde dati in Kafka:

• Ogni fallimentu di capu se i missaghji sò stati cunfirmati cù l'usu acci = 1
• Ogni transizione impura di dirigenza, vale à dì à un seguitore fora di l'ISR, ancu cù acks = tutti
• Isulà u capu da Zookeeper se i missaghji sò stati cunfirmati cù l'usu acci = 1
• L'isolamentu cumpletu di u capu chì hà digià ridutta u gruppu ISR finu à ellu stessu. Tutti i missaghji seranu persi, ancu acks = tutti. Questu hè veru solu se min.insync.replicas=1.
• Falli simultanei di tutti i nodi di partizioni. Perchè i missaghji sò ricunnisciuti da a memoria, alcuni ùn anu ancu esse scrittu à u discu. Dopu à rebooting i servitori, certi missaghji pò esse mancanti.

E transizioni di dirigenza impure ponu esse evitate sia pruibendu o assicurendu almenu dui licenzii. A cunfigurazione più durable hè una cumminazione acks = tutti и min.insync.replicas più di 1.

Comparazione diretta di l'affidabilità di RabbitMQ è Kafka

Per assicurà affidabilità è alta dispunibilità, e duie piattaforme implementanu un sistema di replicazione primariu è secundariu. Tuttavia, RabbitMQ hà un tallone d'Achille. Quandu si ricolleganu dopu un fallimentu, i nodi scartanu i so dati è a sincronizazione hè bluccata. Stu doppiu puzzicheghju mette in quistione a longevità di grandi file in RabbitMQ. Avete da accettà o riduzzione di riduzzione o tempi di bloccu longu. Reducing redundancy aumenta u risicu di perdita di dati massiccia. Ma s'è e fila sò chjuchi, allora, per u ragiunamentu di a redundanza, i brevi periodi di indisponibilità (pochi seconde) ponu esse trattati cù tentativi ripetuti di cunnessione.

Kafka ùn hà micca stu prublema. Discards data solu da u puntu di divergenza trà u capu è u seguitore. Tutti i dati spartuti sò salvati. Inoltre, a replicazione ùn impedisce micca u sistema. U capu cuntinueghja à accettà i posti mentre u novu seguitore prende, cusì per i devops, unisce o riunisce à u cluster diventa un compitu triviale. Di sicuru, ci sò sempre prublemi cum'è a larghezza di banda di a rete durante a replicazione. Se aghjunghje parechje seguitori à u stessu tempu, pudete truvà un limitu di larghezza di banda.

RabbitMQ hè superiore à Kafka in affidabilità quandu parechji servitori in un cluster fallenu à u stessu tempu. Comu avemu digià dettu, RabbitMQ manda una cunferma à l'editore solu dopu chì u messagiu hè scrittu à u discu da u maestru è tutti i specchi. Ma questu aghjunghje una latenza supplementaria per dui motivi:

• fsync ogni pochi centu millisecondi
• U fallimentu di u specchiu pò esse nutatu solu dopu a vita di i pacchetti chì verificanu a dispunibilità di ogni node (tick net) hè scadutu. Se u specchiu rallenta o cascà, questu aghjunghje un ritardu.

A scumessa di Kafka hè chì, se un missaghju hè almacenatu in parechji nodi, pò ricunnosce i missaghji appena si tocca à a memoria. Per via di questu, ci hè un risicu di perda missaghji di ogni tipu (ancu acks = tutti, min.insync.replicas=2) in casu di fallimentu simultanea.

In generale, Kafka mostra un megliu rendimentu di u software è hè pensatu da a terra per i clusters. U numaru di seguitori pò esse aumentatu à 11 se ne necessariu per affidabilità. Fattore di replicazione 5 è numeru minimu di rèpliche in sincronizazione min.insync.replicas=3 farà a perdita di missaghju un avvenimentu assai raru. Se a vostra infrastruttura pò sustene stu rapportu di replicazione è u livellu di redundanza, pudete sceglie sta opzione.

U clustering RabbitMQ hè bonu per e petite file. Ma ancu e petite fila ponu cresce rapidamente quandu ci hè un trafficu pesante. Una volta chì e file diventanu grandi, duverete fà scelte difficili trà dispunibilità è affidabilità. U clustering RabbitMQ hè più adattatu per situazioni non tipiche induve i benefici di a flessibilità di RabbitMQ superano qualsiasi svantaghju di u so clustering.

Un antidotu à a vulnerabilità di RabbitMQ à e grandi file hè di sparghje in parechje file più chjuche. Se ùn avete micca bisognu di l'ordine cumpletu di tutta a fila, ma solu i missaghji pertinenti (per esempiu, i missaghji da un cliente specificu), o ùn avete micca urdinatu nunda, allora sta opzione hè accettata: fighjate u mo prughjettu. Rebalancer per sparte a fila (u prughjettu hè sempre in una prima fase).

Infine, ùn vi scurdate di una quantità di bug in i miccanismi di clustering è replicazione di RabbitMQ è Kafka. À u tempu, i sistemi sò diventati più maturu è stabile, ma nisun missaghju serà mai 100% sicuru da a perdita! Inoltre, l'accidenti à grande scala sò in i centri di dati!

Sì mi mancava qualcosa, aghju fattu un sbagliu, o ùn site micca d'accordu cù qualcunu di i punti, sentite liberu di scrive un cumentu o cuntattatemi.

Sò spessu dumandatu: "Chì sceglite, Kafka o RabbitMQ?", "Quale piattaforma hè megliu?". A verità hè chì dipende veramente da a vostra situazione, l'experientia attuale, etc. Sò esitatu à dà a mo opinione perchè saria troppu simplificatu per ricumandà una piattaforma per tutti i casi d'usu è e pussibuli limitazioni. Aghju scrittu sta serie di articuli per chì pudete fà a vostra propria opinione.

Vogliu dì chì i dui sistemi sò capi in questa zona. Puderaghju esse un pocu preghjudiziu perchè da a mo spirienza cù i prughjetti tendenu à valurizà e cose cum'è l'ordine di messagiu garantitu è ​​l'affidabilità.

Veju altre tecnulugii chì ùn mancanu di sta affidabilità è l'urdinamentu garantitu, allora fighjulà RabbitMQ è Kafka è capisce u valore incredibile di questi dui sistemi.

Source: www.habr.com