Vikasietokyky ja korkea saatavuus ovat suuria aiheita, joten omistamme erilliset artikkelit RabbitMQ:lle ja Kafkalle. Tämä artikkeli käsittelee RabbitMQ:ta ja seuraava Kafkaa verrattuna RabbitMQ:han. Tämä on pitkä artikkeli, joten ole mukava.

Tarkastellaan vikasieto-, johdonmukaisuus- ja korkean käytettävyyden (HA) strategioita ja kunkin strategian kompromisseja. RabbitMQ voi toimia solmuklusterissa - ja sitten se luokitellaan hajautetuksi järjestelmäksi. Kun puhutaan hajautetuista järjestelmistä, puhumme usein johdonmukaisuudesta ja saatavuudesta.

Nämä käsitteet kuvaavat, kuinka järjestelmä käyttäytyy epäonnistuessaan. Verkkoyhteysvirhe, palvelinvika, kiintolevyvirhe, palvelimen tilapäinen käyttökatko roskankeräyksen, pakettien katoamisen tai verkkoyhteyden hidastumisen vuoksi. Kaikki tämä voi johtaa tietojen katoamiseen tai ristiriitaan. Osoittautuu, että on käytännössä mahdotonta rakentaa järjestelmää, joka on sekä täysin johdonmukainen (ei tietojen häviämistä, ei tietojen eroa) että käytettävissä (hyväksyy lukemisen ja kirjoittamisen) kaikissa vikatilanteissa.

Näemme, että yhdenmukaisuus ja saatavuus ovat spektrin vastakkaisissa päissä, ja sinun on valittava optimointitapa. Hyvä uutinen on, että RabbitMQ:lla tämä valinta on mahdollista. Sinulla on tällaisia ​​"nörttiä" vipuja siirtääksesi tasapainoa kohti parempaa johdonmukaisuutta tai parempaa saavutettavuutta.

Kiinnitämme erityistä huomiota siihen, mitkä kokoonpanot johtavat tietojen katoamiseen vahvistettujen tietueiden vuoksi. Julkaisijoiden, välittäjien ja kuluttajien välillä on vastuuketju. Kun viesti on välitetty välittäjälle, hänen tehtävänsä on olla hukkaamatta viestiä. Kun välittäjä vahvistaa, että julkaisija on vastaanottanut viestin, emme odota sen katoavan. Mutta näemme, että tämä voi todella tapahtua välittäjän ja julkaisijan asetuksista riippuen.

Yhden solmun kestävyysprimitiivit

Joustava jonotus/reititys

RabbitMQ:ssa on kahdenlaisia ​​jonoja: kestäviä ja kestäviä. Kaikki jonot tallennetaan Mnesia-tietokantaan. Kestäviä jonoja mainostetaan uudelleen solmun käynnistyksen yhteydessä, ja ne kestävät siten uudelleenkäynnistyksen, järjestelmän kaatumisen tai palvelimen kaatumisen (niin kauan kuin tietoja säilytetään). Tämä tarkoittaa, että niin kauan kuin julistat reitityksen (vaihdon) ja jonon kestäviksi, jonotus-/reititysinfrastruktuuri palaa verkkoon.

Haihtuvat jonot ja reititys poistetaan, kun solmu käynnistetään uudelleen.

Pysyviä viestejä

Vain siksi, että jono on kestävä, ei tarkoita, että kaikki sen viestit säilyvät hengissä solmun uudelleenkäynnistyksen jälkeen. Vain julkaisijan asettamat viestit jatkuva (pysyvä). Pysyvät viestit aiheuttavat lisäkuormitusta välittäjälle, mutta jos viestin katoamista ei voida hyväksyä, ei ole muuta vaihtoehtoa.

Riisi. 1. Kestävän kehityksen matriisi

Klusterointi jonojen peilauksella

Selviytyäksemme välittäjän menetyksestä tarvitsemme irtisanomisia. Voimme yhdistää useita RabbitMQ-solmuja klusteriksi ja lisätä sitten ylimääräistä redundanssia replikoimalla jonoja useiden solmujen välillä. Tällä tavalla, jos yksi solmu epäonnistuu, emme menetä tietoja ja pysymme käytettävissä.

Jonon peilaus:

• yksi pääjono (master), joka vastaanottaa kaikki kirjoitus- ja lukukomennot
• yksi tai useampi peili, joka vastaanottaa kaikki viestit ja metatiedot pääjonosta. Nämä peilit eivät ole skaalausta varten, vaan puhtaasti redundanssia varten.

Riisi. 2. Jonon peilaus

Peilaus määräytyy asianmukaisen käytännön mukaan. Siinä voit valita replikointikertoimen ja jopa solmut, joissa jonon tulisi sijaita. Esimerkkejä:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (yksi mestari ja yksi peili)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Julkaisijan vahvistus

Johdonmukaisen tallennuksen saavuttamiseksi tarvitaan Publisher Confirms. Ilman niitä on olemassa vaara, että viestit katoavat. Julkaisijalle lähetetään vahvistus, kun viesti on kirjoitettu levylle. RabbitMQ kirjoittaa viestejä levylle ei vastaanotettaessa, vaan säännöllisin väliajoin, useiden satojen millisekuntien alueella. Kun jono peilataan, kuittaus lähetetään vasta, kun kaikki peilit ovat myös kirjoittaneet kopion viestistä levylle. Tämä tarkoittaa, että vahvistusten käyttö lisää viivettä, mutta jos tietoturva on tärkeää, ne ovat välttämättömiä.

Virheensiirtojono

Kun välittäjä lopettaa tai kaatuu, kaikki kyseisen solmun jonojohtajat (masterit) kaatuvat sen mukana. Tämän jälkeen klusteri valitsee kunkin isäntälaitteen vanhimman peilin ja mainostaa sen uudeksi isännäksi.

Riisi. 3. Useita peilattuja jonoja ja niiden käytännöt

Broker 3 kaatuu. Huomaa, että Broker 2:n Queue C -peili ylennetään masteriksi. Huomaa myös, että Broker 1:n jonolle C on luotu uusi peili. RabbitMQ yrittää aina säilyttää käytännöissäsi määritetyn replikointitekijän.

Riisi. 4. Välittäjä 3 epäonnistuu, mikä aiheuttaa jonon C epäonnistumisen

Seuraava Broker 1 putoaa! Meillä on vain yksi välittäjä jäljellä. Jonon B peili ylennetään masteriksi.

Kuva 5

Olemme palauttaneet Broker 1:n. Huolimatta siitä, kuinka hyvin tiedot selviävät välittäjän katoamisesta ja palautumisesta, kaikki peilatut jonoviestit hylätään uudelleenkäynnistyksen yhteydessä. Tämä on tärkeää huomata, koska sillä on seurauksia. Tarkastelemme näitä vaikutuksia pian. Joten Broker 1 on nyt jälleen klusterin jäsen, ja klusteri yrittää noudattaa käytäntöjä ja luo siksi peilejä Broker 1:lle.

Tässä tapauksessa Broker 1:n menetys oli täydellinen, samoin kuin tiedot, joten peilaamaton jono B katosi kokonaan.

Riisi. 6. Välittäjä 1 palaa palveluun

Broker 3 on taas online-tilassa, joten jonot A ja B saavat takaisin sille luodut peilit HA-käytäntöjensä mukaisesti. Mutta nyt kaikki pääjonot ovat yhdessä solmussa! Tämä ei ole ihanteellinen, tasainen jakautuminen solmujen välillä on parempi. Valitettavasti tässä ei ole paljon vaihtoehtoja mestareiden tasapainottamiseen. Palaamme tähän ongelmaan myöhemmin, koska meidän on ensin tarkasteltava jonojen synkronointia.

Riisi. 7. Välittäjä 3 palaa palveluun. Kaikki pääjonot yhdessä solmussa!

Joten nyt sinulla pitäisi olla käsitys siitä, kuinka peilit tarjoavat redundanssin ja vikasietoisuuden. Tämä varmistaa käytettävyyden yksittäisen solmun vian sattuessa ja suojaa tietojen katoamiselta. Mutta emme ole vielä valmiita, koska todellisuudessa se on paljon monimutkaisempaa.

tahdistus

Kun luot uuden peilin, kaikki uudet viestit kopioidaan aina tähän peiliin ja kaikkiin muihin. Mitä tulee pääjonon olemassa olevaan dataan, voimme replikoida sen uuteen peiliin, josta tulee täydellinen kopio isäntäjonosta. Voimme myös päättää olla replikoimatta olemassa olevia viestejä ja antaa pääjonon ja uuden peilin lähentyä ajoissa, jolloin uudet viestit saapuvat pääjonon päähän ja olemassa olevat viestit poistuvat pääjonon päästä.

Tämä synkronointi suoritetaan automaattisesti tai manuaalisesti, ja sitä hallitaan jonokäytännön avulla. Katsotaanpa esimerkkiä.

Meillä on kaksi peilattua jonoa. Jono A synkronoidaan automaattisesti ja jono B manuaalisesti. Molemmat jonot sisältävät kymmenen viestiä.

Riisi. 8. Kaksi jonoa eri synkronointitiloilla

Nyt menetämme Broker 3:n.

Riisi. 9. Välittäjä 3 putosi

Broker 3 palaa palveluun. Klusteri luo peilin jokaiselle jonolle uudessa solmussa ja synkronoi automaattisesti uuden jonon A isäntäkoneen kanssa. Uuden B-jonon peili jää kuitenkin tyhjäksi. Tällä tavalla meillä on täysi redundanssi jonossa A ja vain yksi peili olemassa oleville jonon B viesteille.

Riisi. 10. Jonon A uusi peili vastaanottaa kaikki olemassa olevat viestit, mutta jonon B uusi peili ei.

Molempiin jonoihin saapuu vielä kymmenen viestiä. Broker 2 kaatuu sitten ja jono A rullaa takaisin vanhimpaan peiliin, joka on Broker 1:ssä. Tietoja ei menetetä, jos se epäonnistuu. B-jonossa on kaksikymmentä viestiä isännässä ja vain kymmenen peilissä, koska tämä jono ei koskaan replikoinut alkuperäisiä kymmentä viestiä.

Riisi. 11. Jono A palaa välittäjälle 1 menettämättä viestejä

Molempiin jonoihin saapuu vielä kymmenen viestiä. Nyt Broker 1 kaatuu. Jono A siirtyy helposti peiliin menettämättä viestejä. Jonossa B on kuitenkin ongelmia. Tässä vaiheessa voimme optimoida saatavuuden tai johdonmukaisuuden.

Jos haluamme optimoida saavutettavuuden, niin politiikka ha-promote-on-epäonnistuminen tulee asentaa sisään aina. Tämä on oletusarvo, joten et voi yksinkertaisesti määrittää käytäntöä ollenkaan. Tässä tapauksessa sallimme pohjimmiltaan viat synkronoimattomissa peileissä. Tämä aiheuttaa viestien katoamisen, mutta jono pysyy luettavissa ja kirjoitettavissa.

Riisi. 12. Jono A palautetaan välittäjälle 3 menettämättä viestejä. Jono B rullaa takaisin välittäjälle 3 ja kymmenen viestiä on kadonnut

Voimme myös asentaa ha-promote-on-failure merkitykseen when-synced. Tässä tapauksessa sen sijaan, että jono palaisi peiliin, se odottaa, kunnes Broker 1 tietoineen palaa online-tilaan. Kun se palaa, pääjono on takaisin Broker 1:ssä ilman tietojen menetystä. Saatavuus uhrataan tietoturvan vuoksi. Mutta tämä on riskialtis tila, joka voi jopa johtaa täydelliseen tietojen katoamiseen, jota tarkastelemme pian.

Riisi. 13. Jono B ei ole käytettävissä välittäjän 1 menettämisen jälkeen

Saatat kysyä: "Onko parempi olla koskaan käyttämättä automaattista synkronointia?" Vastaus on, että synkronointi on estotoiminto. Synkronoinnin aikana pääjono ei voi suorittaa mitään luku- tai kirjoitustoimintoja!

Katsotaanpa esimerkkiä. Nyt meillä on pitkät jonot. Miten ne voivat kasvaa noin kokoisiksi? Useista syistä:

• Jonoja ei käytetä aktiivisesti
• Nämä ovat nopeita jonoja, ja tällä hetkellä kuluttajat ovat hitaita
• Se on nopeita jonoja, on ollut häiriö ja kuluttajat ovat kiinni

Riisi. 14. Kaksi suurta jonoa eri synkronointitiloilla

Nyt Broker 3 putoaa.

Riisi. 15. Välittäjä 3 putoaa, jolloin jokaiseen jonoon jää yksi isäntä ja peili

Broker 3 palaa verkkoon ja uusia peilejä luodaan. Pääjono A alkaa replikoida olemassa olevia viestejä uuteen peiliin, ja tänä aikana jono ei ole käytettävissä. Tietojen replikointi kestää kaksi tuntia, mikä johtaa kahden tunnin seisokkiin tälle jonolle!

Jono B on kuitenkin käytettävissä koko jakson ajan. Hän uhrasi jonkin verran irtisanomisia saavutettavuuden vuoksi.

Riisi. 16. Jono ei ole käytettävissä synkronoinnin aikana

Kahden tunnin kuluttua myös jono A tulee saataville, ja se voi alkaa hyväksyä lukuja ja kirjoituksia uudelleen.

Päivitykset

Tämä estokäyttäytyminen synkronoinnin aikana vaikeuttaa erittäin suuria jonoja sisältävien klustereiden päivittämistä. Jossain vaiheessa pääsolmu on käynnistettävä uudelleen, mikä tarkoittaa joko vaihtamista peiliin tai jonon poistamista käytöstä palvelimen päivityksen aikana. Jos valitsemme siirtymisen, menetämme viestit, jos peilejä ei synkronoida. Oletusarvoisesti välittäjän käyttökatkon aikana vikasietoa ei suoriteta synkronoimattomaan peiliin. Tämä tarkoittaa, että heti kun välittäjä palaa, emme menetä yhtään viestiä, ainoa vahinko oli yksinkertainen jono. Käytännössä määritetään käyttäytymissäännöt, kun välittäjä katkaistaan ha-promote-on-shutdown. Voit asettaa toisen kahdesta arvosta:

• always= siirtyminen synkronoimattomiin peileihin on käytössä
• when-synced= siirtyminen vain synkronoituun peiliin, muuten jonosta tulee lukukelvoton ja kirjoituskelvoton. Jono palaa palveluun heti välittäjän palattua

Tavalla tai toisella suurilla jonoilla sinun on valittava tietojen katoamisen ja epäkäytettävyyden välillä.

Kun saatavuus parantaa tietoturvaa

On vielä yksi monimutkaisuus, joka on otettava huomioon ennen päätöksen tekemistä. Vaikka automaattinen synkronointi on parempi redundanssille, miten se vaikuttaa tietoturvaan? Tietysti paremmalla redundanssilla RabbitMQ ei todennäköisesti menetä olemassa olevia viestejä, mutta entä julkaisijoiden uudet viestit?

Tässä sinun on otettava huomioon seuraavat asiat:

• Voisiko julkaisija yksinkertaisesti palauttaa virheilmoituksen ja pyytää palvelua tai käyttäjää yrittämään myöhemmin uudelleen?
• Voiko julkaisija tallentaa viestin paikallisesti tai tietokantaan yrittääkseen myöhemmin uudelleen?

Jos julkaisija voi vain hylätä viestin, itse asiassa saavutettavuuden parantaminen parantaa myös tietoturvaa.

Tasapainoa on siis etsittävä, ja ratkaisu riippuu tilanteesta.

Ongelmia ha-promote-on-failure=when-synced kanssa

Ajatus ha-promote-on-epäonnistuminen= milloin synkronoitu on se, että estämme siirtymisen synkronoimattomaan peiliin ja näin vältämme tietojen katoamisen. Jono on edelleen lukukelvoton tai kirjoitettava. Sen sijaan yritämme palauttaa kaatuneen välittäjän tiedot ehjinä, jotta se voi jatkaa toimintaansa isäntänä ilman tietojen menetystä.

Mutta (ja tämä on iso mutta) jos välittäjä on menettänyt tietonsa, meillä on suuri ongelma: jono on kadonnut! Kaikki data on poissa! Vaikka sinulla olisikin peilit, jotka pääosin saavuttavat pääjonon, myös ne peilit hylätään.

Jos haluat lisätä samannimisen solmun uudelleen, käskemme klusterin unohtamaan kadonneen solmun (komennolla rabbitmqctl Force_cluster_node) ja aloita uusi välittäjä samalla isäntänimellä. Vaikka klusteri muistaa kadonneen solmun, se muistaa vanhan jonon ja synkronoimattomat peilit. Kun klusterin käsketään unohtaa orpo solmu, myös tämä jono unohdetaan. Nyt meidän on julistettava se uudelleen. Menetimme kaikki tiedot, vaikka meillä oli peilit osittaisella datajoukolla. Olisi parempi vaihtaa ei-synkronoituun peiliin!

Siksi manuaalinen synkronointi (ja synkronoinnin epäonnistuminen) yhdessä ha-promote-on-failure=when-synced, mielestäni aika riskialtista. Asiakirjat sanovat, että tämä vaihtoehto on olemassa tietoturvan vuoksi, mutta se on kaksiteräinen veitsi.

Master tasapainotus

Kuten luvattiin, palaamme ongelmaan, joka koskee kaikkien isäntien kertymistä yhteen tai useampaan solmuun. Tämä voi tapahtua jopa jatkuvan klusterin päivityksen seurauksena. Kolmen solmun klusterissa kaikki pääjonot kerääntyvät yhteen tai kahteen solmuun.

Masterien tasapainottaminen voi olla ongelmallista kahdesta syystä:

• Tasapainotuksen suorittamiseen ei ole olemassa hyviä työkaluja
• Jonon synkronointi

Tasapainottamiseksi on kolmas osapuoli plugin, jota ei virallisesti tueta. Mitä tulee kolmannen osapuolen laajennuksiin RabbitMQ-oppaassa sanoi: "Lisäosa tarjoaa joitain muita määritys- ja raportointityökaluja, mutta RabbitMQ-tiimi ei tue tai vahvista sitä. Käytä omalla vastuullasi."

On toinenkin temppu siirtää pääjonoa HA-käytäntöjen kautta. Ohjekirjassa mainitaan käsikirjoitus tätä varten. Se toimii näin:

• Poistaa kaikki peilit käyttämällä väliaikaista käytäntöä, jolla on korkeampi prioriteetti kuin nykyisellä HA-käytännöllä.
• Muuttaa HA:n väliaikaisen käytännön käyttämään solmutilaa ja määrittää solmun, johon pääjono tulee siirtää.
• Synkronoi push-siirron jonon.
• Kun siirto on valmis, poistaa väliaikaisen käytännön. Alkuperäinen HA-käytäntö astuu voimaan ja tarvittava määrä peilejä luodaan.

Huono puoli on, että tämä lähestymistapa ei välttämättä toimi, jos sinulla on suuret jonot tai tiukat redundanssivaatimukset.

Katsotaan nyt kuinka RabbitMQ-klusterit toimivat verkkoosioiden kanssa.

Yhteyden katkeaminen

Hajautetun järjestelmän solmut on yhdistetty verkkolinkeillä, ja verkkolinkit voidaan ja tullaan katkaisemaan. Katkosten tiheys riippuu paikallisesta infrastruktuurista tai valitun pilven luotettavuudesta. Joka tapauksessa hajautettujen järjestelmien on kyettävä selviytymään niistä. Jälleen kerran meillä on mahdollisuus valita saatavuuden ja johdonmukaisuuden välillä, ja jälleen hyvä uutinen on, että RabbitMQ tarjoaa molemmat vaihtoehdot (ei vain samaan aikaan).

RabbitMQ:lla meillä on kaksi päävaihtoehtoa:

• Salli looginen jako (split-brain). Tämä varmistaa saatavuuden, mutta voi aiheuttaa tietojen menetyksen.
• Poista looginen erottelu käytöstä. Saattaa johtaa lyhytaikaiseen saatavuuden menettämiseen riippuen siitä, kuinka asiakkaat muodostavat yhteyden klusteriin. Voi myös johtaa täydelliseen epäkäytettävyyteen kahden solmun klusterissa.

Mutta mitä on looginen erottelu? Tällöin klusteri jakautuu kahtia verkkoyhteyksien katkeamisen vuoksi. Kummallakin puolella peilit ylennetään masteriksi, jolloin jonossa on lopulta useita isäntiä.

Riisi. 17. Pääjono ja kaksi peiliä, kumpikin erillisessä solmussa. Sitten tapahtuu verkkovika ja yksi peili irtoaa. Erotettu solmu näkee, että kaksi muuta ovat pudonneet ja ylentävät peilinsä isäntään. Meillä on nyt kaksi pääjonoa, sekä kirjoitettavat että luettavat.

Jos julkaisijat lähettävät dataa molemmille isännille, päädymme kahteen eri kopioon jonosta.

RabbitMQ:n eri tilat tarjoavat joko saatavuuden tai yhdenmukaisuuden.

Ohita tila (oletus)

Tämä tila varmistaa saavutettavuuden. Yhteyden katkeamisen jälkeen tapahtuu looginen erottelu. Kun yhteys on palautettu, järjestelmänvalvojan on päätettävä, mille osioille hän antaa etusija. Häviävä puoli käynnistetään uudelleen ja kaikki tälle puolelle kertyneet tiedot menetetään.

Riisi. 18. Kolme kustantajaa liittyy kolmeen välittäjään. Sisäisesti klusteri reitittää kaikki pyynnöt Broker 2:n pääjonoon.

Nyt menetämme Broker 3:n. Hän näkee, että muut välittäjät ovat pudonneet ja mainostaa peiliään isännille. Näin looginen erottelu tapahtuu.

Riisi. 19. Looginen jako (split-brain). Tietueet menevät kahteen pääjonoon, ja kaksi kopiota eroavat toisistaan.

Yhteydet palautetaan, mutta looginen erottelu säilyy. Järjestelmänvalvojan on valittava häviävä puoli manuaalisesti. Alla olevassa tapauksessa järjestelmänvalvoja käynnistää Broker 3:n uudelleen. Kaikki viestit, joita hän ei onnistunut lähettämään, menetetään.

Riisi. 20. Järjestelmänvalvoja poistaa Broker 3:n käytöstä.

Riisi. 21. Järjestelmänvalvoja käynnistää Broker 3:n ja se liittyy klusteriin menettäen kaikki sinne jääneet viestit.

Yhteyden katkeamisen aikana ja sen palauttamisen jälkeen klusteri ja tämä jono olivat käytettävissä lukemista ja kirjoittamista varten.

Automaattinen paranemistila

Toimii samalla tavalla kuin Ohita-tila, paitsi että klusteri itse valitsee automaattisesti häviävän puolen yhteyden jakamisen ja palauttamisen jälkeen. Häviävä puoli palaa klusteriin tyhjänä, ja jono menettää kaikki viestit, jotka lähetettiin vain tälle puolelle.

Keskeytä vähemmistötila

Jos emme halua sallia loogista osiointia, ainoa vaihtoehtomme on hylätä luku- ja kirjoitustoiminnot pienemmällä puolella klusteriosion jälkeen. Kun välittäjä näkee olevansa pienemmällä puolella, se keskeyttää työn, eli sulkee kaikki olemassa olevat yhteydet ja kieltäytyy uusista. Kerran sekunnissa se tarkistaa yhteyden palautuksen. Kun yhteys on palautettu, se jatkaa toimintaansa ja liittyy klusteriin.

Riisi. 22. Kolme kustantajaa liittyy kolmeen välittäjään. Sisäisesti klusteri reitittää kaikki pyynnöt Broker 2:n pääjonoon.

Välittäjät 1 ja 2 eroavat sitten Broker 3:sta. Sen sijaan, että mainostaisi peilinsä masteriksi, Broker 3 jäädyttää ja poistuu käytöstä.

Riisi. 23. Broker 3 keskeyttää, katkaisee yhteyden kaikkiin asiakkaisiin ja hylkää yhteyspyynnöt.

Kun yhteys on palautettu, se palaa klusteriin.

Katsotaanpa toista esimerkkiä, jossa pääjono on Broker 3:ssa.

Riisi. 24. Broker 3:n pääjono.

Sitten tapahtuu sama yhteyden katkeaminen. Välittäjä 3 pysähtyy, koska se on pienemmällä puolella. Toisella puolella solmut näkevät, että Broker 3 on pudonnut, joten Brokers 1:n ja 2:n vanhempi peili ylennetään masteriksi.

Riisi. 25. Siirtyminen Broker 2:een, jos Broker 3 ei ole käytettävissä.

Kun yhteys on palautettu, Broker 3 liittyy klusteriin.

Riisi. 26. Klusteri on palannut normaaliin toimintaan.

Tässä on tärkeää ymmärtää, että saamme johdonmukaisuuden, mutta voimme myös saada saatavuuden, jos Siirrämme asiakkaita onnistuneesti suurimmalle osalle osastosta. Useimmissa tilanteissa valitsisin henkilökohtaisesti Pause Minority -tilan, mutta se riippuu todella tapauksesta.

Käytettävyyden varmistamiseksi on tärkeää varmistaa, että asiakkaat muodostavat onnistuneen yhteyden isäntään. Katsotaanpa vaihtoehtojamme.

Asiakasyhteyksien varmistaminen

Meillä on useita vaihtoehtoja, kuinka ohjata asiakkaat klusterin pääosaan tai toimiviin solmuihin (kun yksi solmu epäonnistuu) yhteyden katkeamisen jälkeen. Ensin muistetaan, että tietty jono isännöi tietyssä solmussa, mutta reititys ja käytännöt replikoidaan kaikissa solmuissa. Asiakkaat voivat muodostaa yhteyden mihin tahansa solmuun, ja sisäinen reititys ohjaa heidät minne heidän täytyy mennä. Mutta kun solmu keskeytetään, se hylkää yhteydet, joten asiakkaiden on muodostettava yhteys toiseen solmuun. Jos solmu putoaa, hän ei voi tehdä juuri mitään.

Vaihtoehtomme:

• Klusteriin päästään kuormantasaajan avulla, joka yksinkertaisesti kiertää solmut ja asiakkaat yrittävät muodostaa yhteyden uudelleen, kunnes onnistuu. Jos solmu on alhaalla tai keskeytetty, yhteyden muodostamisyritykset kyseiseen solmuun epäonnistuvat, mutta seuraavat yritykset menevät muille palvelimille (kierto-robin). Tämä sopii lyhytaikaiseen yhteyden katkeamiseen tai kaatuneeseen palvelimeen, joka palautetaan nopeasti.
• Käytä klusteria kuormituksen tasaajan kautta ja poista keskeytetyt/epäonnistuneet solmut luettelosta heti, kun ne havaitaan. Jos teemme tämän nopeasti ja jos asiakkaat voivat yrittää yhteyttä uudelleen, saavutamme jatkuvan käytettävyyden.
• Anna jokaiselle asiakkaalle luettelo kaikista solmuista, ja asiakas valitsee satunnaisesti yhden niistä muodostaessaan yhteyden. Jos se saa virheilmoituksen yrittäessään muodostaa yhteyttä, se siirtyy luettelon seuraavaan solmuun, kunnes se muodostaa yhteyden.
• Poista liikenne epäonnistuneesta/keskeytetystä solmusta DNS:n avulla. Tämä tehdään käyttämällä pientä TTL:ää.

Tulokset

RabbitMQ-klusteroinnilla on hyvät ja huonot puolensa. Vakavimpia haittoja ovat seuraavat:

• klusteriin liittyessään solmut hylkäävät tietonsa;
• synkronoinnin estäminen aiheuttaa sen, että jono ei ole käytettävissä.

Kaikki vaikeat päätökset johtuvat näistä kahdesta arkkitehtonisesta piirteestä. Jos RabbitMQ voisi tallentaa tietoja, kun klusteri yhdistetään uudelleen, synkronointi olisi nopeampaa. Jos se pystyisi estämään synkronoinnin, se tukisi paremmin suuria jonoja. Näiden kahden ongelman korjaaminen parantaisi huomattavasti RabbitMQ:n suorituskykyä vikasietoisena ja erittäin saatavilla olevana viestintäteknologiana. En epäröi suositella RabbitMQ:ta klusteroimalla seuraavissa tilanteissa:

• Epäluotettava verkko.
• Epäluotettava tallennustila.
• Todella pitkät jonot.

Kun kyse on korkean käytettävyyden asetuksista, ota huomioon seuraavat seikat:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (tai autoheal)
• pysyviä viestejä
• varmistaa, että asiakkaat muodostavat yhteyden aktiiviseen solmuun, kun jokin solmu epäonnistuu

Johdonmukaisuuden (tietoturvan) vuoksi harkitse seuraavia asetuksia:

• Julkaisijan vahvistukset ja manuaaliset tunnustukset kuluttajan puolelta
• ha-promote-on-failure=when-synced, jos julkaisijat voivat yrittää myöhemmin uudelleen ja jos sinulla on erittäin luotettava tallennustila! Muuten laita =always.
• ha-sync-mode=automatic (mutta suurille ei-aktiivisille jonoille saatetaan tarvita manuaalista tilaa; harkitse myös, aiheuttaako epäkäytettävyys viestien katoamista)
• Keskeytä vähemmistötila
• pysyviä viestejä

Emme ole vielä käsittäneet kaikkia vikasietoisuuteen ja korkeaan käytettävyyteen liittyviä kysymyksiä; esimerkiksi kuinka hallinnolliset toimenpiteet (kuten jatkuvat päivitykset) suoritetaan turvallisesti. Meidän on myös puhuttava liittämisestä ja Shovel-laajennuksesta.

Jos olen unohtanut jotain muuta, ilmoita minulle.

Katso myös minun posti, jossa teen tuhon RabbitMQ-klusterille käyttämällä Dockeria ja Blockadea testatakseni joitain tässä artikkelissa kuvattuja viestin katoamisskenaarioita.

Sarjan aiemmat artikkelit:
Nro 1 - habr.com/ru/company/itsumma/blog/416629
Nro 2 - habr.com/ru/company/itsumma/blog/418389
Nro 3 - habr.com/ru/company/itsumma/blog/437446

Lähde: will.com