Gedimų tolerancija ir didelis prieinamumas yra didelės temos, todėl RabbitMQ ir Kafka skirsime atskirus straipsnius. Šis straipsnis yra apie RabbitMQ, o kitas - apie Kafką, palyginti su RabbitMQ. Tai ilgas straipsnis, todėl jauskitės patogiai.

Pažvelkime į atsparumo gedimams, nuoseklumo ir didelio prieinamumo (HA) strategijas ir kiekvienos strategijos kompromisus. RabbitMQ gali veikti mazgų klasteryje ir tada klasifikuojamas kaip paskirstyta sistema. Kalbant apie paskirstytas sistemas, dažnai kalbame apie nuoseklumą ir prieinamumą.

Šios sąvokos apibūdina, kaip sistema elgiasi sugedus. Tinklo ryšio gedimas, serverio gedimas, standžiojo disko gedimas, laikinas serverio nepasiekiamumas dėl šiukšlių surinkimo, paketų praradimas arba tinklo ryšio sulėtėjimas. Visa tai gali sukelti duomenų praradimą arba konfliktus. Pasirodo, praktiškai neįmanoma sukurti sistemos, kuri būtų visiškai nuosekli (neprarastų duomenų, nebūtų skirtumų) ir būtų prieinama (priimtų skaitymus ir įrašus) visiems gedimų scenarijams.

Pamatysime, kad nuoseklumas ir prieinamumas yra priešinguose spektro kraštuose, ir jūs turite pasirinkti optimizavimo būdą. Geros naujienos yra tai, kad naudojant RabbitMQ šis pasirinkimas yra įmanomas. Turite tokius „nerdy“ svertus, kad perkeltumėte pusiausvyrą į didesnį nuoseklumą arba didesnį prieinamumą.

Ypatingą dėmesį skirsime tam, kurios konfigūracijos lemia duomenų praradimą dėl patvirtintų įrašų. Yra atsakomybės grandinė tarp leidėjų, tarpininkų ir vartotojų. Kai pranešimas perduodamas brokeriui, jo darbas yra neprarasti pranešimo. Kai tarpininkas patvirtina, kad leidėjas gavo pranešimą, mes nesitikime, kad jis bus prarastas. Tačiau pamatysime, kad tai iš tikrųjų gali nutikti priklausomai nuo jūsų tarpininko ir leidėjo konfigūracijos.

Vieno mazgo atsparumo primityvai

Atsparus eilių / maršruto parinkimas

„RabbitMQ“ yra dviejų tipų eilės: patvarios ir netvarios. Visos eilės išsaugomos Mnesia duomenų bazėje. Ilgalaikės eilės iš naujo reklamuojamos paleidžiant mazgą, todėl jos išgyvena paleidus iš naujo, įvykus sistemos gedimams ar serverio gedimams (tol, kol duomenys išlieka). Tai reiškia, kad tol, kol paskelbsite, kad maršrutas (keitimasis) ir eilė yra atsparūs, eilių / maršruto parinkimo infrastruktūra vėl veiks.

Nepastovios eilės ir maršruto parinkimas pašalinami, kai mazgas paleidžiamas iš naujo.

Nuolatiniai pranešimai

Vien todėl, kad eilė yra patvari, dar nereiškia, kad visi jos pranešimai išliks paleidus mazgą iš naujo. Tik pranešimai, kuriuos leidėjas nustatė kaip atsparus (patvarus). Nuolatiniai pranešimai sukuria papildomą apkrovą tarpininkui, tačiau jei pranešimų praradimas yra nepriimtinas, tada nėra kitos išeities.

Ryžiai. 1. Tvarumo matrica

Klasterizavimas su eilių atspindėjimu

Norint išgyventi praradus brokerį, mums reikia atleidimo. Galime sujungti kelis RabbitMQ mazgus į klasterį, o tada pridėti papildomo dubliavimo, pakartodami eiles tarp kelių mazgų. Tokiu būdu, sugedus vienam mazgui, neprarandame duomenų ir liekame pasiekiami.

Eilės atspindėjimas:

• viena pagrindinė eilė (master), kuri gauna visas rašymo ir skaitymo komandas
• vienas ar daugiau veidrodžių, kurie gauna visus pranešimus ir metaduomenis iš pagrindinės eilės. Šie veidrodžiai skirti ne mastelio keitimui, o tik pertekliui.

Ryžiai. 2. Eilių atspindėjimas

Dubliavimas nustatomas pagal atitinkamą politiką. Jame galite pasirinkti replikacijos koeficientą ir net mazgus, kuriuose turėtų būti eilė. Pavyzdžiai:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (vienas meistras ir vienas veidrodis)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Leidėjo patvirtinimas

Norint užtikrinti nuoseklų įrašymą, reikalingi leidėjo patvirtinimai. Be jų kyla pavojus, kad pranešimai bus prarasti. Patvirtinimas siunčiamas leidėjui po to, kai pranešimas įrašomas į diską. RabbitMQ rašo pranešimus į diską ne gavęs, o periodiškai, kelių šimtų milisekundžių srityje. Kai eilė atspindima, patvirtinimas siunčiamas tik tada, kai visi veidrodžiai taip pat įrašo pranešimo kopiją į diską. Tai reiškia, kad patvirtinimų naudojimas padidina delsą, tačiau jei duomenų saugumas yra svarbus, tada jie yra būtini.

Perdavimo eilė

Kai brokeris pasitraukia arba sugenda, visi to mazgo eilės lyderiai (šeimininkai) sugenda kartu su juo. Tada grupė pasirenka seniausią kiekvieno meistro veidrodį ir reklamuoja jį kaip naująjį.

Ryžiai. 3. Kelios veidrodinės eilės ir jų taisyklės

Brokeris 3 krenta. Atminkite, kad „Broker 2“ eilės C veidrodis yra paaukštintas kaip pagrindinis. Taip pat atminkite, kad buvo sukurtas naujas veidrodis C eilei tarpininke 1. RabbitMQ visada bando išlaikyti jūsų strategijose nurodytą replikacijos faktorių.

Ryžiai. 4. 3 tarpininkas sugenda, todėl C eilė sugenda

Kitas brokeris 1 patenka! Turime tik vieną brokerį. Eilės B veidrodis paaukštintas į meistrą.

Pav. 5

Grąžinome 1 tarpininką. Nepriklausomai nuo to, ar duomenys išgyvena po tarpininko praradimo ir atkūrimo, visi atspindėti eilės pranešimai atmetami iš naujo. Tai svarbu atkreipti dėmesį, nes tai turės pasekmių. Netrukus pažvelgsime į šias pasekmes. Taigi „Broker 1“ dabar vėl yra klasterio narys, o klasteris bando laikytis politikos, todėl sukuria „Broker 1“ veidrodžius.

Šiuo atveju brokerio 1 praradimas buvo visiškas, kaip ir duomenys, todėl neatvaizduota eilė B buvo visiškai prarasta.

Ryžiai. 6. 1 brokeris grįžta į tarnybą

„Broker 3“ vėl prisijungė, todėl A ir B eilės grąžina jame sukurtus veidrodžius, kad atitiktų jų HA politiką. Bet dabar visos pagrindinės eilės yra viename mazge! Tai nėra idealu, tolygus pasiskirstymas tarp mazgų yra geresnis. Deja, čia nėra daug galimybių meistrams perbalansuoti. Prie šios problemos grįšime vėliau, nes pirmiausia turime pažvelgti į eilės sinchronizavimą.

Ryžiai. 7. Brokeris 3 grįžta į tarnybą. Visos pagrindinės eilės viename mazge!

Taigi dabar turėtumėte suprasti, kaip veidrodžiai užtikrina dubliavimą ir atsparumą gedimams. Tai užtikrina prieinamumą vieno mazgo gedimo atveju ir apsaugo nuo duomenų praradimo. Bet mes dar nebaigėme, nes iš tikrųjų viskas yra daug sudėtingiau.

sinchronizavimas

Kuriant naują veidrodį, visi nauji pranešimai visada bus kopijuojami į šį veidrodį ir kitus. Kalbant apie esamus duomenis pagrindinėje eilėje, galime juos kopijuoti į naują veidrodį, kuris tampa visa pagrindinės eilės kopija. Taip pat galime pasirinkti nekartoti esamų pranešimų ir leisti pagrindinei eilei ir naujam veidrodžiui susilieti laiku, kai nauji pranešimai patenka į galą, o esami pranešimai palieka pagrindinės eilės viršūnę.

Šis sinchronizavimas atliekamas automatiškai arba rankiniu būdu ir valdomas naudojant eilės politiką. Pažiūrėkime į pavyzdį.

Turime dvi veidrodines eiles. Eilė A sinchronizuojama automatiškai, o eilė B sinchronizuojama rankiniu būdu. Abiejose eilėse yra dešimt pranešimų.

Ryžiai. 8. Dvi eilės su skirtingais sinchronizacijos režimais

Dabar mes prarandame Brokerį 3.

Ryžiai. 9. Brokeris 3 krito

3 brokeris grįžta į paslaugą. Klasteris sukuria veidrodį kiekvienai eilei naujame mazge ir automatiškai sinchronizuoja naują eilę A su pagrindiniu. Tačiau naujosios eilės B veidrodis lieka tuščias. Tokiu būdu turime visą A eilės dubliavimą ir tik vieną veidrodį esamiems B eilės pranešimams.

Ryžiai. 10. Naujasis A eilės veidrodis gauna visus esamus pranešimus, bet naujasis eilės B veidrodis negauna.

Abiejose eilėse ateina dar dešimt pranešimų. Tada „Broker 2“ sugenda ir A eilė grįžta į seniausią veidrodį, kuris yra „Broker 1“. Sugedus duomenų neprarandama. B eilėje pagrindiniame kompiuteryje yra dvidešimt pranešimų, o veidrodyje - tik dešimt, nes ši eilė niekada nepakartojo pirminių dešimties pranešimų.

Ryžiai. 11. A eilė grįžta į 1 tarpininką neprarandant pranešimų

Abiejose eilėse ateina dar dešimt pranešimų. Dabar „Broker 1“ sugenda A eilė lengvai persijungia į veidrodį neprarasdama pranešimų. Tačiau B eilė turi problemų. Šiuo metu galime optimizuoti prieinamumą arba nuoseklumą.

Jei norime optimizuoti prieinamumą, tai politika ha-promote-on-gedimas turėtų būti įdiegta visada. Tai yra numatytoji reikšmė, todėl galite tiesiog visai nenurodyti politikos. Šiuo atveju iš esmės leidžiame nesinchronizuotų veidrodžių gedimus. Dėl to pranešimai bus prarasti, tačiau eilė išliks skaitoma ir įrašoma.

Ryžiai. 12. A eilė grąžinama į Broker 3 neprarandant pranešimų. B eilė grįžta į tarpininką 3, kai prarandama dešimt pranešimų

Galime ir sumontuoti ha-promote-on-failure į prasmę when-synced. Tokiu atveju, užuot grįžusi į veidrodį, eilė lauks, kol Broker 1 su savo duomenimis grįš į internetinį režimą. Jai grįžus, pagrindinė eilė grįžta į „Broker 1“ neprarandant duomenų. Prieinamumas paaukotas dėl duomenų saugumo. Tačiau tai yra rizikingas režimas, dėl kurio netgi gali būti visiškai prarasti duomenys, kurį netrukus panagrinėsime.

Ryžiai. 13. Praradus 1 tarpininką, eilė B lieka nepasiekiama

Galite paklausti: „Ar geriau niekada nenaudoti automatinio sinchronizavimo? Atsakymas yra tas, kad sinchronizavimas yra blokavimo operacija. Sinchronizavimo metu pagrindinė eilė negali atlikti jokių skaitymo ar rašymo operacijų!

Pažiūrėkime į pavyzdį. Dabar pas mus labai ilgos eilės. Kaip jie gali užaugti iki tokio dydžio? Dėl kelių priežasčių:

• Eilės aktyviai nenaudojamos
• Tai didelės eilės, o šiuo metu vartotojai yra lėti
• Tai didelės eilės, įvyko gedimas ir vartotojai vejasi

Ryžiai. 14. Dvi didelės eilės su skirtingais sinchronizacijos režimais

Dabar brokeris 3 krenta.

Ryžiai. 15. Brokeris 3 krenta, palikdamas po vieną meistrą ir veidrodį kiekvienoje eilėje

Broker 3 grįžta į internetą ir sukuriami nauji veidrodžiai. Pagrindinė eilė A pradeda kopijuoti esamus pranešimus į naują veidrodį, o tuo metu eilė nepasiekiama. Duomenims kopijuoti reikia dviejų valandų, todėl šios eilės prastovos trunka dvi valandas!

Tačiau eilė B išlieka prieinama visą laikotarpį. Dėl prieinamumo ji paaukojo šiek tiek pertekliaus.

Ryžiai. 16. Sinchronizacijos metu eilė nepasiekiama

Po dviejų valandų A eilė taip pat tampa prieinama ir gali vėl pradėti skaityti ir rašyti.

Atnaujinimai

Dėl šio blokavimo sinchronizavimo metu sunku atnaujinti grupes su labai didelėmis eilėmis. Tam tikru momentu pagrindinį mazgą reikia paleisti iš naujo, o tai reiškia, kad reikia perjungti į veidrodį arba išjungti eilę, kol serveris atnaujinamas. Jei pasirinksime perėjimą, prarasime pranešimus, jei veidrodžiai nebus sinchronizuoti. Pagal numatytuosius nustatymus tarpininko gedimo metu perjungimas į nesinchronizuotą veidrodį neatliekamas. Tai reiškia, kad kai tik brokeris grįžta, mes neprarandame jokių pranešimų, vienintelė žala buvo paprasta eilė. Elgesio taisyklės, kai brokeris atjungiamas, nustatomos politikoje ha-promote-on-shutdown. Galite nustatyti vieną iš dviejų reikšmių:

• always= įjungtas perėjimas prie nesinchronizuotų veidrodžių
• when-synced= tik perėjimas prie sinchronizuoto veidrodžio, kitaip eilė taps neįskaitoma ir neįrašoma. Eilė grįžta į paslaugą, kai tik grįžta brokeris

Vienaip ar kitaip, esant didelėms eilėms, tenka rinktis tarp duomenų praradimo ir nepasiekiamumo.

Kai pasiekiamumas pagerina duomenų saugumą

Yra dar viena komplikacija, kurią reikia apsvarstyti prieš priimant sprendimą. Nors automatinis sinchronizavimas yra geresnis atleidimo iš darbo atveju, kaip tai paveikia duomenų saugumą? Žinoma, esant geresniam atleidimui, RabbitMQ mažesnė tikimybė prarasti esamus pranešimus, bet kaip dėl naujų leidėjų pranešimų?

Čia reikia atsižvelgti į šiuos dalykus:

• Ar leidėjas galėtų tiesiog grąžinti klaidą, o ankstesnė paslauga ar naudotojas vėliau bandytų dar kartą?
• Ar leidėjas gali išsaugoti pranešimą vietoje arba duomenų bazėje, kad vėliau bandytų dar kartą?

Jei leidėjas gali tik atmesti pranešimą, iš tikrųjų pagerinus pasiekiamumą pagerėja ir duomenų saugumas.

Taigi reikia ieškoti balanso, o sprendimas priklauso nuo konkrečios situacijos.

Problemos su ha-promote-on-failure=when-synced

Idėja ha-promote-on-gedimas= kai sinchronizuojama yra tai, kad neleidžiame perjungti į nesinchronizuotą veidrodį ir taip išvengiame duomenų praradimo. Eilė lieka neįskaitoma arba įrašoma. Vietoj to, bandome atkurti sudužusį tarpininką su nepažeistais duomenimis, kad jis galėtų toliau veikti kaip pagrindinis neprarasdamas duomenų.

Bet (ir tai yra didelis bet), jei brokeris prarado savo duomenis, turime didelę problemą: eilė prarasta! Dingo visi duomenys! Net jei turite veidrodžių, kurie dažniausiai pasiveja pagrindinę eilę, tie veidrodžiai taip pat bus atmesti.

Norėdami iš naujo pridėti mazgą tuo pačiu pavadinimu, mes liepiame klasteriui pamiršti prarastą mazgą (su komanda rabbitmqctl pamiršti_klasterio_mazgas) ir paleiskite naują brokerį tuo pačiu pagrindinio kompiuterio pavadinimu. Nors klasteris prisimena prarastą mazgą, jis prisimena seną eilę ir nesinchronizuotus veidrodžius. Kai klasteriui nurodoma pamiršti našlaitį mazgą, ta eilė taip pat pamirštama. Dabar turime tai iš naujo paskelbti. Praradome visus duomenis, nors turėjome veidrodžius su daliniu duomenų rinkiniu. Geriau būtų pereiti prie nesinchroninio veidrodžio!

Todėl rankinis sinchronizavimas (ir nesugebėjimas sinchronizuoti) kartu su ha-promote-on-failure=when-synced, mano nuomone, gana rizikinga. Dokumentai teigia, kad ši parinktis egzistuoja siekiant užtikrinti duomenų saugumą, tačiau tai yra dviašmenis peilis.

Meistras perbalansavimas

Kaip ir buvo žadėta, grįžtame prie visų meistrų kaupimo viename ar keliuose mazguose problemos. Tai netgi gali nutikti dėl nuolatinio klasterio atnaujinimo. Trijų mazgų klasteryje visos pagrindinės eilės bus kaupiamos viename ar dviejuose mazguose.

Subalansuoti meistrai gali būti problemiški dėl dviejų priežasčių:

• Nėra gerų įrankių balansavimui atlikti
• Eilių sinchronizavimas

Subalansuoti yra trečioji šalis prijungti, kuri oficialiai nepalaikoma. Dėl trečiųjų šalių įskiepių RabbitMQ vadove sakė: „Papildinys suteikia papildomų konfigūravimo ir ataskaitų teikimo įrankių, tačiau RabbitMQ komanda jo nepalaiko ir nepatvirtina. Naudokite savo rizika."

Yra dar vienas triukas, kaip perkelti pagrindinę eilę per HA politiką. Vadove minima scenarijus už tai. Tai veikia taip:

• Pašalina visus veidrodžius naudojant laikiną politiką, kuri turi didesnį prioritetą nei esama HA politika.
• Pakeičia HA laikinąją politiką, kad būtų naudojamas mazgo režimas, nurodant mazgą, į kurį turi būti perkelta pagrindinė eilė.
• Sinchronizuoja tiesioginio perkėlimo eilę.
• Baigus perkėlimą, laikinoji politika ištrinama. Pradinė HA politika įsigalioja ir sukuriamas reikiamas veidrodžių skaičius.

Neigiama yra tai, kad šis metodas gali neveikti, jei turite didelių eilių arba griežtus atleidimo reikalavimus.

Dabar pažiūrėkime, kaip RabbitMQ klasteriai veikia su tinklo skaidiniais.

Ryšio praradimas

Paskirstytos sistemos mazgai yra sujungti tinklo nuorodomis, o tinklo nuorodos gali ir bus atjungtos. Nutraukimų dažnis priklauso nuo vietinės infrastruktūros arba pasirinkto debesies patikimumo. Bet kuriuo atveju paskirstytos sistemos turi sugebėti su jais susidoroti. Dar kartą turime pasirinkimą tarp prieinamumo ir nuoseklumo, ir vėl gera žinia ta, kad RabbitMQ siūlo abi parinktis (tik ne tuo pačiu metu).

Su RabbitMQ turime dvi pagrindines parinktis:

• Leisti loginį padalijimą (split-brain). Tai užtikrina prieinamumą, tačiau gali prarasti duomenis.
• Išjungti loginį atskyrimą. Gali sukelti trumpalaikį pasiekiamumo praradimą, atsižvelgiant į tai, kaip klientai prisijungia prie grupės. Taip pat gali būti visiškas nepasiekiamumas dviejų mazgų klasteryje.

Bet kas yra loginis atskyrimas? Tai yra tada, kai klasteris suskaidomas į dvi dalis dėl tinklo ryšių praradimo. Kiekvienoje pusėje veidrodžiai paaukštinami iki meistrų, todėl galiausiai vienoje eilėje yra keli meistrai.

Ryžiai. 17. Pagrindinė eilė ir du veidrodžiai, kiekvienas atskirame mazge. Tada įvyksta tinklo gedimas ir vienas veidrodis atsiskiria. Atskirtas mazgas mato, kad kiti du nukrito ir paaukština savo veidrodžius šeimininkui. Dabar turime dvi pagrindines eiles – ir rašomas, ir skaitomas.

Jei leidėjai siunčia duomenis abiem pagrindiniams kompiuteriams, gauname dvi skirtingas eilės kopijas.

Skirtingi RabbitMQ režimai užtikrina prieinamumą arba nuoseklumą.

Ignoravimo režimas (numatytasis)

Šis režimas užtikrina prieinamumą. Praradus ryšį, įvyksta loginis atskyrimas. Atkūrus ryšį, administratorius turi nuspręsti, kuriam skaidiniui suteikti pirmenybę. Pralaimėjusioji pusė bus paleista iš naujo ir visi toje pusėje sukaupti duomenys bus prarasti.

Ryžiai. 18. Trys leidėjai yra susiję su trimis brokeriais. Viduje klasteris nukreipia visas užklausas į pagrindinę brokerio 2 eilę.

Dabar mes prarandame Brokerį 3. Jis mato, kad kiti brokeriai nukrito ir paaukština savo veidrodį šeimininkui. Taip įvyksta loginis atskyrimas.

Ryžiai. 19. Loginis padalijimas (split-brain). Įrašai patenka į dvi pagrindines eiles, o dvi kopijos skiriasi.

Ryšys atkurtas, tačiau loginis atskyrimas išlieka. Administratorius turi rankiniu būdu pasirinkti pralaimėjusią pusę. Žemiau nurodytu atveju administratorius perkrauna Broker 3. Visi pranešimai, kurių jam nepavyko perduoti, prarandami.

Ryžiai. 20. Administratorius išjungia Broker 3.

Ryžiai. 21. Administratorius paleidžia Broker 3 ir jis prisijungia prie klasterio, prarasdamas visus ten paliktus pranešimus.

Nutrūkus ryšiui ir jį atkūrus, klasteris ir ši eilė buvo prieinami skaitymui ir rašymui.

Autoheal režimas

Veikia panašiai kaip Ignoravimo režimas, išskyrus tai, kad pati klasteris automatiškai pasirenka pralaimėjusią pusę, išskaidžius ir atkūrus ryšį. Pralaimėjusioji pusė grįžta į klasterį tuščia, o eilė praranda visus pranešimus, kurie buvo išsiųsti tik į tą pusę.

Pristabdykite mažumos režimą

Jei nenorime leisti loginio skaidymo, tada vienintelė galimybė yra atmesti skaitymus ir rašymą mažesnėje pusėje po klasterio skaidinio. Kai brokeris pamato, kad jis yra mažesnėje pusėje, jis sustabdo darbą, tai yra, uždaro visus esamus ryšius ir atsisako naujų. Kartą per sekundę tikrina, ar atkurtas ryšys. Kai ryšys atkuriamas, jis atnaujinamas ir prisijungia prie grupės.

Ryžiai. 22. Trys leidėjai yra susiję su trimis brokeriais. Viduje klasteris nukreipia visas užklausas į pagrindinę brokerio 2 eilę.

1 ir 2 brokeriai atsiskiria nuo 3 brokerio. Užuot paaukštinęs savo veidrodį į meistrą, 3 brokeris sustabdo veiklą ir tampa nepasiekiamas.

Ryžiai. 23. Brokeris 3 pristabdo, atjungia visus klientus ir atmeta prisijungimo užklausas.

Kai ryšys atkuriamas, jis grįžta į klasterį.

Pažvelkime į kitą pavyzdį, kai pagrindinė eilė yra brokeryje 3.

Ryžiai. 24. Pagrindinė brokerio 3 eilė.

Tada nutrūksta ryšys. 3 brokeris pristabdo, nes yra mažesnėje pusėje. Kitoje pusėje mazgai mato, kad Broker 3 nukrito, todėl senesnis veidrodis iš Brokers 1 ir 2 yra paaukštintas į meistrą.

Ryžiai. 25. Perėjimas prie 2 tarpininko, jei brokeris 3 nepasiekiamas.

Kai ryšys bus atkurtas, „Broker 3“ prisijungs prie klasterio.

Ryžiai. 26. Klasteris grįžo į įprastą veikimą.

Čia svarbu suprasti, kad gauname nuoseklumą, bet galime ir prieinamumą, jei Sėkmingai perkelsime klientus į didžiąją skyriaus dalį. Daugeliu atvejų aš asmeniškai rinkčiausi Pause Minority režimą, tačiau tai tikrai priklauso nuo konkretaus atvejo.

Norint užtikrinti pasiekiamumą, svarbu užtikrinti, kad klientai sėkmingai prisijungtų prie pagrindinio kompiuterio. Pažvelkime į savo galimybes.

Klientų ryšio užtikrinimas

Turime keletą variantų, kaip nukreipti klientus į pagrindinę klasterio dalį arba į veikiančius mazgus (sugedus vienam mazgui) praradus ryšį. Pirmiausia prisiminkime, kad konkreti eilė yra priglobta konkrečiame mazge, tačiau maršruto parinkimas ir strategijos yra pakartojamos visuose mazguose. Klientai gali prisijungti prie bet kurio mazgo, o vidinis maršrutas nukreips juos ten, kur reikia. Tačiau kai mazgas sustabdomas, jis atmeta ryšius, todėl klientai turi prisijungti prie kito mazgo. Jei mazgas nukrenta, jis mažai ką gali padaryti.

Mūsų parinktys:

• Klasteris pasiekiamas naudojant apkrovos balansavimo priemonę, kuri tiesiog perjungia mazgus, o klientai bando prisijungti iš naujo, kol pavyks. Jei mazgas neveikia arba laikinai sustabdytas, bandymai prisijungti prie to mazgo nepavyks, bet vėlesni bandymai bus nukreipti į kitus serverius (apvalaus veikimo būdu). Tai tinka trumpam nutrūkus ryšiui arba sugedus serveriui, kuris bus greitai atkurtas.
• Pasiekite klasterį naudodami apkrovos balansavimo priemonę ir pašalinkite sustabdytus / nepavykusius mazgus iš sąrašo, kai tik jie bus aptikti. Jei tai padarysime greitai ir jei klientai galės dar kartą bandyti prisijungti, pasieksime nuolatinį pasiekiamumą.
• Kiekvienam klientui pateikite visų mazgų sąrašą, o klientas jungdamasis atsitiktinai pasirenka vieną iš jų. Jei bandant prisijungti gauna klaidą, jis pereina į kitą sąrašo mazgą, kol prisijungs.
• Pašalinkite srautą iš nepavykusio / laikinai sustabdyto mazgo naudodami DNS. Tai atliekama naudojant mažą TTL.

išvados

RabbitMQ klasterizavimas turi savo privalumų ir trūkumų. Rimčiausi trūkumai yra šie:

• prisijungdami prie klasterio, mazgai išmeta savo duomenis;
• užblokavus sinchronizavimą, eilė tampa nepasiekiama.

Visi sunkūs sprendimai kyla dėl šių dviejų architektūrinių ypatybių. Jei RabbitMQ galėtų išsaugoti duomenis, kai klasteris vėl prisijungia, sinchronizavimas būtų greitesnis. Jei jis galėtų neblokuoti sinchronizavimo, jis geriau palaikytų dideles eiles. Išsprendus šias dvi problemas, RabbitMQ, kaip gedimams atsparios ir labai prieinamos pranešimų technologijos, našumas labai pagerėtų. Nedvejodamas rekomenduočiau RabbitMQ su klasterizavimu toliau nurodytose situacijose:

• Nepatikimas tinklas.
• Nepatikima saugykla.
• Labai ilgos eilės.

Kalbant apie aukšto pasiekiamumo nustatymus, atsižvelkite į šiuos dalykus:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (Arba autoheal)
• nuolatiniai pranešimai
• užtikrinti, kad klientai prisijungtų prie aktyvaus mazgo, kai kuris nors mazgas sugenda

Siekiant nuoseklumo (duomenų saugumo), apsvarstykite šiuos nustatymus:

• Leidėjas vartotojo pusėje patvirtina ir rankiniu būdu patvirtina
• ha-promote-on-failure=when-synced, jei leidėjai gali bandyti dar kartą vėliau ir jei turite labai patikimą saugyklą! Priešingu atveju įdėti =always.
• ha-sync-mode=automatic (tačiau didelėms neaktyvioms eilėms gali prireikti rankinio režimo; taip pat apsvarstykite, ar dėl neprieinamumo pranešimai bus prarasti)
• Pristabdyti mažumos režimą
• nuolatiniai pranešimai

Mes dar neaptarėme visų atsparumo gedimams ir didelio prieinamumo klausimų; pavyzdžiui, kaip saugiai atlikti administracines procedūras (pvz., nuolatinius atnaujinimus). Taip pat turime kalbėti apie federaciją ir Shovel įskiepį.

Jei dar ko nors praleidau, praneškite.

Taip pat žiūrėkite mano paštu, kur aš atlieku sumaištį RabbitMQ klasteryje naudodamas Docker ir Blockade, kad išbandyčiau kai kuriuos šiame straipsnyje aprašytus pranešimų praradimo scenarijus.

Ankstesni šios serijos straipsniai:
Nr. 1 - habr.com/ru/company/itsumma/blog/416629
Nr. 2 - habr.com/ru/company/itsumma/blog/418389
Nr. 3 - habr.com/ru/company/itsumma/blog/437446

Šaltinis: www.habr.com