A hibatűrés és a magas rendelkezésre állás nagy téma, ezért külön cikkeket fogunk szentelni a RabbitMQ-nak és a Kafkának. Ez a cikk a RabbitMQ-ról szól, a következő pedig Kafkáról szól, összehasonlítva a RabbitMQ-val. Ez egy hosszú cikk, úgyhogy érezd jól magad.
Nézzük meg a hibatűrési, következetességi és magas rendelkezésre állási (HA) stratégiákat, valamint az egyes stratégiák által kínált kompromisszumokat. A RabbitMQ csomópontok klaszterén futhat, majd elosztott rendszernek minősül. Amikor az elosztott rendszerekről van szó, gyakran beszélünk konzisztenciáról és elérhetőségről.
Ezek a fogalmak leírják, hogyan viselkedik egy rendszer, ha meghibásodik. Hálózati kapcsolathiba, szerverhiba, merevlemez-hiba, a szerver ideiglenes elérhetetlensége szemétgyűjtés miatt, csomagvesztés vagy hálózati kapcsolat lelassulása. Mindez adatvesztéshez vagy konfliktusokhoz vezethet. Kiderült, hogy szinte lehetetlen olyan rendszert felállítani, amely teljesen konzisztens (nincs adatvesztés, nincs adateltérés) és elérhető (elfogadja az olvasást és az írást) minden meghibásodási forgatókönyvre.
Látni fogjuk, hogy a konzisztencia és a rendelkezésre állás a spektrum ellentétes végén található, és ki kell választania az optimalizálási módot. A jó hír az, hogy a RabbitMQ-val ez a választás lehetséges. Vannak ilyen „majom” karok, amelyekkel áthelyezheti az egyensúlyt a nagyobb következetesség vagy jobb hozzáférhetőség felé.
Külön figyelmet fordítunk arra, hogy mely konfigurációk vezetnek adatvesztéshez a visszaigazolt rekordok miatt. Felelősségi lánc van a kiadók, a közvetítők és a fogyasztók között. Miután az üzenetet elküldték a brókernek, az ő feladata, hogy ne veszítse el az üzenetet. Amikor a közvetítő visszaigazolja az üzenet kiadó általi kézhezvételét, nem számítunk annak elvesztésére. De látni fogjuk, hogy ez valóban megtörténhet a közvetítő és a megjelenítő konfigurációjától függően.
Egycsomópontos rugalmassági primitívek
Rugalmas sorban állás/útválasztás
A RabbitMQ-ban kétféle sor létezik: tartós és nem tartós. Az összes sor az Mnesia adatbázisba kerül mentésre. A tartós várólisták a csomópont indításakor újra meghirdetésre kerülnek, és így túlélik az újraindítást, a rendszer összeomlást vagy a szerver összeomlást (amíg az adatok megmaradnak). Ez azt jelenti, hogy mindaddig, amíg az útválasztást (csere) és a várólista rugalmasnak nyilvánítja, a sorban állási/útválasztási infrastruktúra újra online lesz.
Az ingadozó várólisták és az útválasztás a csomópont újraindításakor törlődnek.
Állandó üzenetek
Csak azért, mert egy sor tartós, nem jelenti azt, hogy minden üzenete túléli a csomópont újraindítását. Csak a kiadó által beállított üzenetek kitartó (kitartó). A tartós üzenetek további terhelést jelentenek a közvetítő számára, de ha az üzenetvesztés elfogadhatatlan, akkor nincs más lehetőség.
Rizs. 1. Fenntarthatósági mátrix
Klaszterezés sortükrözéssel
Ahhoz, hogy túléljük egy bróker elvesztését, redundanciára van szükségünk. Több RabbitMQ-csomópontot is kombinálhatunk egy fürtbe, majd további redundanciát adhatunk több csomópont közötti sorok replikálásával. Így, ha egy csomópont meghibásodik, nem veszítünk el adatokat, és elérhetőek maradunk.
Sor tükrözése:
- egy fő sor (master), amely megkapja az összes írási és olvasási parancsot
- egy vagy több tükör, amely megkapja az összes üzenetet és metaadatot a fő sorból. Ezek a tükrök nem méretezésre vannak, hanem pusztán redundanciára.
Rizs. 2. Sor tükrözés
A tükrözést a megfelelő házirend állítja be. Ebben kiválaszthatja a replikációs együtthatót, és még azokat a csomópontokat is, amelyeken a sornak elhelyezkednie kell. Példák:
ha-mode: allha-mode: exactly, ha-params: 2(egy mester és egy tükör)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
Kiadói visszaigazolás
A következetes rögzítés eléréséhez kiadói visszaigazolás szükséges. Ezek nélkül fennáll az üzenetek elvesztésének veszélye. Az üzenet lemezre írása után megerősítést küld a kiadónak. A RabbitMQ nem a beérkezéskor, hanem időszakosan, több száz ezredmásodperces tartományban ír üzeneteket a lemezre. Amikor egy várólista tükröződik, a nyugtázás csak akkor kerül elküldésre, ha az összes tükör is lemezre írta az üzenet másolatát. Ez azt jelenti, hogy a megerősítések növelik a késleltetést, de ha fontos az adatbiztonság, akkor szükség van rájuk.
Feladatátvételi sor
Amikor egy bróker kilép vagy összeomlik, az adott csomóponton lévő összes sorvezető (master) vele együtt összeomlik. A fürt ezután kiválasztja az egyes mesterek legrégebbi tükrét, és előlépteti új mesterré.
Rizs. 3. Több tükrözött sor és házirendjeik
A 3. bróker leáll. Ne feledje, hogy a Broker 2-ben a Queue C tükröt mesterré léptetik elő. Vegye figyelembe azt is, hogy egy új tükör jött létre a C sorhoz a Broker 1-en. A RabbitMQ mindig megpróbálja fenntartani a házirendekben megadott replikációs tényezőt.
Rizs. 4. A 3. közvetítő meghibásodik, ami a C sor meghiúsulását okozza
A következő Broker 1 esik! Már csak egy brókerünk maradt. A „B” sor tükör mesterré lépteti elő.
Fig. 5
Visszaküldtük a Broker 1-et. Függetlenül attól, hogy az adatok mennyire túlélik a közvetítő elvesztését és helyreállítását, újraindításkor minden tükrözött sorüzenet elvész. Ezt fontos megjegyezni, mert ennek következményei lesznek. Hamarosan megvizsgáljuk ezeket a következményeket. Így a Broker 1 ismét a fürt tagja, és a klaszter megpróbál megfelelni az irányelveknek, és ezért tükröket hoz létre a Broker 1-en.
Ebben az esetben a Bróker 1 elvesztése teljes volt, ahogy az adatok is, így a tükrözetlen B sor teljesen elveszett.
Rizs. 6. Az 1. közvetítő visszatér a szolgáltatásba
A Broker 3 újra elérhető, így az A és B sorok visszakapják a rajta létrehozott tükröket, hogy megfeleljenek a HA szabályzataiknak. De most az összes fő sor egy csomóponton van! Ez nem ideális, a csomópontok közötti egyenletes eloszlás jobb. Sajnos itt nincs sok lehetőség a mesterek újraegyensúlyozására. Később visszatérünk erre a problémára, mert először meg kell vizsgálnunk a sorszinkronizálást.
Rizs. 7. A 3. közvetítő visszatér a szolgáltatásba. Minden fő sor egy csomóponton!
Tehát most már van egy elképzelése arról, hogy a tükrök hogyan biztosítanak redundanciát és hibatűrést. Ez biztosítja a rendelkezésre állást egyetlen csomópont meghibásodása esetén, és védelmet nyújt az adatvesztés ellen. De még nem végeztünk, mert a valóságban ez sokkal bonyolultabb.
összehangolás
Új tükör létrehozásakor minden új üzenet mindig replikálódik erre a tükörre és a többire. Ami a fő sorban lévő meglévő adatokat illeti, replikálhatjuk egy új tükörbe, amely a mester teljes másolata lesz. Dönthetünk úgy is, hogy nem replikáljuk a meglévő üzeneteket, és hagyjuk, hogy a fő sor és az új tükör időben konvergáljon, az új üzenetek a végére érkezzenek, a meglévő üzenetek pedig elhagyják a fő sor fejét.
Ezt a szinkronizálást automatikusan vagy manuálisan hajtják végre, és egy sorházirend segítségével kezelik. Nézzünk egy példát.
Két tükrözött sorunk van. Az A sor automatikusan, a B pedig manuálisan szinkronizálódik. Mindkét sor tíz üzenetet tartalmaz.
Rizs. 8. Két sor különböző szinkronizálási módokkal
Most elveszítjük a Broker 3-at.
Rizs. 9. Bróker 3 esett
A 3. bróker visszatér a szolgáltatásba. A fürt minden egyes sorhoz tükröt hoz létre az új csomóponton, és automatikusan szinkronizálja az új A sort a mesterrel. Az új B sor tükre azonban üres marad. Így teljes redundanciánk van az A soron, és csak egy tükör van a meglévő B sor üzenetekhez.
Rizs. 10. Az A sor új tükre megkapja az összes létező üzenetet, de a B sor új tükre nem.
Tíz további üzenet érkezik mindkét sorba. A Broker 2 ezután összeomlik, és az A sor visszagördül a legrégebbi tükörhöz, amely a Broker 1-en található. Nincs adatvesztés, ha meghiúsul. A B sorban húsz üzenet van a főben, és csak tíz a tükörben, mivel ez a sor soha nem replikálta az eredeti tíz üzenetet.
Rizs. 11. Az A sor az üzenetek elvesztése nélkül visszaáll az 1. közvetítőhöz
Tíz további üzenet érkezik mindkét sorba. Most a Broker 1 összeomlik. Az A sor könnyen átvált a tükörre, üzenetek elvesztése nélkül. Azonban a B sornál problémák vannak. Ezen a ponton optimalizálhatjuk a rendelkezésre állást vagy a konzisztenciát.
Ha optimalizálni akarjuk az akadálymentesítést, akkor a házirend ha-promote-on-kudarc be kell telepíteni mindig. Ez az alapértelmezett érték, így egyszerűen nem adhatja meg a házirendet. Ebben az esetben lényegében megengedjük a nem szinkronizált tükrök meghibásodását. Ezzel az üzenetek elvesznek, de a sor olvasható és írható marad.
Rizs. 12. Az A sor visszakerül a 3. közvetítőhöz, üzenetek elvesztése nélkül. A B sor tíz elveszett üzenettel tér vissza a 3. közvetítőhöz
Telepíteni is tudjuk ha-promote-on-failure jelentésbe when-synced. Ebben az esetben ahelyett, hogy visszafordulna a tükörbe, a sor megvárja, amíg a Broker 1 az adataival vissza nem tér online módba. Miután visszatért, a fő sor adatvesztés nélkül visszakerül a Broker 1-be. A rendelkezésre állást feláldozzák az adatbiztonság érdekében. De ez egy kockázatos mód, amely akár teljes adatvesztéshez is vezethet, amit hamarosan megvizsgálunk.
Rizs. 13. A B sor elérhetetlen marad az 1. közvetítő elvesztése után
Felteheti a kérdést: „Jobb, ha soha nem használunk automatikus szinkronizálást?” A válasz az, hogy a szinkronizálás blokkoló művelet. A szinkronizálás során a fősor nem tud semmilyen olvasási vagy írási műveletet végrehajtani!
Nézzünk egy példát. Most nagyon hosszúak a sorok. Hogy tudnak ekkora méretűre nőni? Számos ok miatt:
- A sorokat nem használják aktívan
- Ezek nagy sebességű sorok, és jelenleg a fogyasztók lassúak
- Nagy sebességű sorok vannak, hiba történt, és a fogyasztók felzárkóznak
Rizs. 14. Két nagy sor különböző szinkronizálási módokkal
Most a Bróker 3 esik.
Rizs. 15. A 3. bróker elesik, így minden sorban egy master és egy tükör marad
A Broker 3 újra elérhető, és új tükrök jönnek létre. Az A fő sor megkezdi a meglévő üzenetek replikálását az új tükörbe, és ezalatt a sor nem érhető el. Az adatok replikálása két órát vesz igénybe, ami két órányi leállást eredményez ennél a sornál!
A B sor azonban a teljes időszak alatt elérhető marad. Feláldozott némi redundanciát a hozzáférhetőségért.
Rizs. 16. A várólista nem elérhető a szinkronizálás alatt
Két óra elteltével az A sor is elérhetővé válik, és újra elkezdheti az olvasási és írási fogadást.
frissítése
Ez a blokkoló viselkedés a szinkronizálás során megnehezíti a nagyon nagy várólistákkal rendelkező fürtök frissítését. Egy ponton a főcsomópontot újra kell indítani, ami azt jelenti, hogy tükörre kell váltani, vagy le kell tiltani a várólista a kiszolgáló frissítése közben. Ha az átállást választjuk, elveszítjük az üzeneteket, ha a tükrök nincsenek szinkronizálva. Alapértelmezés szerint a közvetítő kimaradása során nem történik feladatátvétel egy nem szinkronizált tükörre. Ez azt jelenti, hogy amint a bróker visszatér, nem veszítünk el egyetlen üzenetet sem, az egyetlen kárt egy egyszerű sor okozta. A bróker megszakítására vonatkozó viselkedési szabályokat szabályzat határozza meg ha-promote-on-shutdown. Két érték egyikét állíthatja be:
always= áttérés a nem szinkronizált tükrökre engedélyezettwhen-synced= csak szinkronizált tükörre való áttérés, ellenkező esetben a sor olvashatatlanná és írhatatlanná válik. A közvetítő visszatérésekor a sor visszatér a szolgáltatáshoz
Így vagy úgy, nagy sorok esetén választania kell az adatvesztés és az elérhetetlenség között.
Amikor az elérhetőség javítja az adatbiztonságot
Van még egy bonyodalom, amelyet figyelembe kell venni a döntés meghozatala előtt. Noha az automatikus szinkronizálás jobb a redundancia szempontjából, hogyan befolyásolja az adatbiztonságot? Természetesen jobb redundanciával a RabbitMQ kisebb valószínűséggel veszíti el a meglévő üzeneteket, de mi a helyzet a kiadóktól érkező új üzenetekkel?
Itt a következőket kell figyelembe venni:
- Lehetséges, hogy a kiadó egyszerűen hibaüzenetet küld, és megkérheti az upstream szolgáltatást vagy a felhasználót, hogy próbálkozzon újra később?
- Mentheti-e a kiadó az üzenetet helyileg vagy adatbázisba, hogy később újra próbálkozzon?
Ha a kiadó csak elvetheti az üzenetet, akkor valójában az akadálymentesítés javítása az adatbiztonságot is javítja.
Így egyensúlyt kell keresni, a megoldás pedig az adott helyzettől függ.
Problémák a ha-promote-on-failure=when-synced
Ötlet ha-promote-on-kudarc= mikor-szinkronizálva az, hogy megakadályozzuk a nem szinkronizált tükörre való váltást, és ezzel elkerüljük az adatvesztést. A sor olvashatatlan vagy írható marad. Ehelyett megpróbáljuk visszaállítani az összeomlott közvetítőt sértetlen adatokkal, hogy adatvesztés nélkül folytathassa mesterként való működését.
De (és ez egy nagy de) ha a bróker elvesztette az adatait, akkor van egy nagy problémánk: a sor elveszett! Minden adat eltűnt! Még akkor is, ha vannak olyan tükrei, amelyek többnyire utolérik a fő sort, ezeket a tükröket is eldobjuk.
Az azonos nevű csomópont újbóli hozzáadásához azt mondjuk a fürtnek, hogy felejtse el az elveszett csomópontot (a paranccsal rabbitmqctl Forget_cluster_node), és indítson új brókert ugyanazzal a gazdagépnévvel. Míg a fürt emlékszik az elveszett csomópontra, emlékszik a régi sorra és a nem szinkronizált tükrökre. Amikor egy fürtnek azt mondják, hogy felejtsen el egy árva csomópontot, akkor ez a sor is elfelejtődik. Most újra ki kell jelentenünk. Minden adatot elvesztettünk, bár voltak tükreink egy részleges adatkészlettel. Jobb lenne nem szinkron tükörre váltani!
Ezért a kézi szinkronizálás (és a szinkronizálás sikertelensége) együtt ha-promote-on-failure=when-synced, szerintem elég kockázatos. A dokumentumok szerint ez a lehetőség adatbiztonsági szempontból létezik, de ez egy kétélű kés.
Mester kiegyensúlyozás
Ahogy ígértük, visszatérünk az összes mester egy vagy több csomóponton történő felhalmozódásának problémájához. Ez akár egy gördülő fürtfrissítés eredményeként is megtörténhet. Egy három csomópontból álló fürtben az összes fősor egy vagy két csomóponton halmozódik fel.
A mesterek kiegyensúlyozása két okból is problémás lehet:
- Nincsenek jó eszközök az egyensúly helyreállítására
- Sorszinkronizálás
Van egy harmadik fél az egyensúly helyreállításához , amely hivatalosan nem támogatott. A harmadik féltől származó beépülő modulokkal kapcsolatban a RabbitMQ kézikönyvben : „A beépülő modul további konfigurációs és jelentéskészítő eszközöket biztosít, de a RabbitMQ csapata nem támogatja és nem ellenőrzi. Használat csak saját felelősségre."
Van egy másik trükk a fő várólista mozgatására a HA házirendeken keresztül. A kézikönyv említi ezért. Ez így működik:
- Eltávolítja az összes tükröt olyan ideiglenes házirend használatával, amely magasabb prioritású, mint a meglévő HA-házirend.
- Módosítja a HA ideiglenes házirendjét csomópont mód használatára, megadva azt a csomópontot, amelyre a fősort át kell vinni.
- Szinkronizálja a leküldéses áttelepítési sort.
- Az áttelepítés befejezése után törli az ideiglenes házirendet. A kezdeti HA házirend hatályba lép, és létrejön a szükséges számú tükör.
Hátránya, hogy ez a megközelítés nem biztos, hogy működik, ha nagy sorok vagy szigorú redundanciakövetelmények vannak.
Most nézzük meg, hogyan működnek a RabbitMQ-fürtök hálózati partíciókkal.
Kapcsolat elvesztése
Az elosztott rendszer csomópontjait hálózati kapcsolatok kötik össze, és a hálózati kapcsolatok leválaszthatók, és le is fognak kapcsolódni. A kimaradások gyakorisága a helyi infrastruktúrától vagy a kiválasztott felhő megbízhatóságától függ. Az elosztott rendszereknek mindenesetre meg kell birkózni velük. Ismét választhatunk a rendelkezésre állás és a következetesség között, és ismét a jó hír az, hogy a RabbitMQ mindkét lehetőséget kínálja (csak nem egyszerre).
A RabbitMQ-val két fő lehetőségünk van:
- Logikai felosztás engedélyezése (split-brain). Ez biztosítja az elérhetőséget, de adatvesztést okozhat.
- Logikai elválasztás letiltása. Az elérhetőség rövid távú elvesztését eredményezheti attól függően, hogy az ügyfelek hogyan csatlakoznak a fürthöz. Teljes elérhetetlenséghez is vezethet egy két csomópontos fürtben.
De mi a logikai szétválasztás? Ilyenkor egy fürt ketté válik a hálózati kapcsolatok megszakadása miatt. Mindkét oldalon a tükrök egy-egy mesterré léptetnek elő, így végül több mester kerül soronként.
Rizs. 17. Fősor és két tükör, mindegyik külön csomóponton. Ekkor hálózati hiba lép fel, és az egyik tükör leválik. Az elválasztott csomópont látja, hogy a másik kettő leesett, és előlépteti tükréit a mesternek. Most két fő sor áll rendelkezésünkre, mind az írható, mind az olvasható.
Ha a kiadók adatokat küldenek mindkét mesternek, akkor a várólista két eltérő másolatot kapunk.
A RabbitMQ különböző üzemmódjai elérhetőséget vagy konzisztenciát biztosítanak.
Figyelmen kívül hagyási mód (alapértelmezett)
Ez a mód biztosítja a hozzáférhetőséget. A kapcsolat megszűnése után logikai szétválás következik be. A kapcsolat helyreállítása után az adminisztrátornak el kell döntenie, hogy melyik partíciót részesítse előnyben. A vesztes oldal újraindul, és az azon az oldalon felhalmozott összes adat elveszik.
Rizs. 18. Három kiadó három közvetítőhöz kapcsolódik. Belsőleg a fürt az összes kérést a Broker 2 fő sorába irányítja.
Most elveszítjük a Bróker 3-at. Látja, hogy más brókerek lebuktak, és előlépteti a tükrét a mesterré. Így jön létre a logikai elválasztás.
Rizs. 19. Logikai felosztás (split-brain). A rekordok két fő sorba kerülnek, és a két példány eltér egymástól.
A kapcsolat helyreáll, de a logikai elválasztás megmarad. A rendszergazdának kézzel kell kiválasztania a vesztes oldalt. Az alábbi esetben a rendszergazda újraindítja a Broker 3-at. Minden olyan üzenet elveszik, amelyet nem sikerült továbbítania.
Rizs. 20. Az adminisztrátor letiltja a Broker 3-at.
Rizs. 21. Az adminisztrátor elindítja a Broker 3-at, és az csatlakozik a fürthöz, és elveszíti az ott hagyott összes üzenetet.
A kapcsolat megszakadása alatt és a helyreállítás után a fürt és ez a sor olvasható és írható volt.
Autoheal mód
Az Ignore módhoz hasonlóan működik, azzal a különbséggel, hogy a fürt automatikusan kiválasztja a vesztes oldalt a kapcsolat felosztása és visszaállítása után. A vesztes oldal üresen tér vissza a fürthöz, és a sor elveszti az összes üzenetet, amelyet csak arra az oldalra küldtek.
Kisebbségi mód szüneteltetése
Ha nem akarjuk engedélyezni a logikai particionálást, akkor az egyetlen lehetőségünk az, hogy a fürtpartíció utáni kisebb oldalon elvetjük az olvasást és az írást. Amikor a bróker látja, hogy a kisebbik oldalon van, felfüggeszti a munkát, vagyis minden meglévő kapcsolatot lezár, és visszautasít minden újat. Másodpercenként egyszer ellenőrzi a kapcsolat helyreállítását. A kapcsolat helyreállítása után folytatja a működést, és csatlakozik a fürthöz.
Rizs. 22. Három kiadó három közvetítőhöz kapcsolódik. Belsőleg a fürt az összes kérést a Broker 2 fő sorába irányítja.
Az 1. és 2. bróker ezután kivált a 3. brókerből. Ahelyett, hogy tükrét mesterré emelné, a Broker 3 felfüggeszti, és elérhetetlenné válik.
Rizs. 23. A Broker 3 szünetelteti, leválasztja az összes klienst, és elutasítja a csatlakozási kérelmeket.
A kapcsolat helyreállítása után visszatér a fürthöz.
Nézzünk egy másik példát, ahol a fő sor a Broker 3-on van.
Rizs. 24. Fő sor a Broker 3-on.
Ekkor ugyanaz a kapcsolatvesztés következik be. A 3. bróker szünetel, mert a kisebbik oldalon van. A másik oldalon a csomópontok látják, hogy a Broker 3 leesett, így a Brokers 1 és 2 régebbi tükrét adják elő masterré.
Rizs. 25. Áttérés a Broker 2-re, ha a Broker 3 nem érhető el.
Amikor a kapcsolat helyreáll, a Broker 3 csatlakozik a fürthöz.
Rizs. 26. A fürt visszatért a normál működéshez.
Itt fontos megérteni, hogy konzisztenciát kapunk, de elérhetőséget is kaphatunk, ha Sikeresen áthelyezzük az ügyfeleket a részleg nagy részére. A legtöbb helyzetben én személy szerint a Pause Minority módot választanám, de ez valóban az egyedi esettől függ.
Az elérhetőség biztosítása érdekében fontos annak biztosítása, hogy az ügyfelek sikeresen csatlakozzanak a gazdagéphez. Nézzük a lehetőségeinket.
Ügyfélkapcsolat biztosítása
Számos lehetőségünk van arra, hogyan irányítsuk a klienseket a fürt fő részéhez vagy a működő csomópontokhoz (egy csomópont meghibásodása után) a kapcsolat elvesztése után. Először is ne feledjük, hogy egy adott sor egy adott csomóponton található, de az útválasztás és a házirendek replikálódnak az összes csomóponton. Az ügyfelek bármely csomóponthoz csatlakozhatnak, és a belső útválasztás oda irányítja őket, ahová kell menniük. De amikor egy csomópont felfüggesztésre kerül, az elutasítja a kapcsolatokat, így az ügyfeleknek egy másik csomóponthoz kell csatlakozniuk. Ha a csomópont leesik, keveset tehet.
Lehetőségeink:
- A fürt egy terheléselosztó segítségével érhető el, amely egyszerűen végighalad a csomópontokon, és az ügyfelek újra próbálkoznak a csatlakozással, amíg sikerrel nem járnak. Ha egy csomópont nem működik vagy fel van függesztve, akkor az ahhoz a csomóponthoz való csatlakozási kísérletek sikertelenek lesznek, de a további próbálkozások más szerverekre mennek (körbefutó módon). Ez alkalmas a kapcsolat rövid távú megszakadására vagy a szerver leállására, amelyet gyorsan vissza lehet állítani.
- Hozzáférés a fürthöz egy terheléselosztón keresztül, és azonnal távolítsa el a felfüggesztett/meghibásodott csomópontokat a listáról, amint észlelik. Ha ezt gyorsan megtesszük, és a kliensek újra meg tudják próbálni a kapcsolatot, akkor állandó rendelkezésre állást érünk el.
- Adjon minden kliensnek egy listát az összes csomópontról, és az ügyfél véletlenszerűen kiválaszt egyet a csatlakozás során. Ha hibaüzenetet kap a csatlakozási kísérlet során, a lista következő csomópontjára lép, amíg nem csatlakozik.
- Távolítsa el a forgalmat egy meghibásodott/felfüggesztett csomópontról DNS segítségével. Ez egy kis TTL segítségével történik.
Álláspontja
A RabbitMQ klaszterezésnek megvannak az előnyei és hátrányai. A legsúlyosabb hátrányok a következők:
- a fürthöz való csatlakozáskor a csomópontok elvetik az adataikat;
- a szinkronizálás blokkolása miatt a sor elérhetetlenné válik.
Minden nehéz döntés ebből a két építészeti jellemzőből fakad. Ha a RabbitMQ el tudja menteni az adatokat a fürt újracsatlakozásakor, akkor a szinkronizálás gyorsabb lenne. Ha képes lenne nem blokkoló szinkronizálásra, akkor jobban támogatná a nagy sorokat. E két probléma kijavítása nagymértékben javítaná a RabbitMQ teljesítményét, mint hibatűrő és rendkívül elérhető üzenetküldő technológia. Haboznék ajánlani a RabbitMQ-t fürtözéssel a következő helyzetekben:
- Megbízhatatlan hálózat.
- Megbízhatatlan tárolás.
- Nagyon hosszú sorok.
Ha magas rendelkezésre állási beállításokról van szó, vegye figyelembe a következőket:
ha-promote-on-failure=alwaysha-sync-mode=manualcluster_partition_handling=ignore(vagyautoheal)- kitartó üzenetek
- biztosítsa, hogy az ügyfelek csatlakozzanak az aktív csomóponthoz, ha valamelyik csomópont meghibásodik
A következetesség (adatbiztonság) érdekében vegye figyelembe a következő beállításokat:
- A kiadói visszaigazolások és kézi elismerések a fogyasztói oldalon
ha-promote-on-failure=when-synced, ha a kiadók később újra próbálkozhatnak, és ha nagyon megbízható tárhelyed van! Ellenkező esetben fel=always.ha-sync-mode=automatic(de nagy inaktív sorok esetén kézi üzemmódra lehet szükség; mérlegelje azt is, hogy az elérhetetlenség nem okoz-e üzenetek elvesztését)- Kisebbségi mód szüneteltetése
- kitartó üzenetek
Még nem foglalkoztunk a hibatűrés és a magas rendelkezésre állás minden kérdésével; például az adminisztrációs eljárások (például a folyamatos frissítések) biztonságos végrehajtása. Szólnunk kell a föderációról és a Shovel bővítményről is.
Ha még valamit kihagytam, kérlek jelezd.
Lásd még az enyémet , ahol a Docker és a Blockade segítségével pusztítást hajtok végre egy RabbitMQ-fürtön, hogy teszteljek néhány, ebben a cikkben leírt üzenetvesztési forgatókönyvet.
A sorozat korábbi cikkei:
1. sz. -
2. sz. -
3. sz. -
Forrás: will.com