В lêste artikel wy seagen op RabbitMQ-klustering foar skuldtolerânsje en hege beskikberens. Litte wy no djip yn Apache Kafka grave.

Hjir is de ienheid fan replikaasje de partysje. Elk ûnderwerp hat ien of mear seksjes. Elke seksje hat in lieder mei of sûnder folgers. By it meitsjen fan in ûnderwerp spesifisearje jo it oantal partysjes en de replikaasjekoëffisjint. De gewoane wearde is 3, wat trije replika's betsjut: ien lieder en twa folgers.

Rys. 1. Fjouwer seksjes wurde ferdield ûnder trije makelders

Alle lês- en skriuwfersiken geane nei de lieder. Folgers stjoere periodyk fersiken nei de lieder om de lêste berjochten te ûntfangen. Konsuminten draaie noait nei folgers; de lêste besteane allinich foar oerstalligens en skuldtolerânsje.

Partition failure

As in brokker mislearret, mislearje de lieders fan ferskate seksjes faak. Yn elk fan harren wurdt in folger fan in oare knooppunt de lieder. Yn feite is dat net altyd it gefal, om't de syngronisaasjefaktor ek beynfloedet: oft der syngronisearre folgers binne, en sa net, dan oft oerstappe nei in net-syngronisearre replika tastien is. Mar litte wy de dingen no net komplisearje.

Broker 3 ferlit it netwurk, en in nije lieder wurdt keazen foar seksje 2 by broker 2.

Rys. 2. Broker 3 stjert en syn follower op broker 2 wurdt keazen as de nije lieder fan dieling 2

Dan ferlit makelder 1 en seksje 1 ferliest ek syn lieder, waans rol oergiet nei makelder 2.

Rys. 3. Der is ien makelder oer. Alle lieders binne op ien broker mei nul oerstalligens

As broker 1 werom komt online, foeget it fjouwer folgers ta, wat oerstallich is foar elke partysje. Mar alle lieders bleaunen noch op broker 2.

Rys. 4. Lieders bliuwe op makelder 2

As broker 3 opkomt, binne wy ​​werom nei trije replika's per partysje. Mar alle lieders binne noch op broker 2.

Rys. 5. Unbalansearre pleatsing fan lieders nei de restauraasje fan brokers 1 en 3

Kafka hat in ark foar bettere lieder rebalancing dan RabbitMQ. Dêr moasten jo in plugin of skript fan tredden brûke dy't it belied foar it migrearjen fan de masterknoop feroare troch redundânsje te ferminderjen tidens migraasje. Derneist moasten wy foar grutte wachtrigen unbeskikberens akseptearje by syngronisaasje.

Kafka hat it konsept fan "foarkar replika's" foar de liederrol. As ûnderwerppartysjes oanmakke wurde, besiket Kafka lieders gelyk te fersprieden oer knopen en markearret dy earste lieders as foarkar. Yn 'e rin fan' e tiid kinne lieders op oare knooppunten einigje, as gefolch fan herstarten fan tsjinners, flaters en ferbiningsproblemen, lykas yn it hjirboppe beskreaune ekstreme gefal.

Om dit te reparearjen biedt Kafka twa opsjes:

• Opsje auto.leader.rebalance.enable=wier lit de kontrôlerknooppunt lieders automatysk weromjaan nei foarkarreplika's en dêrmei unifoarme ferdieling weromsette.
• De behearder kin it skript útfiere kafka-preferred-replica-election.sh foar hânmjittich reassignment.

Rys. 6. Replicas nei rebalancing

Dit wie in ferienfâldige ferzje fan it mislearjen, mar de realiteit is komplekser, hoewol d'r hjir neat te yngewikkeld is. It komt allegear del op syngronisearre replika's (In-Sync Replicas, ISR).

Syngronisearre replika's (ISR)

In ISR is in set replika's fan in partysje dy't wurdt beskôge as "syngronisearre" (yn-syngronisearre). D'r is in lieder, mar d'r binne miskien gjin folgers. In folger wurdt as syngronisearre beskôge as it krekte kopyen makke hat fan alle berjochten fan de lieder foardat it ynterval ferrint replica.lag.time.max.ms.

In follower wurdt fuortsmiten fan 'e ISR-set as it:

• hat gjin fersyk dien om te selektearjen foar it ynterval replica.lag.time.max.ms (fermoedlik dea)
• koe net bywurkje tidens it ynterval replica.lag.time.max.ms (beskôge stadich)

Folgers meitsje samplingoanfragen yn it ynterval replica.fetch.wait.max.ms, dy't standert is op 500ms.

Om dúdlik te ferklearjen it doel fan ISR, wy moatte sjen nei befêstigings fan de produsint en guon mislearre senario. Produsinten kinne kieze wannear't de makelder befêstiging stjoert:

• acks=0, befêstiging wurdt net ferstjoerd
• acks=1, befêstiging wurdt ferstjoerd neidat de lieder in berjocht skreaun hat yn syn lokale log
• acks=alles, befêstiging wurdt ferstjoerd neidat alle replika's yn 'e ISR it berjocht skreaun hawwe nei de lokale logs

Yn Kafka-terminology, as de ISR in berjocht hat bewarre, is it "ynset". Acks=alles is de feilichste opsje, mar foeget ek ekstra fertraging ta. Litte wy nei twa foarbylden fan mislearring sjen en hoe't de ferskillende 'acks'-opsjes ynteraksje mei it ISR-konsept.

Acks=1 en ISR

Yn dit foarbyld sille wy sjen dat as de lieder net wachtet op elk berjocht fan alle folgers om te bewarjen, dan is gegevensferlies mooglik as de lieder mislearret. Navigearje nei in net syngronisearre folger kin yn- of útskeakele wurde troch ynstelling unclean.leader.election.enable.

Yn dit foarbyld hat de fabrikant de wearde acks=1. De seksje is ferdield oer alle trije makelders. Broker 3 is efter, it syngronisearre mei de lieder acht sekonden lyn en is no 7456 berjochten efter. Broker 1 wie mar ien sekonde efter. Us produsint stjoert in berjocht en krijt fluch in ack werom, sûnder de overhead fan stadige of deade folgers dêr't de lieder net op wachtet.

Rys. 7. ISR mei trije replika's

Broker 2 mislearret en de produsint ûntfangt in ferbiningsflater. Neidat liederskip trochgiet nei makelder 1, ferlieze wy 123 berjochten. De follower op broker 1 wie diel fan 'e ISR, mar wie net folslein syngronisearre mei de lieder doe't it foel.

Rys. 8. Berjochten binne ferlern as it crasht

Yn konfiguraasje bootstrap.servers De fabrikant hat ferskate makelders neamd en kin in oare makelder freegje wa't de nije seksjelieder is. It makket dan in ferbining mei broker 1 en bliuwt berjochten ferstjoere.

Rys. 9. It ferstjoeren fan berjochten giet werom nei in koarte pauze

Broker 3 is noch fierder efter. It makket opheljen oanfragen mar kin net syngronisearje. Dit kin wêze fanwege trage netwurk ferbining tusken makelders, opslach issue, ensfh It wurdt fuorthelle út de ISR. No bestiet de ISR út ien replika - de lieder! De fabrikant bliuwt berjochten ferstjoere en befêstigings ûntfange.

Rys. 10. Folger op makelder 3 wurdt fuorthelle út de ISR

Broker 1 giet omleech en de liedersrol giet nei broker 3 mei it ferlies fan 15286 berjochten! De fabrikant krijt in ferbining flater berjocht. De oergong nei in lieder bûten de ISR wie allinnich mooglik troch de setting unclean.leader.election.enable=wier. As it is ynstallearre yn falsk, dan soe de oergong net foarkomme en alle lês- en skriuwfersiken wurde ôfwiisd. Yn dit gefal wachtsje wy op brokker 1 om werom te kommen mei syn yntakte gegevens yn 'e replika, dy't opnij liederskip sil oernimme.

Rys. 11. Broker 1 falt. As in mislearring optreedt, giet in grut oantal berjochten ferlern

De produsint stelt in ferbining mei de lêste makelder en sjocht dat hy no de lieder is fan 'e seksje. Hy begjint berjochten te ferstjoeren nei broker 3.

Rys. 12. Nei in koarte pauze wurde berjochten wer ferstjoerd nei seksje 0

Wy seagen dat, útsein koarte ûnderbrekkings om nije ferbiningen te meitsjen en in nije lieder te sykjen, de fabrikant konstant berjochten stjoerde. Dizze konfiguraasje soarget foar beskikberens ten koste fan konsistinsje (gegevensfeiligens). Kafka ferlear tûzenen berjochten, mar bleau nije skriften akseptearje.

Acks=alles en ISR

Lit ús werhelje dit senario nochris, mar mei acks = allegear. Broker 3 hat in gemiddelde latency fan fjouwer sekonden. De fabrikant stjoert in berjocht mei acks = allegear, en no krijt gjin fluch antwurd. De lieder wachtet op it berjocht dat troch alle replika's yn 'e ISR bewarre wurdt.

Rys. 13. ISR mei trije replika's. Ien is stadich, wat resulteart yn opnamefertragingen

Nei fjouwer sekonden fan ekstra fertraging stjoert broker 2 in ack. Alle replika's binne no folslein bywurke.

Rys. 14. Alle replika's bewarje berjochten en stjoer ack

Broker 3 falt no fierder efter en wurdt fuorthelle út de ISR. Wachttiid wurdt signifikant fermindere, om't d'r gjin trage replika's binne oerbleaun yn 'e ISR. Broker 2 wachtet no allinich op broker 1, en hy hat in gemiddelde efterstân fan 500 ms.

Rys. 15. De replika op makelder 3 wurdt fuorthelle út de ISR

Dan falt broker 2 en liederskip giet oer nei broker 1 sûnder ferlies fan berjochten.

Rys. 16. Broker 2 falt

De fabrikant fynt in nije lieder en begjint berjochten nei him te stjoeren. De latency wurdt fierder fermindere omdat de ISR no bestiet út ien replika! Dêrom de opsje acks = allegear foeget gjin oerstallichheid ta.

Rys. 17. Replika op makelder 1 nimt de lieding sûnder berjochten te ferliezen

Dan crasht broker 1 en giet de lieding nei broker 3 mei in ferlies fan 14238 berjochten!

Rys. 18. Broker 1 stjert en liederskip oergong mei ûnreine ynstelling resultearret yn wiidweidich gegevens ferlies

Wy koene de opsje net ynstallearje unclean.leader.election.enable yn betsjutting wier. Standert is it gelyk oan falsk. Ynstellings acks = allegear с unclean.leader.election.enable=wier jout tagonklikens mei wat tafoege gegevensfeiligens. Mar sa't jo sjen kinne, kinne wy ​​noch berjochten ferlieze.

Mar wat as wy gegevensfeiligens wolle ferheegje? Jo kinne sette unclean.leader.election.enable = falsk, mar dit sil ús net needsaaklik beskermje tsjin gegevensferlies. As de lieder hurd foel en de gegevens meinaam, dan binne berjochten noch ferlern, plus beskikberens is ferlern oant de behearder de situaasje herstelt.

It is better om te soargjen dat alle berjochten oerstallich binne, en oars de opname fersmite. Dan, op syn minst út it eachpunt fan de makelder, gegevens ferlies is allinnich mooglik yn it gefal fan twa of mear simultane mislearrings.

Acks=alles, min.insync.replicas en ISR

Mei ûnderwerp konfiguraasje min.insync.replicas Wy ferheegje it nivo fan gegevensfeiligens. Lit ús gean troch it lêste diel fan it foarige senario nochris, mar dizze kear mei min.insync.replicas=2.

Dus broker 2 hat in replika-lieder en de follower op broker 3 wurdt fuortsmiten fan 'e ISR.

Rys. 19. ISR út twa replika's

Broker 2 falt en liederskip giet oer nei broker 1 sûnder ferlies fan berjochten. Mar no bestiet de ISR út mar ien replika. Dit foldocht net oan it minimale oantal om records te ûntfangen, en dêrom reagearret de makelder op 'e skriuwpoging mei in flater NotEnoughReplicas.

Rys. 20. It oantal ISRs is ien leger as oantsjutte yn min.insync.replicas

Dizze konfiguraasje offeret beskikberens op foar konsistinsje. Foardat wy in berjocht erkennen, soargje wy derfoar dat it skreaun is nei op syn minst twa replika's. Dit jout de fabrikant folle mear fertrouwen. Hjir is berjochtferlies allinich mooglik as twa replika's tagelyk mislearje yn in koart ynterval oant it berjocht wurdt replikearre nei in ekstra folger, wat net wierskynlik is. Mar as jo super paranoïde binne, kinne jo de replikaasjefaktor ynstelle op 5, en min.insync.replicas troch 3. Hjir moatte trije makelders falle tagelyk te ferliezen it rekôr! Fansels betelje jo foar dizze betrouberens yn ekstra latency.

As tagonklikens nedich is foar gegevensfeiligens

Lykas gefal mei RabbitMQ, soms is tagonklikens nedich foar gegevensfeiligens. Hjir is wat jo moatte tinke oer:

• Kin 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 it antwurd nee is, ferbetteret it optimalisearjen fan beskikberens gegevensfeiligens. Jo sille minder gegevens ferlieze as jo beskikberens kieze ynstee fan net opnimme. Sa komt it allegear del op it finen fan in lykwicht, en it beslút hinget ôf fan 'e spesifike situaasje.

De betsjutting fan ISR

De ISR-suite lit jo it optimale lykwicht kieze tusken gegevensfeiligens en latency. Soargje bygelyks foar beskikberens yn gefal fan mislearring fan 'e mearderheid fan replika's, minimalisearje de ynfloed fan deade of trage replika's yn termen fan latency.

Wy kieze de betsjutting sels replica.lag.time.max.ms neffens jo behoeften. Yn wêzen betsjut dizze parameter hoefolle fertraging wy binne ree om te akseptearjen wannear acks = allegear. De standertwearde is tsien sekonden. As dit te lang foar jo is, kinne jo it ferminderje. Dan sil de frekwinsje fan feroaringen yn 'e ISR tanimme, om't folgers faker wurde fuortsmiten en tafoege.

RabbitMQ is gewoan in set spegels dy't moatte wurde replikearre. Stadige spegels yntrodusearje ekstra latency, en deade spegels kinne wachtsje oant de pakketten dy't de beskikberens fan elke knooppunt kontrolearje (net tick) om te reagearjen. ISR is in nijsgjirrige manier om dizze latencyproblemen te foarkommen. Mar wy riskearje oerstalligens te ferliezen, om't de ISR allinich kin krimpe nei de lieder. Om dit risiko te foarkommen, brûk de ynstelling min.insync.replicas.

Client ferbining garânsje

Yn ynstellings bootstrap.servers produsint en konsumint kinne meardere makelders oantsjutte foar it ferbinen fan kliïnten. It idee is dat as ien knooppunt nei ûnderen giet, d'r ferskate reserves binne oerbleaun wêrmei't de kliïnt in ferbining iepenje kin. Dit binne net needsaaklikerwize seksjelieders, mar gewoan in springplanke foar it earste laden. De kliïnt kin har freegje hokker knooppunt de lês- / skriuwpartijlieder host.

Yn RabbitMQ kinne kliïnten ferbine mei elke knooppunt, en ynterne routing stjoert it fersyk nei wêr't it moat. Dit betsjut dat jo in load balancer kinne ynstallearje foar RabbitMQ. Kafka fereasket dat kliïnten ferbine mei de knooppunt dy't de korrespondearjende partysjelieder host. Yn sa'n situaasje kinne jo gjin load balancer ynstallearje. List bootstrap.servers It is kritysk dat kliïnten tagong krije ta en fine de juste knopen nei in mislearring.

Kafka Consensus Architecture

Oant no hawwe wy net beskôge hoe't it kluster leart oer de fal fan 'e makelder en hoe't in nije lieder keazen wurdt. Om te begripen hoe't Kafka wurket mei netwurkpartysjes, moatte jo earst de konsensus-arsjitektuer begripe.

Elts Kafka kluster wurdt ynset tegearre mei in Zookeeper kluster, dat is in ferspraat konsensus tsjinst wêrmei it systeem te berikken konsensus op guon opjûne steat, prioriteit gearhing boppe beskikberens. De tastimming fan in mearderheid fan Zookeeper-knooppunten is nedich om lês- en skriuwoperaasjes goed te keuren.

Zookeeper bewarret de steat fan it kluster:

• List fan ûnderwerpen, seksjes, konfiguraasje, replika's fan hjoeddeistige lieder, replika's foarkar.
• Cluster leden. Elke makelder pingt it Zookeeper-kluster. As it gjin ping ûntfangt binnen in bepaalde perioade, dan registreart Zookeeper de makelder as net beskikber.
• Selektearje de haad- en reserveknooppunten foar de controller.

De kontrôlerknooppunt is ien fan 'e Kafka-makelaars dy't ferantwurdlik is foar it kiezen fan replika-lieders. Zookeeper stjoert notifikaasjes nei de kontrôler oer klusterlidmaatskip en ûnderwerpwizigingen, en de kontrôler moat hannelje op dizze feroarings.

Litte wy bygelyks in nij ûnderwerp nimme mei tsien partysjes en in replikaasjefaktor fan 3. De kontrôler moat in lieder kieze foar elke partysje, besykje de lieders optimaal te fersprieden ûnder de makelders.

Foar elke seksjekontrôler:

• updates ynformaasje yn Zookeeper oer ISR en lieder;
• Stjoert in LeaderAndISRCommand nei elke makelder dy't in replika fan dizze partition host, en ynformearret de makelders oer de ISR en de lieder.

As in makelder mei in lieder falt, stjoert Zookeeper in notifikaasje nei de controller, en it kiest in nije lieder. Nochris bywurket de kontrôler Zookeeper earst by en stjoert dan in kommando nei elke makelder dy't har ynformearret oer de feroaring fan liederskip.

Elke lieder is ferantwurdlik foar it werven fan ISR's. Ynstellings replica.lag.time.max.ms bepaalt wa't dêr yngean sil. As de ISR feroaret, stjoert de lieder nije ynformaasje nei Zookeeper.

Zookeeper wurdt altyd op 'e hichte brocht fan alle feroarings, sadat it management by in mislearring soepel oergiet nei in nije lieder.

Rys. 21. Kafka Konsensus

Replikaasje protokol

Troch de details fan replikaasje te begripen helpt jo potinsjele senario's foar gegevensferlies better te begripen.

Samplingfragen, Log End Offset (LEO) en Highwater Mark (HW)

Wy beskôgen dat folgers periodyk opheljen oanfragen stjoere nei de lieder. It standert ynterval is 500ms. Dit ferskilt fan RabbitMQ yn dat yn RabbitMQ replikaasje net inisjearre wurdt troch de wachtrige spegel, mar troch de master. De master triuwt feroaringen oan 'e spegels.

De lieder en alle folgers bewarje de Log End Offset (LEO) en it Highwater (HW) label. De LEO-mark bewarret de offset fan it lêste berjocht yn 'e lokale replika, en de HW hâldt de offset fan' e lêste commit. Unthâld dat foar commit status, it berjocht moat wurde oanhâlden oer alle ISR replika's. Dit betsjut dat LEO meastentiids wat foarút is op HW.

As de lieder in berjocht ûntfangt, bewarret it it lokaal. De folger docht in opheljenfersyk troch syn LEO oer te stjoeren. De lieder stjoert dan in partij berjochten út dizze LEO en stjoert ek de hjoeddeistige HW oer. As de lieder ûntfangt ynformaasje dat alle replika's it berjocht hawwe opslein by de opjûne offset, ferpleatst it HW-mark. Allinich de lieder kin de HW ferpleatse, en dus sille alle folgers de hjoeddeistige wearde witte yn 'e antwurden op har fersyk. Dit betsjut dat folgers efter de lieder kinne bliuwe yn sawol berjocht as HW-kennis. Konsuminten krije allinich berjochten oant de hjoeddeistige HW.

Tink derom dat "oanhâlde" betsjut skreaun nei it ûnthâld, net op skiif. Foar prestaasjes syngronisearret Kafka nei skiif op in spesifyk ynterval. RabbitMQ hat ek sa'n ynterval, mar it sil pas in erkenning nei de útjouwer stjoere nei't de master en alle spegels it berjocht op skiif skreaun hawwe. De Kafka-ûntwikkelders besleaten om prestaasjesredenen in ack te stjoeren sa gau as it berjocht yn it ûnthâld skreaun is. Kafka weddet dat oerstalligens it risiko fan it koart opslaan fan erkende berjochten allinich yn it ûnthâld opheft.

Leader falen

As in lieder falt, meldt Zookeeper de kontrôler, en it selekteart in nije liederreplika. De nije lieder set in nij HW-mark neffens syn LEO. Folgers krije dan ynformaasje oer de nije lieder. Ofhinklik fan 'e ferzje fan Kafka sil de folger ien fan twa senario's kieze:

1. It sil it lokale log ôfbrekke nei in bekende HW en stjoere in fersyk nei de nije lieder foar berjochten nei dit mark.
2. Sil stjoere in fersyk oan de lieder te finen út de HW op it stuit dat hy waard keazen lieder, en dan truncate it log nei dizze offset. It sil dan begjinne mei it meitsjen fan periodike opheljen oanfragen begjinnend by dizze offset.

In folger moat it log miskien ôfbrekke om de folgjende redenen:

• As in lieder mislearret, wint de earste folger yn 'e ISR-set registrearre by Zookeeper de ferkiezing en wurdt de lieder. Alle folgers op ISR, hoewol as "yn syngronisaasje" beskôge, hawwe miskien gjin kopyen krigen fan alle berjochten fan 'e eardere lieder. It is folslein mooglik dat de featured folger net de meast aktuele kopy hat. Kafka soarget derfoar dat der gjin diverginsje is tusken replika's. Sa, om diskrepânsjes te foarkommen, moat elke follower syn log ôfbrekke nei de HW-wearde fan 'e nije lieder op' e tiid fan syn ferkiezing. Dit is in oare reden wêrom ynstelling acks = allegear sa wichtich foar konsistinsje.
• Berjochten wurde periodyk skreaun op skiif. As alle klusterknooppunten tagelyk mislearje, dan wurde replika's mei ferskate offsets op 'e skiven opslein. It is mooglik dat as makelders online weromkomme, de nije lieder dy't keazen wurdt efter syn folgelingen wêze sil, om't hy foar de oaren op skiif bewarre waard.

Reuny mei it kluster

By it wer oanslute by it kluster dogge de replika's itselde as wannear't in lieder mislearret: se kontrolearje de replika fan 'e lieder en truncate har log nei har HW (op it momint fan ferkiezing). Yn ferliking, RabbitMQ behannelet wer ferienige knopen likegoed as folslein nij. Yn beide gefallen smyt de brokker elke besteande steat ôf. As automatyske syngronisaasje wurdt brûkt, dan moat de master absolút alle aktuele ynhâld nei de nije spegel replikearje yn in metoade "lit de hiele wrâld wachtsje". De master akseptearret gjin lês- of skriuwoperaasjes tidens dizze operaasje. Dizze oanpak soarget foar problemen yn grutte wachtrigen.

Kafka is in ferspraat log, en yn it algemien bewarret it mear berjochten as in RabbitMQ-wachtrige, wêrby't gegevens út 'e wachtrige fuortsmiten wurde nei't it lêzen is. Aktive wachtrigen moatte relatyf lyts bliuwe. Mar Kafka is in log mei in eigen retinsjebelied, dat in perioade fan dagen as wiken ynstelle kin. De wachtrige blocking en folsleine syngronisaasje oanpak is perfoarst net akseptabel foar in ferspraat log. Ynstee, Kafka followers gewoan truncate harren log nei de lieder syn HW (op it stuit fan syn ferkiezing) as harren kopy is foarsprong op de lieder. Yn it wierskynliker gefal, as de folger efter is, begjint it gewoan opheljen oanfragen te meitsjen begjinnend mei syn hjoeddeistige LEO.

Nije of opnij oansletten folgers begjinne bûten de ISR en dogge net mei oan commits. Se wurkje gewoan neist de groep, ûntfange berjochten sa gau as se kinne oant se de lieder ynhelje en de ISR ynfiere. D'r is gjin lock-in en gjin needsaak om al jo gegevens fuort te smiten.

Ferlies fan ferbining

Kafka hat mear komponinten as RabbitMQ, dus it hat in kompleksere set fan gedrach as it kluster loskeppele wurdt. Mar Kafka is oarspronklik ûntworpen foar klusters, dus de oplossingen binne tige goed trochtocht.

Hjirûnder binne ferskate senario's foar ferbiningsfout:

• Senario 1: De folger sjocht de lieder net, mar sjocht dochs de Zookeeper.
• Senario 2: De lieder sjocht gjin folgers, mar sjocht dochs Zookeeper.
• Senario 3: De folger sjocht de lieder, mar sjocht de Zookeeper net.
• Senario 4: De lieder sjocht de folgers, mar sjocht de Zookeeper net.
• Senario 5: De folger is folslein apart fan beide oare Kafka-knooppunten en Zookeeper.
• Senario 6: De lieder is folslein apart fan beide oare Kafka-knooppunten en Zookeeper.
• Senario 7: De Kafka-controllerknooppunt kin gjin oare Kafka-knooppunt sjen.
• Senario 8: Kafka-controller sjocht Zookeeper net.

Elk senario hat syn eigen gedrach.

Senario 1: Folger sjocht de lieder net, mar sjocht dochs Zookeeper

Rys. 22. senario 1: ISR fan trije replika's

De ferbiningsfout skiedt makelder 3 fan makelders 1 en 2, mar net fan Zookeeper. Broker 3 kin net langer ferstjoere fersiken om opheljen. Nei de tiid is foarby replica.lag.time.max.ms it wurdt fuorthelle út de ISR en docht net mei oan berjocht commits. Sadree't de ferbining is hersteld, sil it opheljen oanfragen ferfetsje en meidwaan oan 'e ISR as it de lieder ynhellet. Zookeeper sil trochgean te ûntfangen pings en der fan út dat de makelder libbet en goed.

Rys. 23. Senario 1: De makelder wurdt fuorthelle út de ISR as der gjin opheljen fersyk wurdt ûntfongen fan it binnen it replica.lag.time.max.ms ynterval

D'r is gjin split-brain of knooppunt ophinging lykas yn RabbitMQ. Ynstee wurdt oertaligens fermindere.

Senario 2: Leader sjocht gjin folgers, mar sjocht noch Zookeeper

Rys. 24. senario 2. Lieder en twa followers

In ferdieling yn netwurkferbining skiedt de lieder fan 'e folgers, mar de brokker kin Zookeeper noch sjen. Lykas yn it earste senario krimpt de ISR, mar dizze kear allinich foar de lieder, om't alle folgers stopje mei it ferstjoeren fan fetch-fersiken. Nochris is der gjin logyske ferdieling. Ynstee dêrfan is d'r in ferlies fan oerstalligens foar nije berjochten oant de ferbining is hersteld. Zookeeper bliuwt pings ûntfange en is fan betinken dat de makelder libbet en goed is.

Rys. 25. senario 2. ISR hat krimp allinnich oan de lieder

Senario 3. Folger sjocht de lieder, mar sjocht de Zookeeper net

De folger is skieden fan Zookeeper, mar net fan de makelder mei de lieder. As gefolch, de folger bliuwt te heljen fersiken en wêze lid fan de ISR. Zookeeper krijt gjin pings mear en registrearret in brokercrash, mar om't it allinich in follower is, binne d'r gjin gefolgen nei herstel.

Rys. 26. senario 3: De folger giet fierder te stjoeren fetch fersiken nei de lieder

Senario 4. Leader sjocht folgers, mar sjocht Zookeeper net

Rys. 27. senario 4. Lieder en twa followers

De lieder is skieden fan Zookeeper, mar net fan de makelders mei folgers.

Rys. 28. senario 4: Leader isolearre út Zookeeper

Nei in skoft sil Zookeeper in brokerfal registrearje en de kontrôler der oer ynformearje. Hy sil in nije lieder kieze ûnder syn folgers. Lykwols, de oarspronklike lieder sil bliuwe te tinken dat it is de lieder en sil trochgean te akseptearjen ynstjoerings fan acks=1. Folgers stjoere him net mear fersiken om te heljen, dus hy sil se dea beskôgje en besykje de ISR foar himsels te krimpjen. Mar om't it gjin ferbining hat mei Zookeeper, sil it dit net kinne dwaan, en sil op dat stuit wegerje om fierdere ynstjoeringen te akseptearjen.

berjochten acks = allegear sil gjin erkenning krije om't de ISR earst alle replika's ynskeakelt, en berjochten berikke se net. As de orizjinele lieder besiket se fan 'e ISR te ferwiderjen, sil it dit net kinne en sil it hielendal stopje mei it akseptearjen fan alle berjochten.

Klanten merken gau de feroaring yn lieder en begjinne records te ferstjoeren nei de nije tsjinner. Sadree't it netwurk is restaurearre, de oarspronklike lieder sjocht dat it is net mear in lieder en truncates syn log nei de HW wearde dat de nije lieder hie op it stuit fan mislearjen om log divergence te foarkommen. It sil dan begjinne te ferstjoeren fan opheljen fersiken nei de nije lieder. Alle records fan 'e orizjinele lieder dy't net nei de nije lieder wurde replikearre binne ferlern. Dat is, berjochten dy't net waarden erkend troch de oarspronklike lieder yn dy pear sekonden doe't twa lieders wurken sille ferlern gean.

Rys. 29. Senario 4. De lieder op makelder 1 wurdt in follower neidat it netwurk is restaurearre

Senario 5: De folger is folslein apart fan beide oare Kafka-knooppunten en Zookeeper

De follower is folslein isolearre fan sawol oare Kafka-knooppunten as Zookeeper. Hy ferwideret himsels gewoan fan 'e ISR oant it netwurk is restaurearre, en komt dan de oaren yn.

Rys. 30. senario 5: Isolearre follower wurdt fuorthelle út ISR

Senario 6: De lieder is folslein apart fan beide oare Kafka-knooppunten en Zookeeper

Rys. 31. senario 6. Lieder en twa followers

De lieder is folslein isolearre fan syn folgers, de kontrôler en Zookeeper. Foar in koarte perioade sil trochgean te akseptearjen ynstjoerings fan acks=1.

Rys. 32. senario 6: Isolearje de lieder fan oare Kafka en Zookeeper knopen

Nei't jo gjin oanfragen hawwe ûntfongen nei ferrinnen replica.lag.time.max.ms, it sil besykje de ISR foar himsels te krimpjen, mar sil dat net dwaan kinne om't der gjin kommunikaasje is mei Zookeeper, dan sil it ophâlde mei it akseptearjen fan skriuwt.

Underwilens sil Zookeeper de isolearre makelder as dea markearje en sil de kontrôler in nije lieder kieze.

Rys. 33. senario 6. Twa lieders

De orizjinele lieder kin in pear sekonden ynstjoerings akseptearje, mar hâldt dan op mei it akseptearjen fan alle berjochten. Klanten wurde elke 60 sekonden bywurke mei de lêste metadata. Se wurde ynformearre oer de feroaring fan 'e lieder en sille begjinne mei it ferstjoeren fan ynstjoerings nei de nije lieder.

Rys. 34. senario 6: Fabrikanten oerstappe nei in nije lieder

Alle befêstige yngongen makke troch de oarspronklike lieder sûnt it ferlies fan ferbining sille ferlern gean. Sadree't it netwurk is restaurearre, de oarspronklike lieder sil ûntdekke fia Zookeeper dat it is net mear de lieder. Dan sil it op it momint fan ferkiezing syn log oanmeitsje nei de HW fan 'e nije lieder en begjinne fersiken as folger te ferstjoeren.

Rys. 35. senario 6: De oarspronklike lieder wurdt in follower neidat netwurk ferbining is restaurearre

Yn dizze situaasje kin logyske skieding foar in koarte perioade foarkomme, mar allinich as acks=1 и min.insync.replicas ek 1. Logyske skieding automatysk einiget óf nei it netwurk wurdt restaurearre, doe't de oarspronklike lieder beseft dat hy is net mear de lieder, of as alle kliïnten beseffe dat de lieder is feroare en begjinne te skriuwen oan de nije lieder - wat bart earst. Yn alle gefallen, guon berjochten wurde ferlern, mar allinnich mei acks=1.

D'r is in oare fariant fan dit senario wêr't, krekt foardat it netwurk splitst, de followers efter foelen en de lieder de ISR komprimearre om gewoan himsels. It wurdt dan isolearre troch ferlies fan ferbining. In nije lieder wurdt keazen, mar de oarspronklike lieder bliuwt te akseptearjen ynstjoerings, sels acks = allegear, want der is gjinien oars yn ISR útsein him. Dizze records sille ferlern gean as it netwurk wersteld is. De ienige manier om dizze opsje te foarkommen is min.insync.replicas = 2.

Senario 7: Kafka Controller Node kin gjin oare Kafka Node sjen

Yn 't algemien, as ienris de ferbining mei in Kafka-knooppunt ferlern is, sil de kontrôler gjin ynformaasje oer liederwiziging nei har oerjaan. Yn it slimste gefal sil dit liede ta in koarte termyn logyske skieding, lykas yn senario 6. Faker as net sil de brokker gewoan gjin kandidaat wurde foar liederskip as de lêste mislearret.

Senario 8: Kafka-controller sjocht Zookeeper net

Zookeeper sil gjin ping ûntfange fan 'e fallen controller en sil in nij Kafka-knooppunt selektearje as de controller. De orizjinele kontrôler kin himsels as sadanich presintearje, mar hy ûntfangt gjin notifikaasjes fan Zookeeper, dus sil it gjin taken hawwe om út te fieren. Sadree't it netwurk is restaurearre, hy sil realisearje dat hy is net mear in controller, mar is wurden in gewoane Kafka-knooppunt.

Konklúzjes út de senario's

Wy sjogge dat it ferlies fan follower-ferbining net resulteart yn berjochtferlies, mar gewoan tydlik redundânsje fermindert oant it netwurk is restaurearre. Dit kin fansels liede ta gegevensferlies as ien of mear knopen ferlern gean.

As de lieder skieden wurdt fan Zookeeper troch in ferlies fan ferbining, kin dit resultearje yn berjochten dy't ferlern gean fan acks=1. Gebrek oan kommunikaasje mei Zookeeper soarget foar in koarte logyske splitsing mei de twa lieders. Dit probleem wurdt oplost troch de parameter acks = allegear.

Parameter min.insync.replicas yn twa of mear replika's jout ekstra garânsje dat sokke koarte termyn senario's net resultearje yn ferlernende berjochten lykas yn senario 6.

Gearfetting fan Lost Berjochten

Litte wy alle manieren listje wêrop jo gegevens kinne ferlieze yn Kafka:

• Eltse lieder falen as berjochten waarden befêstige mei help acks=1
• Eltse ûnreine oergong fan liederskip, dat is, nei in follower bûten de ISR, sels mei acks = allegear
• Isolearje de lieder fan Zookeeper as berjochten waarden befêstige mei help acks=1
• Folsleine isolemint fan 'e lieder dy't de ISR-groep al foar himsels fermindere hat. Alle berjochten sille ferlern gean, sels acks = allegear. Dit is allinnich wier as min.insync.replicas=1.
• Simultane mislearrings fan alle partition nodes. Om't berjochten út it ûnthâld wurde erkend, kinne guon noch net op skiif skreaun wurde. Nei it op 'e nij opstarten fan de servers kinne guon berjochten ûntbrekke.

Unreine liederskipstransysjes kinne wurde foarkommen troch se te ferbieden of te garandearjen fan op syn minst twa ûntslaggen. De meast duorsume konfiguraasje is in kombinaasje acks = allegear и min.insync.replicas mear as 1.

Direkte ferliking fan de betrouberens fan RabbitMQ en Kafka

Om betrouberens en hege beskikberens te garandearjen, implementearje beide platfoarms in primêr en sekundêr replikaasjesysteem. RabbitMQ hat lykwols in achilleshiel. By it opnij ferbinen nei in mislearring, knooppunten ferwiderje har gegevens en syngronisaasje wurdt blokkearre. Dizze dûbele whammy stelt de langstme fan grutte wachtrigen yn RabbitMQ yn twifel. Jo sille moatte akseptearje of fermindere ûntslach as lange blokkearjende tiden. Redundânsje ferminderje fergruttet it risiko fan massale gegevensferlies. Mar as de wachtrigen lyts binne, dan kinne om 'e redundânsje koarte perioaden fan ûnbeskikberens (in pear sekonden) wurde behannele mei werhelle ferbiningspogingen.

Kafka hat dit probleem net. It smyt gegevens allinich út it punt fan diverginsje tusken de lieder en de folger. Alle dielde gegevens wurde bewarre. Derneist blokkeart replikaasje it systeem net. De lieder bliuwt berjochten akseptearje wylst de nije folger it ynhaalt, dus foar devops wurdt it oansluten of wer meidwaan oan it kluster in triviale taak. Fansels binne d'r noch problemen lykas netwurkbânbreedte by replikaasje. As jo ​​​​meardere folgers tagelyk tafoegje, kinne jo in limyt foar bânbreedte tsjinkomme.

RabbitMQ is superieur oan Kafka yn betrouberens as meardere servers yn in kluster tagelyk mislearje. Lykas wy al sein hawwe, stjoert RabbitMQ in befêstiging nei de útjouwer pas nei't it berjocht op skiif skreaun is troch de master en alle spegels. Mar dit foeget ekstra latency ta om twa redenen:

• fsync elke pear hûndert millisekonden
• It mislearjen fan 'e spegel kin allinich opmurken wurde nei't it libben fan' e pakketten dy't de beskikberens fan elke knooppunt kontrolearje (net tick) is ferrûn. As de spegel fertraget of falt, foeget dit in fertraging ta.

Kafka syn weddenskip is dat as in berjocht wurdt opslein oer meardere knopen, it kin erkennen berjochten sa gau as se reitsje ûnthâld. Hjirtroch is d'r in risiko om berjochten fan elk type te ferliezen (sels acks = allegear, min.insync.replicas=2) yn gefal fan simultane mislearring.

Oer it algemien toant Kafka bettere softwareprestaasjes en is fan 'e grûn ôf ûntworpen foar klusters. It oantal folgers kin ferhege wurde nei 11 as it nedich is foar betrouberens. Replikaasjefaktor 5 en minimaal oantal replika's yn syngronisaasje min.insync.replicas=3 sil berjochtferlies in heul seldsum barren meitsje. As jo ​​​​ynfrastruktuer dizze replikaasjeferhâlding en it nivo fan redundânsje kin stypje, dan kinne jo dizze opsje kieze.

RabbitMQ-klustering is goed foar lytse wachtrijen. Mar sels lytse wachtriges kinne fluch groeie as der swier ferkear is. Sadree't wachtrigen grut wurde, moatte jo drege karren meitsje tusken beskikberens en betrouberens. RabbitMQ-klustering is it bêste geskikt foar net-typyske situaasjes wêr't de foardielen fan 'e fleksibiliteit fan RabbitMQ opwegen tsjin alle neidielen fan har klustering.

Ien tsjingif foar de kwetsberens fan RabbitMQ foar grutte wachtrigen is om se op te brekken yn in protte lytsere wachtrigen. As jo ​​​​gjin folsleine oardering fan 'e folsleine wachtrige nedich binne, mar allinich de relevante berjochten (bygelyks berjochten fan in spesifike klant), of hielendal neat bestelle, dan is dizze opsje akseptabel: sjoch nei myn projekt Rebalancer om de wachtrige te splitsen (it projekt is noch yn in ier stadium).

As lêste, ferjit net oer in oantal bugs yn 'e klustering- en replikaasjemeganismen fan sawol RabbitMQ as Kafka. Yn 'e rin fan' e tiid binne systemen folwoeksener en stabiler wurden, mar gjin berjocht sil ea 100% feilich wêze foar ferlies! Dêrneist barre grutskalige ûngemakken yn datasintra!

As ik wat miste, in flater makke, of as jo it net iens binne mei ien fan 'e punten, fiel jo frij om in reaksje te skriuwen of kontakt mei my op te nimmen.

Ik wurd faak frege: "Wat te kiezen, Kafka of RabbitMQ?", "Hokker platfoarm is better?". De wierheid is dat it echt hinget fan jo situaasje, aktuele ûnderfining, ensfh Ik twifelje myn miening te jaan, om't it te folle fan in oersimplifikaasje wêze soe om ien platfoarm foar alle gebrûksgefallen en mooglike beheiningen oan te rieden. Ik haw dizze searje artikels skreaun sadat jo jo eigen miening kinne foarmje.

Ik wol sizze dat beide systemen lieders binne op dit mêd. Ik kin in bytsje bias wêze, om't ik út myn ûnderfining mei projekten neigeraden dingen te wurdearjen lykas garandearre berjochtbestelling en betrouberens.

Ik sjoch oare technologyen dy't dizze betrouberens en garandearre oardering misse, dan sjoch ik nei RabbitMQ en Kafka en realisearje de ongelooflijke wearde fan dizze beide systemen.

Boarne: www.habr.com