Toleranca napak in visoka razpoložljivost sta veliki temi, zato bomo RabbitMQ in Kafki posvetili ločena članka. Ta članek govori o RabbitMQ, naslednji pa o Kafki v primerjavi z RabbitMQ. To je dolg članek, zato se udobno namestite.

Oglejmo si strategije tolerance napak, doslednosti in visoke razpoložljivosti (HA) ter kompromise, ki jih naredi vsaka strategija. RabbitMQ lahko deluje na gruči vozlišč - in je nato razvrščen kot porazdeljen sistem. Ko gre za porazdeljene sisteme, pogosto govorimo o doslednosti in razpoložljivosti.

Ti koncepti opisujejo, kako se sistem obnaša, ko odpove. Napaka omrežne povezave, napaka strežnika, napaka trdega diska, začasna nedosegljivost strežnika zaradi zbiranja smeti, izgube paketov ali upočasnitve omrežne povezave. Vse to lahko povzroči izgubo podatkov ali konflikte. Izkazalo se je, da je praktično nemogoče postaviti sistem, ki je hkrati popolnoma skladen (brez izgube podatkov, brez odstopanja podatkov) in na voljo (sprejemal bo branje in pisanje) za vse scenarije napak.

Videli bomo, da sta doslednost in razpoložljivost na nasprotnih koncih spektra, zato morate izbrati način optimizacije. Dobra novica je, da je z RabbitMQ ta izbira mogoča. Imate te nekakšne "piflarske" vzvode za premik ravnotežja k večji doslednosti ali večji dostopnosti.

Posebej bomo pozorni na to, katere konfiguracije vodijo do izgube podatkov zaradi potrjenih zapisov. Med založniki, posredniki in potrošniki obstaja veriga odgovornosti. Ko je sporočilo posredovano posredniku, je njegova naloga, da sporočila ne izgubi. Ko posrednik založniku potrdi prejem sporočila, ne pričakujemo, da bo izgubljeno. Vendar bomo videli, da se to dejansko lahko zgodi, odvisno od konfiguracije vašega posrednika in založnika.

Primitive odpornosti na eno vozlišče

Odporno čakalno vrsto/usmerjanje

V RabbitMQ obstajata dve vrsti čakalnih vrst: trajne in netrajne. Vse čakalne vrste so shranjene v bazi podatkov Mnesia. Trajne čakalne vrste so ponovno oglašene ob zagonu vozlišča in tako preživijo ponovne zagone, zrušitve sistema ali zrušitve strežnika (dokler so podatki obstojni). To pomeni, da dokler razglašate, da sta usmerjanje (izmenjava) in čakalna vrsta odporna, bo infrastruktura čakalne vrste/usmerjanja spet na spletu.

Nestanovitne čakalne vrste in usmerjanje se odstranijo, ko se vozlišče znova zažene.

Stalna sporočila

Samo zato, ker je čakalna vrsta trajna, ne pomeni, da bodo vsa njena sporočila preživela ponovni zagon vozlišča. Samo sporočila, ki jih je založnik določil kot odporen (vztrajno). Vztrajna sporočila sicer dodatno obremenijo posrednika, a če je izguba sporočila nesprejemljiva, potem ni druge možnosti.

riž. 1. Trajnostna matrika

Združevanje v gruče z zrcaljenjem čakalne vrste

Da bi preživeli izgubo posrednika, potrebujemo odpuščanje. Več vozlišč RabbitMQ lahko združimo v gručo in nato dodamo dodatno redundanco s podvajanjem čakalnih vrst med več vozlišči. Na ta način, če eno vozlišče odpove, ne izgubimo podatkov in ostanemo na voljo.

Zrcaljenje čakalne vrste:

• eno glavno čakalno vrsto (master), ki sprejema vse ukaze za pisanje in branje
• enega ali več ogledal, ki prejemajo vsa sporočila in metapodatke iz glavne čakalne vrste. Ta zrcala niso tam za skaliranje, ampak zgolj za redundanco.

riž. 2. Zrcaljenje čakalne vrste

Zrcaljenje je nastavljeno z ustreznim pravilnikom. V njem lahko izberete koeficient replikacije in celo vozlišča, na katerih naj bo čakalna vrsta. Primeri:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (en mojster in eno ogledalo)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Potrditev založnika

Da bi dosegli dosledno snemanje, so potrebna potrdila izdajatelja. Brez njih obstaja nevarnost izgube sporočil. Ko je sporočilo zapisano na disk, se založniku pošlje potrditev. RabbitMQ ne zapisuje sporočil na disk ob prejemu, ampak občasno, v območju nekaj sto milisekund. Ko je čakalna vrsta zrcaljena, je potrditev poslana šele potem, ko so tudi vsa zrcala zapisala svojo kopijo sporočila na disk. To pomeni, da uporaba potrditev poveča zakasnitev, a če je varnost podatkov pomembna, so nujne.

Čakalna vrsta za preklop

Ko posrednik zapre ali se zruši, se skupaj z njim zrušijo vsi voditelji čakalnih vrst (masterji) na tem vozlišču. Grozd nato izbere najstarejše ogledalo vsakega masterja in ga promovira kot novega masterja.

riž. 3. Več zrcaljenih čakalnih vrst in njihove politike

Posrednik 3 ne uspe. Upoštevajte, da je ogledalo Queue C na posredniku 2 povišano v glavnega. Upoštevajte tudi, da je bilo ustvarjeno novo ogledalo za čakalno vrsto C na posredniku 1. RabbitMQ vedno poskuša vzdrževati faktor podvajanja, naveden v vaših pravilnikih.

riž. 4. Posrednik 3 odpove, kar povzroči odpoved čakalne vrste C

Naslednji posrednik 1 pade! Imamo samo še enega posrednika. Ogledalo čakalne vrste B je povišano v glavnega.

Sl. 5

Vrnili smo posrednika 1. Ne glede na to, kako dobro podatki preživijo izgubo in obnovitev posrednika, so vsa zrcaljena sporočila v čakalni vrsti ob ponovnem zagonu zavržena. To je pomembno upoštevati, ker bodo posledice. Te posledice si bomo ogledali kmalu. Posrednik 1 je zdaj spet član gruče, gruča pa poskuša izpolnjevati pravilnike in zato ustvarja zrcala na posredniku 1.

V tem primeru je bila izguba posrednika 1 popolna, prav tako podatki, zato je bila nezrcaljena čakalna vrsta B popolnoma izgubljena.

riž. 6. Posrednik 1 se vrne v storitev

Posrednik 3 je spet na spletu, tako da čakalni vrsti A in B vrneta zrcala, ki so bila ustvarjena na njej, da zadovoljijo svoje politike HA. Toda zdaj so vse glavne čakalne vrste na enem vozlišču! To ni idealno, enakomerna porazdelitev med vozlišči je boljša. Na žalost tukaj ni veliko možnosti za rebalans masterjev. K tej težavi se bomo vrnili pozneje, ker moramo najprej pogledati sinhronizacijo čakalne vrste.

riž. 7. Posrednik 3 se vrne v storitev. Vse glavne čakalne vrste na enem vozlišču!

Zdaj bi morali imeti idejo o tem, kako zrcala zagotavljajo redundanco in toleranco na napake. To zagotavlja razpoložljivost v primeru okvare enega vozlišča in ščiti pred izgubo podatkov. Vendar še nismo končali, ker je v resnici veliko bolj zapleteno.

Sinhronizacija

Pri ustvarjanju novega ogledala bodo vsa nova sporočila vedno podvojena v to ogledalo in vsa druga. Kar zadeva obstoječe podatke v glavni čakalni vrsti, jih lahko repliciramo v novo ogledalo, ki postane popolna kopija glavnega. Lahko se tudi odločimo, da ne podvajamo obstoječih sporočil in pustimo, da se glavna čakalna vrsta in novo zrcalo pravočasno združita, pri čemer nova sporočila prispejo na rep, obstoječa sporočila pa zapustijo glavo glavne čakalne vrste.

Ta sinhronizacija se izvede samodejno ali ročno in se upravlja s pravilnikom čakalne vrste. Poglejmo si primer.

Imamo dve zrcaljeni čakalni vrsti. Čakalna vrsta A se sinhronizira samodejno, čakalna vrsta B pa ročno. Obe čakalni vrsti vsebujeta deset sporočil.

riž. 8. Dve čakalni vrsti z različnimi načini sinhronizacije

Zdaj izgubljamo posrednika 3.

riž. 9. Broker 3 je padel

Posrednik 3 se vrne v uporabo. Grozd ustvari ogledalo za vsako čakalno vrsto na novem vozlišču in samodejno sinhronizira novo čakalno vrsto A z glavnim. Vendar zrcalo nove čakalne vrste B ostaja prazno. Na ta način imamo popolno redundanco v čakalni vrsti A in samo eno ogledalo za obstoječa sporočila čakalne vrste B.

riž. 10. Novo ogledalo čakalne vrste A prejme vsa obstoječa sporočila, novo ogledalo čakalne vrste B pa ne.

V obe čakalni vrsti prispe še deset sporočil. Posrednik 2 se nato zruši in čakalna vrsta A se vrne nazaj na najstarejše zrcaljenje, ki je na posredniku 1. Pri odpovedi ne pride do izgube podatkov. V čakalni vrsti B je dvajset sporočil v glavnem sporočilu in samo deset v zrcalnem, ker ta čakalna vrsta ni nikoli podvojila prvotnih deset sporočil.

riž. 11. Čakalna vrsta A se vrne nazaj na posrednika 1 brez izgube sporočil

V obe čakalni vrsti prispe še deset sporočil. Zdaj se zruši posrednik 1. Čakalna vrsta A zlahka preklopi na zrcalo brez izgube sporočil. Vendar ima čakalna vrsta B težave. Na tej točki lahko optimiziramo razpoložljivost ali doslednost.

Če želimo optimizirati dostopnost, potem pravilnik ha-promocija-ob-neuspehu je treba namestiti v vedno. To je privzeta vrednost, zato pravilnika preprosto ne morete določiti. V tem primeru v bistvu dopuščamo napake v nesinhroniziranih zrcalih. To bo povzročilo izgubo sporočil, vendar bo čakalna vrsta ostala berljiva in zapisljiva.

riž. 12. Čakalna vrsta A se vrne nazaj na posrednika 3 brez izgube sporočil. Čakalna vrsta B se vrne nazaj na posrednika 3 z desetimi izgubljenimi sporočili

Lahko tudi montiramo ha-promote-on-failure v pomen when-synced. V tem primeru bo čakalna vrsta počakala, dokler se posrednik 1 s svojimi podatki ne vrne nazaj v zrcalni način. Ko se vrne, je glavna čakalna vrsta spet na posredniku 1 brez izgube podatkov. Razpoložljivost je žrtvovana zaradi varnosti podatkov. Toda to je tvegan način, ki lahko povzroči celo popolno izgubo podatkov, kar si bomo ogledali v kratkem.

riž. 13. Čakalna vrsta B ostane nedosegljiva po izgubi posrednika 1

Morda boste vprašali: "Ali je bolje, da nikoli ne uporabite samodejne sinhronizacije?" Odgovor je, da je sinhronizacija operacija blokiranja. Med sinhronizacijo glavna čakalna vrsta ne more izvajati nobenih operacij branja ali pisanja!

Poglejmo si primer. Zdaj imamo zelo dolge vrste. Kako lahko zrastejo do takšne velikosti? Iz več razlogov:

• Čakalne vrste se ne uporabljajo aktivno
• To so hitre čakalne vrste, potrošniki pa so trenutno počasni
• Čakalne vrste so visoke hitrosti, prišlo je do napake in potrošniki dohitevajo

riž. 14. Dve veliki čakalni vrsti z različnimi načini sinhronizacije

Zdaj Broker 3 pade.

riž. 15. Posrednik 3 pade, pri čemer ostaneta po en mojster in ogledalo v vsaki čakalni vrsti

Broker 3 se vrne na splet in ustvarjena so nova ogledala. Glavna čakalna vrsta A začne podvajati obstoječa sporočila v novo zrcaljenje in v tem času čakalna vrsta ni na voljo. Podvajanje podatkov traja dve uri, kar povzroči dve uri izpadov za to čakalno vrsto!

Vendar pa čakalna vrsta B ostane na voljo skozi celotno obdobje. Za dostopnost je žrtvovala nekaj odvečnosti.

riž. 16. Čakalna vrsta ostane nedosegljiva med sinhronizacijo

Po dveh urah postane na voljo tudi čakalna vrsta A in lahko ponovno začne sprejemati branja in pisanja.

Posodobitve

To blokiranje med sinhronizacijo otežuje posodabljanje gruč z zelo velikimi čakalnimi vrstami. Na neki točki je treba glavno vozlišče znova zagnati, kar pomeni preklop na zrcaljenje ali onemogočanje čakalne vrste med nadgradnjo strežnika. Če se odločimo za prehod, bomo izgubili sporočila, če ogledala niso sinhronizirana. Med izpadom posrednika se privzeto ne izvede samodejni preklop na nesinhronizirano zrcaljenje. To pomeni, da takoj, ko se posrednik vrne, ne izgubimo nobenega sporočila, edina škoda je bila preprosta čakalna vrsta. Pravila obnašanja, ko je posrednik prekinjen, so določena s pravilnikom ha-promote-on-shutdown. Nastavite lahko eno od dveh vrednosti:

• always= prehod na nesinhronizirana ogledala je omogočen
• when-synced= samo prehod na sinhronizirano zrcalo, sicer postane čakalna vrsta neberljiva in nezapisljiva. Čakalna vrsta se vrne v storitev takoj, ko se vrne posrednik

Tako ali drugače morate pri velikih čakalnih vrstah izbirati med izgubo podatkov in nedosegljivostjo.

Ko dostopnost izboljša varnost podatkov

Pred odločitvijo je treba upoštevati še en zaplet. Čeprav je samodejna sinhronizacija boljša za redundanco, kako vpliva na varnost podatkov? Seveda je manj verjetno, da bo RabbitMQ z boljšo redundanco izgubil obstoječa sporočila, kaj pa nova sporočila založnikov?

Tukaj morate upoštevati naslednje:

• Ali lahko izdajatelj preprosto vrne napako in naj storitev ali uporabnik poskusi znova pozneje?
• Ali lahko založnik shrani sporočilo lokalno ali v zbirko podatkov, da poskusi znova pozneje?

Če lahko založnik samo zavrže sporočilo, potem izboljšanje dostopnosti dejansko izboljša tudi varnost podatkov.

Tako je treba iskati ravnotežje, rešitev pa je odvisna od konkretne situacije.

Težave s ha-promote-on-failure=when-synced

Ideja ha-promocija-ob-neuspehu= ob sinhronizaciji je, da preprečimo preklop na nesinhronizirano ogledalo in s tem preprečimo izgubo podatkov. Čakalna vrsta ostane neberljiva ali zapisljiva. Namesto tega poskušamo obnoviti zrušenega posrednika z nedotaknjenimi podatki, tako da lahko nadaljuje z delovanjem kot glavni brez izgube podatkov.

Toda (in to je velik vendar), če je posrednik izgubil svoje podatke, potem imamo velik problem: čakalna vrsta je izgubljena! Vsi podatki so izginili! Tudi če imate zrcala, ki večinoma dohitevajo glavno čakalno vrsto, so tudi ta zrcala zavržena.

Za ponovno dodajanje vozlišča z istim imenom povemo gruči, naj pozabi izgubljeno vozlišče (z ukazom rabbitmqctl pozabite_vozlišče_gruče) in zaženite novega posrednika z istim imenom gostitelja. Medtem ko si gruča zapomni izgubljeno vozlišče, si zapomni staro čakalno vrsto in nesinhronizirana zrcala. Ko se gruči sporoči, naj pozabi osirotelo vozlišče, je pozabljena tudi ta čakalna vrsta. Zdaj ga moramo ponovno prijaviti. Izgubili smo vse podatke, čeprav smo imeli zrcala z delnim naborom podatkov. Bolje bi bilo preklopiti na nesinhronizirano ogledalo!

Zato je ročna sinhronizacija (in neuspešna sinhronizacija) v kombinaciji z ha-promote-on-failure=when-synced, po mojem mnenju precej tvegano. Dokumenti pravijo, da ta možnost obstaja zaradi varnosti podatkov, vendar je to dvorezen nož.

Master ponovno uravnoteženje

Kot obljubljeno, se vračamo k problemu kopičenja vseh masterjev na enem ali več vozliščih. To se lahko zgodi celo kot posledica tekoče posodobitve gruče. V gruči s tremi vozlišči se bodo vse glavne čakalne vrste zbrale na enem ali dveh vozliščih.

Ponovno uravnoteženje masterjev je lahko problematično iz dveh razlogov:

• Ni dobrih orodij za izvedbo ponovnega uravnoteženja
• Sinhronizacija čakalne vrste

Za ponovno uravnoteženje obstaja tretja oseba vtičnik, ki ni uradno podprt. Glede vtičnikov tretjih oseb v priročniku RabbitMQ rekel: »Vtičnik ponuja nekaj dodatnih orodij za konfiguracijo in poročanje, vendar ga ekipa RabbitMQ ne podpira ali preverja. Uporabljajte na lastno odgovornost."

Obstaja še en trik za premikanje glavne čakalne vrste skozi pravilnike HA. Priročnik omenja skripta za to. Deluje takole:

• Odstrani vsa ogledala z uporabo začasnega pravilnika, ki ima višjo prioriteto od obstoječega pravilnika HA.
• Spremeni začasno politiko HA za uporabo načina vozlišča, pri čemer določi vozlišče, v katero naj se prenese glavna čakalna vrsta.
• Sinhronizira čakalno vrsto za potisno selitev.
• Po končani selitvi izbriše začasni pravilnik. Začetna politika HA stopi v veljavo in ustvarjeno je zahtevano število zrcalnikov.

Slaba stran je, da ta pristop morda ne bo deloval, če imate velike čakalne vrste ali stroge zahteve glede odvečnosti.

Zdaj pa poglejmo, kako gruče RabbitMQ delujejo z omrežnimi particijami.

Izguba povezljivosti

Vozlišča porazdeljenega sistema so povezana z omrežnimi povezavami, omrežne povezave pa se lahko in bodo prekinjene. Pogostost izpadov je odvisna od lokalne infrastrukture oziroma zanesljivosti izbranega oblaka. Vsekakor pa jim morajo biti porazdeljeni sistemi kos. Spet imamo izbiro med razpoložljivostjo in doslednostjo in spet je dobra novica, da RabbitMQ ponuja obe možnosti (samo ne hkrati).

Z RabbitMQ imamo dve glavni možnosti:

• Omogoča logično delitev (split-brain). To zagotavlja razpoložljivost, vendar lahko povzroči izgubo podatkov.
• Onemogoči logično ločevanje. Lahko povzroči kratkotrajno izgubo razpoložljivosti, odvisno od tega, kako se odjemalci povezujejo z gručo. Lahko povzroči tudi popolno nerazpoložljivost v gruči z dvema vozliščema.

Toda kaj je logična ločitev? To je, ko se gruča zaradi izgube omrežnih povezav razdeli na dva dela. Na vsaki strani se ogledala povišajo v masterja, tako da je na koncu več masterjev na potezo.

riž. 17. Glavna čakalna vrsta in dve ogledali, vsaka na ločenem vozlišču. Nato pride do okvare omrežja in eno ogledalo se odklopi. Ločeno vozlišče vidi, da sta drugi dve odpadla, in svoja zrcala promovira glavnemu. Zdaj imamo dve glavni čakalni vrsti, zapisljivo in berljivo.

Če založniki pošljejo podatke obema glavnima, dobimo dve različni kopiji čakalne vrste.

Različni načini RabbitMQ zagotavljajo razpoložljivost ali doslednost.

Način ignoriranja (privzeto)

Ta način zagotavlja dostopnost. Po izgubi povezljivosti pride do logične ločitve. Ko je povezljivost ponovno vzpostavljena, se mora skrbnik odločiti, kateri particiji bo dal prednost. Poražena stran se bo znova zagnala in vsi zbrani podatki na tej strani bodo izgubljeni.

riž. 18. Trije založniki so povezani s tremi posredniki. Interno gruča vse zahteve usmeri v glavno čakalno vrsto na posredniku 2.

Zdaj izgubljamo posrednika 3. Vidi, da so drugi posredniki padli, in poviša svoje ogledalo v gospodarja. Tako pride do logične ločitve.

riž. 19. Logična delitev (split-brain). Zapisi gredo v dve glavni čakalni vrsti in dve kopiji se razhajata.

Povezljivost je obnovljena, vendar logična ločitev ostaja. Administrator mora ročno izbrati poraženo stran. V spodnjem primeru skrbnik ponovno zažene Broker 3. Vsa sporočila, ki jih ni uspel prenesti, so izgubljena.

riž. 20. Administrator onemogoči posrednika 3.

riž. 21. Administrator zažene Broker 3 in se pridruži gruči ter izgubi vsa sporočila, ki so tam ostala.

Med izgubo povezljivosti in po njeni obnovi sta bila gruča in ta čakalna vrsta na voljo za branje in pisanje.

Način samodejnega zdravljenja

Deluje podobno kot način Prezri, le da gruča sama samodejno izbere poraženo stran po razdelitvi in ​​obnovitvi povezljivosti. Poražena stran se vrne v gručo prazna in čakalna vrsta izgubi vsa sporočila, ki so bila poslana samo tej strani.

Zaustavi manjšinski način

Če ne želimo dovoliti logičnega particioniranja, je naša edina možnost, da zavržemo branje in pisanje na manjši strani za particijo gruče. Ko posrednik vidi, da je na manjši strani, prekine delo, torej zapre vse obstoječe povezave in zavrne nove. Enkrat na sekundo preveri obnovitev povezave. Ko je povezljivost ponovno vzpostavljena, nadaljuje z delovanjem in se pridruži gruči.

riž. 22. Trije založniki so povezani s tremi posredniki. Interno gruča vse zahteve usmeri v glavno čakalno vrsto na posredniku 2.

Posrednika 1 in 2 se nato ločita od posrednika 3. Namesto da bi svoje ogledalo povišali v glavnega, posrednik 3 prekine in postane nedosegljiv.

riž. 23. Posrednik 3 začasno ustavi, prekine povezavo z vsemi odjemalci in zavrne zahteve za povezavo.

Ko je povezljivost ponovno vzpostavljena, se vrne v gručo.

Poglejmo še en primer, kjer je glavna čakalna vrsta na posredniku 3.

riž. 24. Glavna čakalna vrsta na posredniku 3.

Nato pride do enake izgube povezljivosti. Broker 3 se ustavi, ker je na manjši strani. Na drugi strani vozlišča vidijo, da je posrednik 3 odpadel, zato je starejše ogledalo iz posrednikov 1 in 2 povišano v glavnega.

riž. 25. Prehod na posrednika 2, če posrednik 3 ni na voljo.

Ko bo povezljivost ponovno vzpostavljena, se bo posrednik 3 pridružil gruči.

riž. 26. Grozd se je vrnil v normalno delovanje.

Tukaj je pomembno razumeti, da pridobimo doslednost, lahko pa tudi razpoložljivost, če Stranke bomo uspešno prenesli na večji del oddelka. Za večino situacij bi osebno izbral način Pause Minority, vendar je res odvisno od posameznega primera.

Da bi zagotovili razpoložljivost, je pomembno zagotoviti, da se stranke uspešno povežejo z gostiteljem. Poglejmo naše možnosti.

Zagotavljanje povezljivosti strank

Imamo več možnosti, kako usmeriti odjemalce na glavni del gruče ali na delujoča vozlišča (po odpovedi enega vozlišča) po izgubi povezljivosti. Najprej si zapomnimo, da določena čakalna vrsta gostuje v določenem vozlišču, vendar se usmerjanje in pravilniki podvojijo v vseh vozliščih. Odjemalci se lahko povežejo s katerim koli vozliščem in notranje usmerjanje jih bo usmerilo, kamor morajo iti. Toda ko je vozlišče začasno ustavljeno, zavrne povezave, zato se morajo odjemalci povezati z drugim vozliščem. Če vozel odpade, sploh ne more storiti veliko.

Naše možnosti:

• Do gruče se dostopa z izravnalnikom obremenitve, ki preprosto kroži skozi vozlišča in odjemalci se znova poskušajo povezati, dokler ni uspešen. Če vozlišče ne deluje ali je začasno onemogočeno, bodo poskusi povezave s tem vozliščem neuspešni, vendar bodo nadaljnji poskusi šli na druge strežnike (na krožni način). To je primerno za kratkotrajno izgubo povezljivosti ali okvarjen strežnik, ki bo hitro ponovno vzpostavljen.
• Dostopajte do gruče prek izravnalnika obremenitve in odstranite suspendirana/neuspešna vozlišča s seznama, takoj ko so zaznana. Če to storimo hitro in če lahko stranke znova poskusijo vzpostaviti povezavo, bomo dosegli stalno razpoložljivost.
• Vsakemu odjemalcu dajte seznam vseh vozlišč in odjemalec pri povezovanju naključno izbere eno izmed njih. Če pri poskusu vzpostavitve povezave prejme napako, se premakne na naslednje vozlišče na seznamu, dokler se ne poveže.
• Odstranite promet iz neuspelega/začasno ustavljenega vozlišča z uporabo DNS. To se naredi z majhnim TTL.

Ugotovitve

Gručenje RabbitMQ ima svoje prednosti in slabosti. Najresnejše slabosti so:

• ko se pridružijo gruči, vozlišča zavržejo svoje podatke;
• blokiranje sinhronizacije povzroči, da čakalna vrsta postane nedosegljiva.

Vse težke odločitve izhajajo iz teh dveh arhitekturnih značilnosti. Če bi RabbitMQ lahko shranil podatke, ko je gruča ponovno združena, bi bila sinhronizacija hitrejša. Če bi bil sposoben sinhronizacije brez blokiranja, bi bolje podpiral velike čakalne vrste. Odpravljanje teh dveh težav bi močno izboljšalo delovanje RabbitMQ kot tehnologije sporočanja, ki je odporna na napake in je zelo razpoložljiva. RabbitMQ z združevanjem v gruče bi okleval priporočiti v naslednjih situacijah:

• Nezanesljivo omrežje.
• Nezanesljivo shranjevanje.
• Zelo dolge čakalne vrste.

Ko gre za nastavitve visoke razpoložljivosti, upoštevajte naslednje:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (Ali autoheal)
• obstojna sporočila
• zagotoviti, da se odjemalci povežejo z aktivnim vozliščem, ko kakšno vozlišče odpove

Za doslednost (varnost podatkov) upoštevajte naslednje nastavitve:

• Potrdila založnika in ročna potrdila na strani potrošnika
• ha-promote-on-failure=when-synced, če lahko izdajatelji poskusijo znova pozneje in če imate zelo zanesljivo shrambo! Sicer postavi =always.
• ha-sync-mode=automatic (vendar je za velike neaktivne čakalne vrste morda potreben ročni način; upoštevajte tudi, ali bo nedosegljivost povzročila izgubo sporočil)
• Zaustavi manjšinski način
• obstojna sporočila

Nismo še zajeli vseh vprašanj tolerance napak in visoke razpoložljivosti; na primer, kako varno izvajati administrativne postopke (kot so tekoče posodobitve). Pogovoriti se moramo tudi o federaciji in vtičniku Shovel.

Če sem še kaj zamudil, mi prosim sporočite.

Glej tudi moje post, kjer izvajam opustošenje v gruči RabbitMQ z uporabo Dockerja in Blockade, da preizkusim nekatere scenarije izgube sporočila, opisane v tem članku.

Prejšnji članki v seriji:
št. 1 - habr.com/ru/company/itsumma/blog/416629
št. 2 - habr.com/ru/company/itsumma/blog/418389
št. 3 - habr.com/ru/company/itsumma/blog/437446

Vir: www.habr.com