Tolerancija grešaka i visoka dostupnost su velike teme, pa ćemo RabbitMQ-u i Kafki posvetiti zasebne članke. Ovaj članak je o RabbitMQ-u, a sljedeći o Kafki protiv RabbitMQ-a. Članak je dugačak, pa se raskomotite.

Hajde da pogledamo strategije tolerancije grešaka, konzistentnosti i visoke dostupnosti (HA) i kompromise koji se moraju napraviti u svakoj strategiji. RabbitMQ može raditi na klasteru čvorova - i tada je klasifikovan kao distribuirani sistem. Kada su u pitanju distribuirani sistemi, često govorimo o konzistentnosti i dostupnosti.

Ovi koncepti opisuju kako se sistem ponaša kada pokvari. Greška mrežne veze, greška servera, kvar hard diska, privremena nedostupnost servera zbog sakupljanja smeća, gubitka paketa ili usporavanja mrežne veze. Sve to može dovesti do gubitka podataka ili sukoba. Ispostavilo se da je gotovo nemoguće podići sistem koji je i potpuno konzistentan (bez gubitka podataka, nema neslaganja podataka) i dostupan (prihvatiće čitanje i pisanje) za sve scenarije kvara.

Vidjet ćemo da su konzistentnost i dostupnost na različitim krajevima spektra, a vi morate odabrati koji način ćete optimizirati. Dobra vijest je da je s RabbitMQ-om ovaj izbor moguć. Imate neku vrstu "štreberskih" poluga da pomaknete ravnotežu ka većoj konzistentnosti ili većoj pristupačnosti.

Posebno ćemo obratiti pažnju na to koje konfiguracije dovode do gubitka podataka zbog potvrđenog upisivanja. Postoji lanac odgovornosti između izdavača, brokera i potrošača. Nakon što je poruka proslijeđena brokeru, njegov je posao da ne izgubi poruku. Kada broker potvrdi poruku izdavaču, ne očekujemo da će biti izgubljena. Ali vidjet ćemo da se to zapravo može dogoditi ovisno o konfiguraciji vašeg brokera i izdavača.

Primitive otpornosti jednog čvora

Trajni redovi/usmjeravanje

Postoje dvije vrste reda u RabbitMQ-u: izdržljiv/stabilan (trajan) i nestabilan (netrajan). Svi redovi se pohranjuju u bazu podataka Mnesia. Trajni redovi se ponovo deklariraju pri pokretanju čvora i tako preživljavaju ponovno pokretanje, pad sistema ili pad servera (sve dok podaci traju). To znači da sve dok deklarišete usmjeravanje (razmjenu) i red čekanja postojanim, infrastruktura čekanja/usmjeravanja će se vratiti na mrežu.

Nestalni redovi i usmjeravanje se uklanjaju kada se čvor ponovno pokrene.

Održive poruke

Samo zato što je red trajan ne znači da će sve njegove poruke preživjeti ponovno pokretanje čvora. Samo poruke koje je izdavač postavio kao elastičan (uporan). Stalne poruke dodatno opterećuju brokera, ali ako je gubitak poruke neprihvatljiv, onda nema druge opcije.

Rice. 1. Matrica stabilnosti

Grupiranje sa zrcaljenjem redova

Da bismo preživjeli gubitak brokera, potreban nam je višak. Možemo grupirati više RabbitMQ čvorova i zatim dodati dodatnu redundantnost repliciranjem redova na više čvorova. Dakle, ako se jedan čvor pokvari, ne gubimo podatke i ostajemo dostupni.

Zrcaljenje reda čekanja:

• jedan glavni red (master) koji prima sve naredbe za pisanje i čitanje
• jedan ili više ogledala koji primaju sve poruke i metapodatke iz glavnog reda čekanja. Ova ogledala ne postoje za skaliranje, već isključivo za redundantnost.

Rice. 2. Preslikavanje reda

Zrcaljenje je postavljeno odgovarajućom politikom. U njemu možete odabrati faktor replikacije, pa čak i čvorove na koje treba postaviti red. primjeri:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (jedan majstor i jedno ogledalo)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Potvrda izdavača

Potvrde izdavača su potrebne da bi se postiglo dosljedno pisanje. Bez njih postoji mogućnost gubitka poruka. Potvrda se šalje izdavaču nakon što je poruka zapisana na disk. RabbitMQ zapisuje poruke na disk ne po prijemu, već na periodičnoj osnovi, u području od nekoliko stotina milisekundi. Kada je red preslikan, potvrda se šalje tek nakon što sva ogledala također upišu svoju kopiju poruke na disk. To znači da upotreba potvrda dodaje latencije, ali ako je sigurnost podataka važna, onda su one neophodne.

Failover Queue

Kada se broker isključi ili sruši, svi vođe reda (masteri) na tom čvoru otpadaju s njim. Klaster tada bira najstarije ogledalo svakog mastera i promoviše ga kao novog mastera.

Rice. 3. Višestruki zrcaljeni redovi i njihova pravila

Broker 3 se ruši. Imajte na umu da se ogledalo reda C na Brokeru 2 unapređuje u master. Također imajte na umu da je kreirano novo ogledalo za Red C na Brokeru 1. RabbitMQ uvijek pokušava održati faktor replikacije naveden u vašim politikama.

Rice. 4. Broker 3 pada, uzrokujući neuspjeh reda C

Sljedeći Broker 1 je pao! Ostao nam je samo jedan broker. Ogledalo reda B se unapređuje u master.

Fig. 5

Vratili smo Brokera 1. Bez obzira na to koliko su podaci preživjeli gubitak i oporavak brokera, sve preslikane poruke reda se odbacuju pri ponovnom pokretanju. Ovo je važno napomenuti jer će biti posljedica. Uskoro ćemo razmotriti ove implikacije. Dakle, Broker 1 je sada ponovo član klastera, a klaster pokušava da se pridržava pravila i stoga kreira ogledala na Brokeru 1.

U ovom slučaju, gubitak brokera 1 je bio potpun, kao i gubitak podataka, tako da je red čekanja B bez ogledala potpuno izgubljen.

Rice. 6. Broker 1 se vraća u službu

Broker 3 je ponovo na mreži, tako da redovi A i B vraćaju svoja ogledala kako bi zadovoljili svoje HA politike. Ali sada su svi glavni redovi na istom čvoru! Nije savršeno, bolje je imati ujednačenu distribuciju između čvorova. Nažalost, ne postoje posebne opcije za rebalans mastera. Kasnije ćemo se vratiti na ovaj problem, jer prvo trebamo razmotriti sinhronizaciju redova čekanja.

Rice. 7. Broker 3 se vraća u službu. Svi glavni redovi na jednom čvoru!

Dakle, do sada biste trebali imati ideju o tome kako ogledala pružaju redundantnost i toleranciju grešaka. Ovo osigurava dostupnost u slučaju kvara jednog čvora i štiti od gubitka podataka. Ali još nismo gotovi, jer je u stvari sve mnogo komplikovanije.

Sync

Kada se kreira novo ogledalo, sve nove poruke će se uvijek replicirati na to ogledalo i sve druge. Što se tiče postojećih podataka u glavnom redu, možemo ih replicirati na novo ogledalo, koje postaje potpuna kopija mastera. Također možemo odabrati da ne repliciramo postojeće poruke i dozvolimo glavnom redu i novom ogledalu da se konvergiraju u vrijeme kada nove poruke uđu u rep, a postojeće poruke napuste glavu glavnog reda.

Ova sinhronizacija je automatska ili ručna i kontroliše se politikom čekanja. Razmotrimo primjer.

Imamo dva zrcaljena reda. Red A se sinhronizuje automatski, dok se Red B sinhronizuje ručno. Oba reda čekanja sadrže deset poruka.

Rice. 8. Dva reda s različitim vremenskim modovima

Sada gubimo Brokera 3.

Rice. 9. Broker 3 je pao

Broker 3 je ponovo u funkciji. Klaster kreira ogledalo za svaki red na novom čvoru i automatski sinhronizuje novi red A sa glavnim. Međutim, ogledalo novog reda B ostaje prazno. Dakle, imamo potpunu redundantnost reda A i samo jedno ogledalo za postojeće poruke reda B.

Rice. 10. Novo ogledalo reda A prima sve postojeće poruke, ali novo ogledalo reda B ne prima

Oba reda primaju još deset poruka. Broker 2 tada pada, a red A se vraća na najstariji ogledalo, koji je na Brokeru 1. Nema gubitka podataka kada ne uspije. Red B ima dvadeset poruka u masteru i samo deset u ogledalu jer taj red nikada nije replicirao originalnih deset poruka.

Rice. 11. Posrednik 1 vraća red A bez gubitka poruke

Oba reda primaju po deset poruka više. Broker 1 se sada ruši. Red A prelazi na ogledalo bez gubitka poruke. Međutim, Red B ima problema. U ovom trenutku možemo optimizirati ili dostupnost ili konzistentnost.

Ako želimo optimizirati dostupnost, onda politika ha-promovirati-na-neuspjeh treba ugraditi u uvijek. Ovo je zadana vrijednost, tako da jednostavno ne možete navesti politiku uopće. U takvom slučaju, u stvari, dopuštamo kvarove u ogledalima koja nisu sinhronizirana. Ovo će uzrokovati gubitak poruka, ali red čekanja ostaje čitljiv i upisiv.

Rice. 12. Red A se vraća na Brokera 3 bez gubitka poruke. Red B se vraća na Brokera 3 sa deset izgubljenih poruka

Možemo i instalirati ha-promote-on-failure u značenje when-synced. U ovom slučaju, umjesto vraćanja na ogledalo, red čekanja će čekati dok se Broker 1 ne vrati na mrežu sa svojim podacima. Nakon što se vrati, glavni red se vraća na Broker 1 bez gubitka podataka. Dostupnost se žrtvuje radi sigurnosti podataka. Ali ovo je rizičan način rada, koji čak može dovesti do potpunog gubitka podataka, što ćemo uskoro razmotriti.

Rice. 13. Red B ostaje nedostupan nakon gubitka Brokera 1

Možete postaviti pitanje: "Možda je bolje nikada ne koristiti automatsku sinhronizaciju?". Odgovor je da je sinhronizacija operacija blokiranja. Tokom sinhronizacije, glavni red ne može izvršiti nikakve operacije čitanja ili pisanja!

Razmotrimo primjer. Sada imamo veoma duge redove. Kako mogu narasti do takve veličine? Iz nekoliko razloga:

• Redovi se ne koriste aktivno
• Ovo su redovi velike brzine, a potrošači trenutno trče sporo.
• Ovo su brzi redovi, došlo je do kvara i potrošači sustižu

Rice. 14. Dva velika reda s različitim vremenskim modovima

Broker 3 se sada ruši.

Rice. 15. Broker 3 se ruši ostavljajući jednog mastera i ogledalo u svakom redu

Broker 3 se vraća online i kreiraju se nova ogledala. Glavni red čekanja A počinje replicirati postojeće poruke na novo ogledalo, a za to vrijeme red čekanja nije dostupan. Potrebno je dva sata da se repliciraju podaci, što rezultira dva sata zastoja za ovaj Red!

Međutim, red B ostaje dostupan tokom cijelog perioda. Žrtvovala je malo viška radi pristupačnosti.

Rice. 16. Red čekanja ostaje nedostupan tokom sinhronizacije

Nakon dva sata, red A također postaje dostupan i može ponovo početi prihvaćati čitanje i pisanje.

Ažuriranja

Ovo blokirajuće ponašanje tijekom sinhronizacije otežava ažuriranje klastera s vrlo velikim redovima čekanja. U nekom trenutku, glavni čvor treba ponovo pokrenuti, što znači ili odlazak na ogledalo ili isključivanje reda čekanja tokom nadogradnje servera. Ako se odlučimo za tranziciju, izgubit ćemo poruke ako ogledala nisu sinhronizirana. Podrazumevano, tokom prekida rada brokera, prelazak na grešku na ogledalo van sinhronizacije se ne izvodi. To znači da čim se broker vrati, mi ne gubimo nijednu poruku, jedina šteta je samo običan red čekanja. Pravila ponašanja kada je broker isključen su postavljena politikom ha-promote-on-shutdown. Možete postaviti jednu od dvije vrijednosti:

• always= Omogućeno prebacivanje na nesinhronizovana ogledala
• when-synced= Premjesti samo na sinhronizirano ogledalo, inače red postaje nečitljiv i može se pisati. Red se vraća u funkciju čim se broker vrati

Na ovaj ili onaj način, s velikim redovima čekanja, morate birati između gubitka podataka i nedostupnosti.

Kada dostupnost poboljšava sigurnost podataka

Postoji još jedna komplikacija koju treba razmotriti prije donošenja odluke. Iako je automatska sinhronizacija bolja za redundantnost, kako to utiče na sigurnost podataka? Naravno, uz bolju redundantnost, RabbitMQ je manje vjerovatno da će izgubiti postojeće poruke, ali što je s novim porukama od izdavača?

Ovdje morate uzeti u obzir sljedeće:

• Može li izdavač jednostavno vratiti grešku i naložiti upstream servisu ili korisniku da pokuša ponovo kasnije?
• Može li izdavač sačuvati poruku lokalno ili u bazi podataka da pokuša ponovo kasnije?

Ako je izdavač samo u mogućnosti da odbaci poruku, u stvari, poboljšanje pristupačnosti poboljšava i sigurnost podataka.

Dakle, mora se tražiti balans, a odluka zavisi od konkretne situacije.

Problemi sa ha-promote-on-failure=when-synced

Ideja ha-promovirati-na-neuspjeh= kada se sinhronizuje je da sprečavamo prelazak na nesinhronizovano ogledalo i na taj način izbegavamo gubitak podataka. Red ostaje nečitljiv ili može se pisati. Umjesto toga, pokušavamo vratiti palog brokera sa netaknutim podacima kako bi mogao nastaviti kao glavni bez gubitka podataka.

Ali (a ovo je veliko ali) ako je broker izgubio svoje podatke, onda imamo veliki problem: red je izgubljen! Svi podaci su nestali! Čak i ako imate ogledala koja uglavnom sustižu glavni red čekanja, ta ogledala se takođe odbacuju.

Da ponovo dodate čvor sa istim imenom, kažemo klasteru da zaboravi napušteni čvor (sa rabbitmqctl zaboravi_cluster_node) i pokrenite novog brokera sa istim imenom hosta. Dok klaster pamti izgubljeni čvor, on pamti stari red čekanja i ogledala koja nisu sinhronizovana. Kada se klasteru kaže da zaboravi izgubljeni čvor, ovaj red se također zaboravlja. Sada to moramo ponovo proglasiti. Izgubili smo sve podatke iako smo imali ogledala s djelomičnim skupom podataka. Bilo bi bolje da se prebacite na nesinhronizovano ogledalo!

Stoga, ručna sinhronizacija (i neuspjeh u sinhronizaciji) u kombinaciji sa ha-promote-on-failure=when-syncedpo mom mišljenju prilično rizično. Dokumenti kažu da ova opcija postoji za sigurnost podataka, ali je nož s dvije oštrice.

Master rebalans

Kao što smo obećali, vraćamo se na problem akumulacije svih mastera na jednom ili više čvorova. Ovo se čak može dogoditi kao rezultat ažuriranja klastera. U klasteru sa tri čvora, svi glavni redovi će se akumulirati na jednom ili dva čvora.

Rebalans mastera može biti problematičan iz dva razloga:

• Ne postoje dobri alati za izvođenje rebalansa
• Sinhronizacija reda čekanja

Postoji treća strana za rebalans dodatak, koji nije zvanično podržan. Što se tiče dodataka trećih strana u priručniku RabbitMQ rekao: "Dodatak pruža neke dodatne alate za konfiguraciju i izvještavanje, ali ga RabbitMQ tim ne podržava niti testira. Koristite na vlastitu odgovornost."

Postoji još jedan trik za pomicanje glavnog reda kroz HA politike. U priručniku se spominje skripta za ovo. Radi ovako:

• Uklanja sva ogledala koristeći privremenu politiku s višim prioritetom od postojeće HA politike.
• Mijenja privremenu politiku HA da koristi način rada "čvorovi", navodeći čvor na koji želite premjestiti glavni red čekanja.
• Sinhronizira red za prisilnu migraciju.
• Nakon što je migracija završena, briše se privremena politika. Originalna HA politika stupa na snagu i stvara se potreban broj ogledala.

Loša strana je što ovaj pristup možda neće raditi ako imate velike redove ili stroge zahtjeve za redundantnošću.

Sada da vidimo kako RabbitMQ klasteri rade sa mrežnim particijama.

Poremećaj povezivanja

Čvorovi distribuiranog sistema povezani su mrežnim vezama, a mrežne veze mogu i bit će isključene. Učestalost prekida ovisi o lokalnoj infrastrukturi ili pouzdanosti odabranog oblaka. U svakom slučaju, distribuirani sistemi bi trebali biti u stanju da ih nose. Opet imamo izbor između dostupnosti i dosljednosti, a opet dobra vijest je da RabbitMQ nudi obje opcije (samo ne u isto vrijeme).

Sa RabbitMQ imamo dvije glavne opcije:

• Dozvolite logičko razdvajanje (split-brain). Ovo osigurava dostupnost, ali može uzrokovati gubitak podataka.
• Onemogući logičko razdvajanje. Može rezultirati kratkoročnim gubitkom dostupnosti ovisno o tome kako se klijenti povezuju na klaster. Također može uzrokovati potpunu nedostupnost u klasteru s dva čvora.

Ali šta je logična podela? To je kada se klaster podijeli na dva dijela zbog gubitka mrežnih veza. Sa svake strane, ogledala se promovišu u master, tako da na kraju ima nekoliko mastera po redu.

Rice. 17. Glavni red čekanja i dva ogledala, svako na zasebnom čvoru. Zatim dolazi do kvara mreže i jedno ogledalo je odvojeno. Odvojeni čvor vidi da su druga dva otpala i pomera svoja ogledala ka masteru. Sada imamo dva glavna reda čekanja, od kojih su oba čitljiva i upisiva.

Ako izdavači pošalju podatke oba mastera, imat ćemo dvije različite kopije reda.

Različiti načini RabbitMQ-a pružaju ili dostupnost ili dosljednost.

Način ignoriranja (zadano)

Ovaj način rada pruža pristupačnost. Nakon gubitka veze, dolazi do logičnog razdvajanja. Nakon što se veza vrati, administrator mora odlučiti kojoj particiji će dati prioritet. Gubitnička strana će se ponovo pokrenuti i svi akumulirani podaci s te strane će biti izgubljeni.

Rice. 18. Tri izdavača su povezana sa tri brokera. Interno, klaster usmjerava sve zahtjeve u glavni red na Brokeru 2.

Sada gubimo Brokera 3. On vidi da su ostali brokeri otpali i pomakne svoje ogledalo do gospodara. Ovako dolazi do logičkog razdvajanja.

Rice. 19. Logička podjela (split-brain). Zapisi idu u dva glavna reda čekanja, a dvije kopije izlaze.

Povezivanje je obnovljeno, ali logično razdvajanje ostaje. Administrator mora ručno odabrati stranu koja gubi. U sledećem slučaju, administrator ponovo pokreće Broker 3. Sve poruke koje nije imao vremena da prenese su izgubljene.

Rice. 20. Administrator onemogućuje Brokera 3.

Rice. 21. Administrator pokreće Broker 3 i on se pridružuje klasteru, gubeći sve poruke koje su tamo ostavljene.

Tokom gubitka veze i nakon njenog obnavljanja, klaster i ovaj red su bili dostupni za čitanje i pisanje.

Autoheal mode

Radi slično načinu ignoriranja, osim što sam klaster automatski bira gubitničku stranu nakon razdvajanja i ponovnog povezivanja. Strana koja gubi se vraća u prazan klaster, a red gubi sve poruke koje su poslane samo toj strani.

Pauzirajte manji način rada

Ako ne želimo dozvoliti logičko particioniranje, onda je naša jedina opcija da odbijemo čitanje i pisanje na manjoj strani nakon particije klastera. Kada broker vidi da je na manjoj strani, obustavlja rad, odnosno zatvara sve postojeće veze i odbija sve nove. Jednom u sekundi, provjerava ponovno povezivanje. Čim se veza uspostavi, nastavlja sa radom i pridružuje se klasteru.

Rice. 22. Tri izdavača su povezana sa tri brokera. Interno, klaster usmjerava sve zahtjeve u glavni red na Brokeru 2.

Brokeri 1 i 2 se zatim odvajaju od Brokera 3. Umesto da promoviše svoje ogledalo u master, Broker 3 pauzira i postaje nedostupan.

Rice. 23. Broker 3 suspenduje, isključuje sve klijente i odbija zahtjeve za povezivanje.

Čim se veza uspostavi, vraća se u klaster.

Pogledajmo još jedan primjer gdje je glavni red na Brokeru 3.

Rice. 24. Glavni red kod Brokera 3.

Tada dolazi do istog gubitka veze. Broker 3 pauzira jer je na manjoj strani. Sa druge strane, čvorovi vide da je Broker 3 otpao, tako da se starije ogledalo od Brokera 1 i 2 unapređuje u master.

Rice. 25. Prebacivanje na Broker 2 kada Broker 3 nije dostupan.

Kada se veza uspostavi, Broker 3 će se pridružiti klasteru.

Rice. 26. Klaster se vratio u normalan rad.

Ovdje je važno shvatiti da postižemo dosljednost, ali možemo dobiti i pristupačnost, ako uspješno ćemo prebaciti klijente na veći dio odjeljka. Za većinu situacija, lično bih odabrao Pause Minority mod, ali to stvarno ovisi o pojedinačnom slučaju.

Da bi se osigurala dostupnost, važno je osigurati da se klijenti uspješno povezuju na host. Pogledajmo naše opcije.

Osiguravanje povezanosti kupaca

Imamo nekoliko opcija kako da usmjerimo klijente na glavni dio klastera ili na radne čvorove nakon gubitka konekcije (nakon kvara jednog čvora). Prvo, zapamtimo da se određeni red nalazi na određenom čvoru, ali se usmjeravanje i politike repliciraju na sve čvorove. Klijenti se mogu povezati na bilo koji čvor, a interno rutiranje će ih usmjeriti tamo gdje trebaju ići. Ali kada je čvor pauziran, on odbija veze, tako da se klijenti moraju povezati na drugi čvor. Ako je čvor otpao, može učiniti malo.

Naše opcije:

• Klasteru se pristupa pomoću balansera opterećenja koji jednostavno kruži kroz čvorove i klijenti pokušavaju ponovo da se povežu dok ne uspeju. Ako je čvor prekinut ili suspendovan, pokušaji povezivanja na taj čvor neće uspjeti, ali će naredni pokušaji ići na druge servere (na kružni način). Ovo je pogodno za trenutni gubitak veze ili oboren server koji će se brzo pokrenuti.
• Pristup klasteru preko balansera opterećenja i uklanjanje suspendovanih/spalih čvorova sa liste čim se otkriju. Ako se to uradi brzo i ako klijenti budu u mogućnosti da ponovo pokušaju povezivanje, tada ćemo dobiti stalnu dostupnost.
• Dajte svakom klijentu listu svih čvorova, a klijent nasumično bira jedan od njih kada se poveže. Ako dobije grešku dok pokušava da se poveže, prelazi na sledeći čvor na listi dok se ne poveže.
• Uklonite saobraćaj sa oborenog/suspendovanog hosta koristeći DNS. Ovo se radi sa malim TTL-om.

nalazi

RabbitMQ klasterisanje ima svoje prednosti i nedostatke. Najozbiljniji nedostaci su:

• kada se pridružuju klasteru, čvorovi odbacuju svoje podatke;
• blokiranje sinhronizacije uzrokuje da red postane nedostupan.

Sve teške odluke proizlaze iz ove dvije arhitektonske karakteristike. Kada bi RabbitMQ mogao sačuvati podatke prilikom ponovnog pridruživanja klasteru, tada bi sinhronizacija bila brža. Da je sposoban za neblokirajuću sinhronizaciju, bolje bi podržavao velike redove čekanja. Popravljanje ova dva problema bi uvelike poboljšalo performanse RabbitMQ-a kao tehnologije tolerantne na greške i visoko dostupne tehnologije za razmjenu poruka. Oklevao bih preporučiti RabbitMQ sa klasterizacijom u sljedećim situacijama:

• Nepouzdana mreža.
• Nepouzdano skladištenje.
• Veoma dugi redovi.

Što se tiče postavki za visoku dostupnost, razmotrite sljedeće:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (ili autoheal)
• održive poruke
• pobrinite se da se klijenti povežu na aktivni čvor kada neki čvor padne

Za dosljednost (sigurnost podataka), razmotrite sljedeće postavke:

• Potvrde izdavača i ručna priznanja na strani potrošača
• ha-promote-on-failure=when-syncedako izdavači mogu pokušati ponovo kasnije i ako imate jako jak prostor za pohranu! Inače stavi =always.
• ha-sync-mode=automatic (ali veliki neaktivni redovi mogu zahtijevati ručni način rada; također, razmislite da li će nedostupnost uzrokovati gubitak poruka)
• Pauzirajte Manjinski način rada
• održive poruke

Još nismo pokrili sva pitanja tolerancije grešaka i visoke dostupnosti; na primjer, kako bezbedno izvršiti administrativne procedure (kao što su ažuriranja u toku). Također moramo razgovarati o federaciji i dodatku Shovel.

Ako sam još nešto propustio, javite mi.

Vidi i moj postgdje pogromiram RabbitMQ klaster s Dockerom i Blockade kako bih testirao neke od scenarija gubitka poruka opisanih u ovom članku.

Prethodni članci iz serije:
br. 1 - habr.com/ru/company/itsumma/blog/416629
br. 2 - habr.com/ru/company/itsumma/blog/418389
br. 3 - habr.com/ru/company/itsumma/blog/437446

izvor: www.habr.com