Jõudlus ja kõrge kättesaadavus on suured teemad, seega pühendame RabbitMQ ja Kafka käsitlemisele eraldi artiklid. See artikkel käsitleb RabbitMQ-d, järgmine aga Kafka-d võrreldes RabbitMQ-ga. Artikkel on pikk, seega minge mugavale positsioonile.

Kaalume tõrkealtiuse, kooskõlastatuse ja kõrge kättesaadavuse (HA) strateegiaid ning kompromisse, millega iga strateegia puhul silmitsi seisame. RabbitMQ saab töötada sõlmede klastris — sel juhul liigitatakse see jaotatud süsteemiks. Räägime jaotatud süsteemidest, rääkides räägime sageli kooskõlastatusest ja kättesaadavusest.

Need mõisted kirjeldavad, kuidas süsteem käitub ebaõnnestumise korral. Võrguyhenduse ebaõnnestumine, serveri ebaõnnestumine, kõvaketta ebaõnnestumine, serveri ajutine kättesaamatus prügikoristuse tõttu, paketikaotus või võrguühenduse aeglustumine. Kõik need võivad põhjustada andmete kaotsimineku või konfliktid. On selge, et on peaaegu võimatu luua süsteemi, mis oleks korraga täielikult kooskõlas (ilma andmete kaotamiseta, ilma andmete lahknevuseta) ja kättesaadav (ootab lugemis- ja kirjutamise operatsioone) kõikide ebaõnnestumise variantide puhul.

Nähtame, et kooskõlastatus ja kättesaadavus asuvad spektri eri otsades ning teil tuleb valida, mille suunas optimeerida. Hea uudis on see, et RabbitMQ puhul on selline valik võimalik. Teil on teatavad «geeniuse» nupud, et tasakaalu suunata suurema kooskõlastatuse või suurema kättesaadavuse poole.

Eraldi tähelepanu pöörame sellele, millised konfiguratsioonid viivad andmete kaotamiseni kinnitatud salvestuste tõttu. On vastutusketi sidusus pubiisherite, vahendajate ja tarbijate vahel. Kui sõnum on edastatud vahendajale, on tema ülesanne — mitte sõnumit kaotada. Kui vahendaja kinnitab pubiisherile sõnumi vastuvõtmist, siis ei oota me, et see kaoks. Kuid näeme, et tegelikult võib see juhtuda sõltuvalt teie vahendaja ja väljaandja konfiguratsioonist.

Ühe sõlme vastupidavuse primitiivid

Vastupidavad järjekorrad/routimiseks

RabbitMQ-s on kaks tüüpi järjekordi: püsivad (durable) ja ebapüsivad (non-durable). Kõik järjekorrad salvestatakse Mnesia andmebaasi. Püsivad järjekorrad kuulutatakse uuesti välja sõlme käivitamisel ja seetõttu ellu jäävad need käivitamisest, süsteemihäirest või serverihäirest (niikaua kuni andmed on salvestatud). See tähendab, et seni kuni kuulutate marsruutimise (exchange) ja järjekorra püsivaks, tagastatakse järjekordade/marsruutimise infrastruktuur töökorda.

Ebapüsivad järjekorrad ja marsruutimine eemaldatakse sõlme taaskäivitamisel.

Püsivad sõnumid

Juba see, et järjekord on püsiv, ei tähenda, et kõik selle sõnumid ellu jäävad sõlme taaskäivitamisel. Taaskäideldud saavad ainult need sõnumid, mille avaldaja on määranud püsivaks (persistent). Püsivad sõnumid tõepoolest suurendavad maakleri koormust, kuid kui sõnumi kadu on vastuvõetamatu, siis pole muud võimalust.

Joonis 1. Püsivuse maatriks

Klastrimine peegeldusega järjekorras

Kuna me vajame maakleri kaotuse ellu jäämiseks ülemäärasust. Saame ühendada mitu RabbitMQ sõlme klastriks ja seejärel lisada täiendava ülemäärasuse, kopeerides järjekorrad mitme sõlme vahel. Nii et kui üks sõlm ebaõnnestub, ei kaota me andmeid ja jääme ligipääsetavaks.

Järjekorra peegelduse:

• ühes peajärjekorras (master), mis saab kõik kirjutamise ja lugemise käsud
• ühe või mitme peegli, mis saavad kõik sõnumid ja metaandmed peajärjekorrast. Need peeglid eksisteerivad mitte skaleerimiseks, vaid ainult ülemäärasuse tõttu.

Joonis 2. Järjekorra peegelduse seadistamine

Peegelduse seadistamine toimub vastava poliitika kaudu. Selles saab valida kopeerimise määra ja isegi sõlmed, kus järjekord peaks asuma. Näited:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (üks master ja üks peegel)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Kinnitamine avaldajale

Järjepideva salvestuse saavutamiseks on vajalikud kinnitused väljastajalt (Publisher Confirms). Ilma nendeta on sõnumite kadumise oht. Kinnitus saadetakse väljastajale pärast sõnumi salvestamist kettale. RabbitMQ salvestab sõnumeid kettale mitte vastuvõtmise hetkel, vaid perioodiliselt, vahemikus mitusada millisekundit. Kui järjekord on peegeldatud, saadetakse kinnitus ainult siis, kui kõik peeglid on samuti salvestanud oma koopia sõnumist kettale. See tähendab, et kinnituste kasutamine lisab viivitust, kuid kui andmete turvalisus on oluline, on need vajalikud.

Vastupidav järjekord

Kui vahendaja lõpetab töö või kukub kokku, siis kõik peamised järjekorrad (meistrid) sellel sõlmel kukuvad koos temaga. Siis valib klaster igast meistrist kõige vanema peegli ja edendab selle uueks meistriks.

Joonis 3. Mitmed peegeldatud järjekorrad ja nende poliitikad

Vahendaja 3 kukub kokku. Pange tähele, et Järjekorra C peegel Vahendaja 2-l tõuseb meistriks. Samuti tehke tähele, et Järjekorra C jaoks on loodud uus peegel Vahendaja 1-l. RabbitMQ püüab alati säilitada teie poliitikates määratud replikatsiooni suhet.

Joonis 4. Vahendaja 3 kukub kokku, mis põhjustab Järjekorra C ebaõnnestumise

Kukub järgmine Vahendaja 1! Meil on jäänud ainult üks vahendaja. Järjekorra B peegel tõuseb meistriks.

Joonis 5

Me oleme taastanud Vahendaja 1. Olenemata sellest, kui edukalt andmed üle elasid vahendaja kadumise ja taastumise, visatakse kõik peegeldatud sõnumid järjekorrast käivitamisel minema. See on oluline märkida, kuna see toob kaasa tagajärjed. Kõige peagi käsitleme neid tagajärgi. Nii on Vahendaja 1 nüüd taas klastris, ja klaster püüab järgida poliitikaid ning seetõttu loob peegleid Vahendaja 1-l.

Sellisel juhul oli Vahendaja 1 kadu täielik, nagu ka andmete kadu, seega on peegeldamata Järjekord B täielikult kadunud.

Joonis 6. Vahendaja 1 naaseb teenistusse

Broker 3 on taas aktiivne, seega saavad järjekorrad A ja B tagasi loodud peeglid, et rahuldada oma HA poliitikaid. Kuid nüüd asuvad kõik peajärjekorrad ühel sõlmendel! See pole ideaalne, parem oleks ühtlane jaotus sõlmede vahel. Kahjuks ei ole siin mingeid erilisi võimalusi meistrite ümberjaotamiseks. Naaseme selle probleemiga hiljem, sest esmalt tuleb vaadata järjekorra sünkroniseerimist.

Joonis 7. Broker 3 naaseb teenistusse. Kõik peajärjekorrad ühel sõlmendel!

Nii et teil peaks nüüd olema arusaam, kuidas peeglid tagavad ülemäärasuse ja tõrkekindluse. See tagab kättesaadavuse, kui üks sõlm langeb ja kaitseb andmete kadumise eest. Aga me pole veel lõpetanud, sest tegelikult on kõik palju keerulisem.

Sünkroniseerimine

Uue peegli loomisel replikatakse kõik uued sõnumid alati sellele peeglile ja muudele. Mis puutub olemasolevaid andmeid peajärjekorras, saame need replikeerida uude peeglisse, mis muutub meistri täiskoopiaks. Samuti võime mitte replikeerida olemasolevaid sõnumeid ja lasta peajärjekorral ja uuel peeglil aja jooksul kokku tulla, kui uued sõnumid sisenevad sabasse ja olemasolevad sõnumid lahkuvad peajärjekorra algusest.

Selline sünkroniseerimine toimub automaatselt või käsitsi ja seda hallatakse järjekorra poliitika abil. Vaatame näidet.

Meil on kaks peegeldatud järjekorda. Järjekord A sünkroniseeritakse automaatselt, samas kui järjekord B käsitsi. Mõlemas järjekorras on kümme sõnumit.

Joonis 8. Kaks järjekorda erinevate sünkroniseerimisrežiimidega

Nüüd kaotame Broker 3.

Joonis 9. Broker 3 kukkus

Broker 3 naaseb teenistusse. Klaster loob igale järjekorrale uue peegli uuel sõlmendel ja sünkroniseerib automaatselt uue Järjekorra A meistriga. Kuid uue Järjekorra B peegel jääb tyhjaks. Seega on meil täielik üleliigsus Järjekorras A ja ainult üks peegel olemasolevate sõnumite jaoks Järjekorras B.

Joonis 10. Uus peegel Järjekorras A saab kõik olemasolevad sõnumid, kuid uus peegel Järjekorras B ei saa.

Mõlemasse järjekorda tuleb veel kümme teadet. Siis kukub Broker 2 ja Järjekord A pöörab tagasi kõige vanemale peegeldisele, mis asub Broker 1-l. Rikkumise korral andmeid ei kaotata. Järjekorras B on kakskümmend teadet isikus ja ainult kümme peegelduses, kuna see järjekord ei ole kunagi algset kümmet teadet replikoinud.

Joonis 11. Järjekord A pöördub tagasi Broker 1-le ilma teadete kaotamiseta

Mõlemasse järjekorda tuleb veel kümme teadet. Nüüd kukub Broker 1. Järjekord A ümberlülitub probleemideta peegeldisele ilma teadete kaotamiseta. Siiski on Järjekorras B probleeme. Sel hetkel saame optimeerida kas kättesaadavust või järjepidevust.

Kui soovime optimeerida kättesaadavust, siis seadke poliitika ha-promote-on-failure asetamiseks peaks olema always. See on vaikimisi väärtus, seega võib poliitikat lihtsalt mitte määrata. Sel juhul laseme tegelikult esineda tõrkeid sünkroniseerimata peegeldistes. See toob kaasa teadete kaotuse, kuid järjekord jääb lugemiseks ja kirjutamiseks kättesaadavaks.

Joonis 12. Järjekord A pöördub Broker 3-le ilma teadete kaotamiseta. Järjekord B pöördub Broker 3-le, kaotades kümme teadet

Saame ka seadistada ha-promote-on-failure väärtuseks when-synced. Sel juhul ootab järjekord peegeldisele tagasipöördumist Broker 1-l koos tema andmetega. Pärast tema tagasitulekut on peamine järjekord taas Broker 1-l ilma andmete kaotamiseta. Kättesaadavuse nimel on ohutus ohverdatud. Kuid see on riskantne režiim, mis võib isegi kaasa tuua täieliku andmete kaotuse, mida me peagi vaatame.

Joonis 13. Järjekord B jääb pärast Broker 1 kaotust kättesaamatuks

Võite esitada küsimuse: "Kas võib-olla pole parem kunagi automaatset sünkroonimist kasutada?" Vastus on see, et sünkroonimine on blokeeriv operatsioon. Sünkroonimise ajal ei saa peamine järjekord teha mingeid lugemis- või kirjutamistöid!

Vaatame näiteks. Praegu on meil väga suured järjekorrad. Kuidas need saavad kasvada nii suurteks? Mõne põhjuse tõttu:

• Järjekordi ei kasutata aktiivselt
• Need on kõrge kiirusjärjekorrad ja praegu töötavad tarbijad aeglaselt
• Need on kõrge kiirusjärjekorrad, esines tõrge ja tarbijad jõuavad järjele

Joonis 14. Kaks suurt järjekorda erinevate sünkroonimisrežiimidega

Nüüd kukub Broker 3.

Joonis 15. Broker 3 kukub, jättes igasse järjekorda ühe meistri ja peegli

Broker 3 taastub ja luuakse uued peeglid. Peamine Järjekord A hakkab olemasolevaid sõnumeid uuele peeglile replikeerima, ja selle aja jooksul on järjekord saadaval. Andmete replikeerimiseks on vajalik kaks tundi, mis toob kaasa kahe tunni seisaku selle järjekorra jaoks!

Kuid Järjekord B jääb kogu selle aja jooksul saadavaks. Ta ohverdas osa liigsetest ressurssidest saadavuse nimel.

Joonis 16. Järjekord jääb sünkroonimise ajal saadavaks

Kaks tundi hiljem on Järjekord A samuti taas saadaval ja võib uuesti alustada lugemise ja kirjutamise toimingutega.

Uuendused

Selline blokeeriv käitumine sünkroonimise ajal raskendab klastrite värskendamist väga suurte järjekordadega. Ühes etapis tuleb meistriga sõlm taaskäivitada, mis tähendab kas peeglisse üleminekut või järjekorra väljalülitamist serveri värskendamise ajal. Kui valime ülemineku, kaotame sõnumid, kui peeglid ei ole sünkroniseeritud. Vaikimisi ei tehta väljalülitatava brokera puhul üleminekut mitte-sünkroniseeritud peeglisse. See tähendab, et niipea kui broker taastub, ei kaota me ühtegi sõnumit, ainus kahju oli järjekorra seiskamine. Brokera väljalülitamise käitumise reeglid määratakse poliitika kaudu ha-promote-on-shutdown. Saate seada ühe kahest väärtusest:

• always= sünkroniseerimata peeglitele üleminek on lubatud
• when-synced= üleminek ainult sünkroniseeritud peeglile, vastasel juhul järjekord ei ole saadaval lugemiseks ja kirjutamiseks. Järjekord taastub, niipea kui broker naaseb

Igal juhul tuleb suurte järjekordade puhul valida andmete kadumise ja saadavuse vahel.

Kui saadavus suurendab andmete turvalisust

Enne otsuse tegemist tuleb arvesse võtta veel üks keeruline aspekt. Kuigi automaatne sünkroonimine on parem liigsete ressursside puhul, kuidas see mõjutab andmete turvalisust? Loomulikult on parema liigsetega RabbitMQ-l väiksem tõenäosus olemasolevate sõnumite kaotada, kuid kuidas on uute sõnumitega, mis saadetakse avaldajatelt?

Siin tuleb arvesse võtta järgmist:

• Kas võib publisher lihtsalt veateate tagasi saata, ja ülemine teenistus või kasutaja proovivad hiljem uuesti?
• Kas avaldaja saab sõnumi kohapeal või andmebaasis hoida, et proovida hiljem uuesti?

Kui publisher suudab ainult sõnumi tagasi lükata, siis parandab ligipääsetavuse suurendamine ka andmete turvalisust.

Seega tuleb leida tasakaal ning lahendus sõltub konkreetsest olukorrast.

Probleemid ha-promote-on-failure=when-synced

Idee ha-promote-on-failure= when-synced on selles, et me takistame üleminekuid sünkroniseerimata peeglitele ja seeläbi vältida andmete kadumist. Quee jääb lugemiseks või kirjutamiseks kättesaamatuks. Selle asemel proovime taastada kukkunud brokori puutumatute andmetega, et see suudaks jätkata tööd peamina ilma andmete kadumiseta.

Aga (ja see on suur aga) kui brokori andmed on kadunud, siis on meil suur probleem: järjekord on kadunud! Kõik andmed on kadunud! Isegi kui teil on peeglid, mis enamasti jõuavad peajärjekorrale järele, visatakse need peeglid samuti välja.

Kuna soovime sama nimega sõlme uuesti lisada, käsime klastril unustada kadunud sõlm (käsk rabbitmqctl forget_cluster_node) ja käivitame uue brokori sama hostinimega. Niikauaks, kui klaster mäletab kadunud sõlme, mäletab see vana järjekorda ja sünkroniseerimata peegleid. Kui klastrile öeldakse unustada kadunud sõlm, unustatakse ka see järjekord. Nüüd tuleb see uuesti välja kuulutada. Oleme kaotanud kõik andmed, kuigi meil olid peeglid osalise andmekogumiga. Oleks parem minna üle sünkroniseerimata peeglile!

Seetõttu on käsitsi sünkroniseerimine (ja sünkroniseerimise mitteteostamine) koos ha-promote-on-failure=when-synced, minu arvates üsna riskantne. Dokumendid ütlevad, et selline valik eksisteerib andmete turvalisuse nimel, kuid see on kahepoolselt terav nuga.

Meistrite ümberbalanseerimine

Nagu lubatud, naaseme probleemi juurde, et kõik meistrid on koondunud ühele või mitmele sõlmele. See võib juhtuda isegi 'libiseva' (rolling) klastri värskendamise tõttu. Kolme sõlmega klastris koonduvad kõik peajärjekorrad ühele või kahele sõlmele.

Meistrite ümberbalanseerimine võib osutuda keeruliseks kahel põhjusel:

• Heade tööriistade puudumine ümberbalanseerimise teostamiseks
• Järjekordade sünkroniseerimine

Ümberbalanseerimiseks on kolmanda osapoole plugin, mida ametlikult ei toetata. RabbitMQ juhendis mainitakse kolmandate osapoolte pluginaid. öeldakse: «Plugin pakub mõned lisavahendid seadistamiseks ja aruandluseks, kuid ei ole RabbitMQ meeskonna poolt toetatud ega kontrollitud. Kasutada oma riskil».

On veel üks nipp, et liigutada peamine järjekord HA poliitikate kaudu. Juhendis mainitakse skripti selle jaoks. See töötab järgmiselt:

• Eemaldab kõik peeglid kõrgema prioriteediga ajutise poliitika abil kui eksisteeriv HA poliitika.
• Muudab ajutise HA poliitika nii, et see kasutab 'sõlmed' režiimi, määrates sõlme, kuhu peamine järjekord liigutatakse.
• Sünkroniseerib järjekorra sundmigratsiooni teostamiseks.
• Pärast migratsiooni lõpetamist eemaldab ajutise poliitika. Kehtima hakkab algne HA poliitika ja luuakse vajalik arv peegleid.

Puuduseks on see, et selline lähenemine ei pruugi toimida, kui teil on suured järjekorrad või ranged üleliigsuse nõuded.

Nüüd vaatame, kuidas RabbitMQ klastrid töötavad võrgu jaotustega.

Sidususe rikkumine

Kaasaegse süsteemi sõlmed on omavahel ühendatud võrguühendustes ning võrguühendused võivad ja tõenäoliselt katkeda. Katkestuste sagedus sõltub kohalikust infrastruktuurist või valitud pilve usaldusväärsusest. Igatahes peavad hajutatud süsteemid olema võimelised nendega toime tulema. Jällegi on meil valik kättesaadavuse ja järjepidevuse vahel ning taas on hea uudis see, et RabbitMQ tagab mõlemad võimalused (kuid mitte samaaegselt).

RabbitMQ puhul on meil kaks peamist valikut:

• Luba loogiline jaotus (split-brain). See tagab kättesaadavuse, kuid võib põhjustada andmekaotust.
• Keela loogiline jaotus. See võib põhjustada lühiajalist kättesaadavuse kadumist sõltuvalt sellest, kuidas kliendid klastrisse ühenduvad. See võib samuti viia kahe sõlmega klastris täieliku kättesaamatuse.

Aga mis on loogiline jaotus? See on olukord, kui klaster jaguneb kaheks võrguühenduste kaotuse tõttu. Igal pool tõusevad peeglid meistriks, nii et lõpuks on iga järjekorra puhul mitu meistrit.

Joon. 17. Peamine järjekord ja kaks peeglit, igaühe oma eraldi sõlmes. Siis tekib võrgu katkestus ja üks peegel eemaldub. Eemaldunud sõlm näeb, et kaks teist on katkenud, ja tõukab oma peeglid meistriks. Nüüd on meil kaks peamist järjekorda, ja mõlemad lubavad kirjutamist ja lugemist.

Kui väljaandjad saadavad andmeid mõlemale meistrile, saame kaks lahknevat järjekorra koopiat.

Erinevad RabbitMQ režiimid tagavad kas kättesaadavuse või kooskõlastatuse.

Ignoreeri režiim (vaikimisi)

See režiim tagab kättesaadavuse. Pärast ühenduse kadumist toimub loogiline jaotumine. Pärast ühenduse taastumist peab administraator otsustama, kummale jaotusele eelisse anda. Kaotav pool taaskäivitub ja kõik selle poole kogunenud andmed kaovad.

Joon. 18. Kolm väljaandjat on seotud kolme maakleri jaotisega. Sisemiselt suunab klaster kõik taotlused peamisse järjekorda Maakler 2 juures.

Nüüd kaotame Maakleri 3. Ta näeb, et teised maaklerid on katkenud, ja tõukab oma peegli meistriks. Nii toimub loogiline jaotumine.

Joon. 19. Loogiline jaotumine (split-brain). Kirjad lähevad kahte peamisse järjekorda ja kaks koopiat lahknevad.

Ühendus taastatakse, kuid loogiline jaotumine jääb. Administraator peab käsitsi valima kaotava poole. Antud juhul taaskäivitab administraator Maakler 3. Kaovad kõik sõnumid, mida ta ei jõudnud edastada.

Joon. 20. Administraator keelab Maakler 3.

Joon. 21. Administraator käivitab Maakler 3, ja ta liitub klastriga, kaotades kõik sõnumid, mis seal olid.

Ühenduse kadumise ajal ja pärast selle taastumist olid klaster ja see järjekord saadaval lugemiseks ja kirjutamiseks.

Autoheal režiim

Töötleb sarnaselt Ignoreeri režiimile, välja arvatud see, et klaster valib automaatselt kaotava poole pärast jaotust ja ühenduse taastamist. Kaotav pool naaseb klastrisse tühi, ja järjekord kaotab kõik sõnumid, mis olid saadetud ainult sellele poolele.

Pause Minority režiim

Kui me ei soovi jätta loogilist lõhet, on meie ainus võimalus loobuda lugemisest ja kirjutamisest väiksemas osas pärast klastrit. Kui maakler näeb, et ta on väiksemas osas, peatab ta töö, st sulgeb kõik olemasolevad ühendused ja loobub igasugustest uutest. Ta kontrollib ühenduse taastumist kord sekundis. Niikaua kui ühendus on taastatud, taastab ta töö ja liitub klassiga.

Joonis 22. Kolm publikut on seotud kolme maakleriga. Klastri sees suunatakse kõik päringud peajärjekorda Maakler 2-l.

Seejärel lahknevad Maaklerid 1 ja 2 Maaklerist 3. Selle asemel, et oma peeglit meistriks tõsta, peatab Maakler 3 töö ja muutub kättesaamatuks.

Joonis 23. Maakler 3 peatab töö, väljalülitab kõik kliendid ja keeldub ühenduste vastuvõtmisest.

Kui ühendus on taastatud, naaseb ta klassi.

Vaadakem teist näidet, kus peajärjekord asub Maakler 3-l.

Joonis 24. Peajärjekord Maakler 3-l.

Seejärel toimub sama ühenduse kadumine. Maakler 3 peatub, kuna ta on väiksemas osas. Teisel poolel näevad sõlmed, et Maakler 3 on kukkunud, nii et vanem peegel Maakleritest 1 ja 2 tõstetakse meistriks.

Joonis 25. Üleminek Maakler 2-le Maakler 3 puudumise korral.

Kui ühendus on taastatud, liitub Maakler 3 klassiga.

Joonis 26. Klastri töö on taastunud.

Siin on oluline mõista, et saavutame järjepidevuse, kuid saame ka kättesaadavuse. kui edukalt suuname kliendid suuremale osale lõhest. Enamikus olukordades valiksin isiklikult Pause Minority režiimi, kuid see sõltub tõeliselt konkreetsetest juhtumitest.

Kättesaadavuse tagamiseks on oluline veenduda, et kliendid saavad edukalt sõlmele ühenduda. Vaadakem meie võimalusi.

Kliendi ühenduse tagamine

Meil on mitu võimalust, kuidas suunata kliente peamiseks klastriks või toimivatele sõlmedele pärast ühenduse kadu (üks sõlm on ebaõnnestunud). Esiteks tuletame meelde, et konkreetne järjekord on paigaldatud teatud sõlme, kuid marsruutimine ja poliitikad replikeeritakse kõigil sõlmedel. Kliendid saavad ühenduda mis tahes sõlmega ja sisemine marsruutimine suunab nad õigesse kohta. Kuid kui sõlm on peatatud, lükkab see tagasi ühendused, seega peavad kliendid ühenduma teise sõlmiga. Kui sõlm on ebaõnnestunud, ei saa ta üldse midagi teha.

Meie võimalused:

• Juurdepääs klastrile toimub koormuse tasakaalustaja kaudu, mis lihtsalt tsükliliselt vahetab sõlmi, ning kliendid proovivad uuesti ühendust luua kuni edukani. Kui sõlm ei tööta või on peatatud, siis ühenduse loomise katsed selle sõlmega ebaõnnestuvad, kuid järgnevad katsed lähevad teistele serveritele (tsüklilisel viisil). See sobib lühiajalise ühenduse kadumise või langenud serveri jaoks, mis tõstetakse kiiresti üles.
• Juurdepääs klastrile koormuse tasakaalustaja kaudu ja peatatud/veel langevate sõlmede eemaldamine nimekirjast niipea, kui nad avastatakse. Kui seda teha kiiresti ning klientidel on võimalus proovida uuesti ühendust luua, saavutame pideva kättesaadavuse.
• Anda igale kliendile kõigi sõlmede nimekiri, ning klient valib ühendamise ajal juhuslikult ühe neist. Kui ühenduse loomise katsel ilmneb viga, siirdub ta järgmisele sõlmele nimekirjas, kuni ühendub.
• Eemaldada liiklus langenud/peatatud sõlmest DNS-i kaudu. See toimub väikese TTL-i kasutamisega.

Järeldused

RabbitMQ klastril on oma eelised ja puudused. Kõige tõsisemad puudused on:

• kliendi liitumisel klastriga sõlmed loobuvad oma andmetest;
• blokkeeriv sünkroniseerimine toob kaasa järjekorra kättesaamatuse.

Kõik rasked otsused tulenevad neist kahest arhitektuuri omadusest. Kui RabbitMQ suudaks andmeid hoida klastriga uuesti ühendamisel, toimuks sünkroniseerimine kiiremini. Kui see suudaks mitteblokeerivat sünkroniseerimist, toetaks see paremini suuri järjekordi. Nende kahe probleemi lahendamine parandaks tõsiselt RabbitMQ jõudlust usaldusväärse ja kõrge kättesaadavuse sõnumitehnoloogiana. Ei soovitaks RabbitMQ-d klastrimise kasutamiseks järgmistel juhtudel:

• Ebastabiilne võrk.
• Ebastabiilne salvestus.
• Väga suured järjekorrad.

Kõrge kättesaadavuse seadistuste osas kaaluge järgmisi:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (või autoheal)
• püsivad sõnumid
• veenduge, et kliendid ühinevad aktiivse sõlmega, kui mingi sõlm tõrkub

Andmete järjepidevuse (turvalisuse) tagamiseks kaaluge järgmisi seadeid:

• Publisher Confirms ja Manual Acknowledgements tarbija poolel
• ha-promote-on-failure=when-synced, kui väljaandjad saavad hiljem katsetada ja kui teil on väga usaldusväärne salvestus! Vastasel juhul seadke =always.
• ha-sync-mode=automatic (aga suurte mitteaktiivsete järjekordade puhul võib osutuda vajalikuks käsitsi režiim; lisaks mõelge, kas kättesaamatus võib põhjustada sõnumite kadu)
• Pause Minority režiim
• püsivad sõnumid

Oleme arutanud veel kaugele mitte jõudnud usaldusväärsuse ja kõrge kättesaadavuse küsimusi; näiteks, kuidas ohutult läbida administratiivseid protseduure (näiteks libisev uuendamine). Peaksime arutama ka föderatsiooni ja Shovel plugina.

Kui ma veel midagi unustasin, palun andke teada.

Vaadake ka minu postitus, kus viin läbi RabbitMQ klastri purustamise Docker'i ja Blockade'iga, et testida mõningaid selle artikli sõnumikadumise stsenaariume.

Seeria eelmine artikkel:
Nr 1 — habr.com/et/company/itsumma/blog/416629
Nr 2 — habr.com/et/company/itsumma/blog/418389
Nr 3 — habr.com/et/company/itsumma/blog/437446

Allikas: habr.com