Kļūdu tolerance un augsta pieejamība ir lielas tēmas, tāpēc RabbitMQ un Kafka veltīsim atsevišķus rakstus. Šis raksts ir par RabbitMQ, bet nākamais ir par Kafku salīdzinājumā ar RabbitMQ. Šis ir garš raksts, tāpēc jūtieties ērti.

Apskatīsim kļūdu tolerances, konsekvences un augstas pieejamības (HA) stratēģijas un katras stratēģijas radītos kompromisus. RabbitMQ var darboties mezglu klasterī, un pēc tam tiek klasificēta kā izplatīta sistēma. Runājot par izplatītajām sistēmām, mēs bieži runājam par konsekvenci un pieejamību.

Šie jēdzieni apraksta, kā sistēma darbojas, ja tā neizdodas. Tīkla savienojuma kļūme, servera kļūme, cietā diska kļūme, servera īslaicīga nepieejamība atkritumu savākšanas, pakešu zuduma vai tīkla savienojuma palēninājuma dēļ. Tas viss var izraisīt datu zudumu vai konfliktus. Izrādās, ka praktiski nav iespējams izveidot sistēmu, kas būtu gan pilnīgi konsekventa (nav datu zuduma, ne datu novirzes), gan pieejama (pieņems lasīšanu un rakstīšanu) visiem kļūmju scenārijiem.

Mēs redzēsim, ka konsekvence un pieejamība atrodas pretējā spektra galos, un jums ir jāizvēlas optimizēšanas veids. Labā ziņa ir tā, ka ar RabbitMQ šī izvēle ir iespējama. Jums ir šādas “nervu” sviras, lai novirzītu līdzsvaru uz lielāku konsekvenci vai lielāku pieejamību.

Īpašu uzmanību pievērsīsim tam, kuras konfigurācijas izraisa datu zudumu apstiprināto ierakstu dēļ. Starp izdevējiem, brokeriem un patērētājiem pastāv atbildības ķēde. Kad ziņojums ir nosūtīts brokerim, viņa uzdevums ir nepazaudēt ziņojumu. Kad starpnieks apstiprina, ka izdevējs ir saņēmis ziņojumu, mēs negaidām, ka tas tiks pazaudēts. Taču mēs redzēsim, ka tas faktiski var notikt atkarībā no jūsu starpnieka un izdevēja konfigurācijas.

Viena mezgla elastīguma primitīvas

Elastīga rinda/maršrutēšana

RabbitMQ ir divu veidu rindas: izturīgas un neizturīgas. Visas rindas tiek saglabātas Mnesia datubāzē. Noturīgas rindas tiek atkārtoti reklamētas mezgla palaišanas laikā, un tādējādi tās izdzīvo restartēšanas, sistēmas avārijas vai servera avārijas (ja vien tiek saglabāti dati). Tas nozīmē, ka tik ilgi, kamēr jūs paziņosiet, ka maršrutēšana (apmaiņa) un rinda ir elastīga, rindas/maršrutēšanas infrastruktūra atkal būs tiešsaistē.

Nepastāvīgās rindas un maršrutēšana tiek noņemta, kad mezgls tiek restartēts.

Pastāvīgi ziņojumi

Tas, ka rinda ir izturīga, nenozīmē, ka visi tās ziņojumi izdzīvos pēc mezgla restartēšanas. Tikai ziņojumi, kurus izdevējs iestatījis kā elastīga (noturīgs). Pastāvīgi ziņojumi rada papildu slodzi brokerim, taču, ja ziņojumu zudums ir nepieņemams, tad nav citas iespējas.

Rīsi. 1. Ilgtspējas matrica

Klasterizācija ar rindu spoguļošanu

Lai pārdzīvotu brokera zaudējumu, mums ir nepieciešama atlaišana. Mēs varam apvienot vairākus RabbitMQ mezglus klasterī un pēc tam pievienot papildu dublēšanu, atkārtojot rindas starp vairākiem mezgliem. Tādā veidā, ja viens mezgls neizdodas, mēs nezaudējam datus un paliekam pieejami.

Rindas spoguļošana:

• viena galvenā rinda (master), kas saņem visas rakstīšanas un lasīšanas komandas
• viens vai vairāki spoguļi, kas saņem visus ziņojumus un metadatus no galvenās rindas. Šie spoguļi nav paredzēti mērogošanai, bet gan tikai atlaišanai.

Rīsi. 2. Rindas spoguļošana

Spoguļošanu nosaka atbilstošā politika. Tajā varat atlasīt replikācijas koeficientu un pat mezglus, uz kuriem jāatrodas rindai. Piemēri:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (viens meistars un viens spogulis)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Izdevēja apstiprinājums

Lai nodrošinātu konsekventu ierakstīšanu, ir nepieciešami izdevēja apstiprinājumi. Bez tiem pastāv risks, ka ziņojumi tiks pazaudēti. Pēc ziņojuma ierakstīšanas diskā izdevējam tiek nosūtīts apstiprinājums. RabbitMQ ieraksta ziņojumus diskā nevis pēc saņemšanas, bet periodiski, vairāku simtu milisekundu apgabalā. Kad rinda tiek atspoguļota, apstiprinājums tiek nosūtīts tikai pēc tam, kad visi spoguļi ir arī ierakstījuši savu ziņojuma kopiju diskā. Tas nozīmē, ka apstiprinājumu izmantošana palielina latentumu, bet, ja datu drošība ir svarīga, tad tie ir nepieciešami.

Kļūmjpārlēces rinda

Kad brokeris pārtrauc darbu vai avarē, visi šī mezgla rindu vadītāji (galvenie) kopā ar to avarē. Pēc tam klasteris atlasa katra meistara vecāko spoguli un reklamē to kā jauno meistaru.

Rīsi. 3. Vairākas spoguļattēlu rindas un to politikas

Brokeris 3 nokrīt. Ņemiet vērā, ka Broker 2 rindas C spogulis tiek paaugstināts par galveno. Ņemiet vērā arī to, ka ir izveidots jauns spogulis rindai C pakalpojumā Broker 1. RabbitMQ vienmēr mēģina uzturēt jūsu politikās norādīto replikācijas faktoru.

Rīsi. 4. Broker 3 neizdodas, izraisot rindas C kļūmi

Nākamais Broker 1 krīt! Mums ir palicis tikai viens brokeris. Rindas B spogulis tiek paaugstināts par galveno.

Att. 5

Mēs esam atgriezuši Broker 1. Neatkarīgi no tā, cik labi dati saglabājas pēc starpnieka zaudēšanas un atkopšanas, restartējot tiek atmesti visi spoguļattēlu rindas ziņojumi. Tas ir svarīgi atzīmēt, jo tam būs sekas. Drīzumā aplūkosim šīs sekas. Tātad Broker 1 tagad atkal ir klastera dalībnieks, un klasteris mēģina ievērot politikas un tāpēc izveido spoguļus Broker 1.

Šajā gadījumā Broker 1 zaudēšana bija pilnīga, tāpat kā dati, tāpēc neatspoguļotā rinda B tika pilnībā zaudēta.

Rīsi. 6. Brokeris 1 atgriežas darbā

Broker 3 atkal ir tiešsaistē, tāpēc rindas A un B saņem atpakaļ tajā izveidotos spoguļus, lai izpildītu viņu HA politikas. Bet tagad visas galvenās rindas ir vienā mezglā! Tas nav ideāli, vienmērīgs sadalījums starp mezgliem ir labāks. Diemžēl šeit nav daudz iespēju, kā līdzsvarot meistarus. Mēs atgriezīsimies pie šīs problēmas vēlāk, jo mums vispirms ir jāaplūko rindu sinhronizācija.

Rīsi. 7. Brokeris 3 atgriežas darbā. Visas galvenās rindas vienā mezglā!

Tāpēc tagad jums vajadzētu būt priekšstatam par to, kā spoguļi nodrošina atlaišanu un kļūdu toleranci. Tas nodrošina pieejamību viena mezgla atteices gadījumā un aizsargā pret datu zudumu. Bet mēs vēl neesam pabeiguši, jo patiesībā tas ir daudz sarežģītāk.

Sinhronizācija

Veidojot jaunu spoguli, visi jaunie ziņojumi vienmēr tiks replicēti šajā spogulī un citos. Kas attiecas uz esošajiem datiem galvenajā rindā, mēs varam tos replicēt uz jaunu spoguli, kas kļūst par pilnīgu galvenā kopiju. Mēs varam arī izvēlēties nedublēt esošos ziņojumus un ļaut galvenajai rindai un jaunajam spoguļam saplūst laikā, jaunajiem ziņojumiem nonākot beigās un esošajiem ziņojumiem atstājot galvenās rindas galvgali.

Šī sinhronizācija tiek veikta automātiski vai manuāli, un tā tiek pārvaldīta, izmantojot rindas politiku. Apskatīsim piemēru.

Mums ir divas spoguļrindas. Rinda A tiek sinhronizēta automātiski, un rinda B tiek sinhronizēta manuāli. Abās rindās ir desmit ziņojumi.

Rīsi. 8. Divas rindas ar dažādiem sinhronizācijas režīmiem

Tagad mēs zaudējam Broker 3.

Rīsi. 9. Brokeris 3 krita

Brokeris 3 atgriežas darbā. Klasteris izveido spoguli katrai rindai jaunajā mezglā un automātiski sinhronizē jauno rindu A ar galveno. Tomēr jaunās rindas B spogulis paliek tukšs. Tādā veidā mums ir pilnīga dublēšana A rindā un tikai viens spogulis esošajiem rindas B ziņojumiem.

Rīsi. 10. Jaunais rindas A spogulis saņem visus esošos ziņojumus, bet jaunais rindas B spogulis nesaņem.

Abās rindās tiek saņemti vēl desmit ziņojumi. Pēc tam brokeris 2 avarē, un rinda A atgriežas pie vecākā spoguļa, kas atrodas Broker 1. Ja tas neizdodas, dati netiek zaudēti. Rindā B ir divdesmit ziņojumi galvenajā un tikai desmit ziņojumi spogulī, jo šī rinda nekad nedublē sākotnējos desmit ziņojumus.

Rīsi. 11. Rinda A atgriežas pie Broker 1, nezaudējot ziņojumus

Abās rindās tiek saņemti vēl desmit ziņojumi. Tagad Broker 1 avarē. Rinda A viegli pārslēdzas uz spoguli, nezaudējot ziņojumus. Tomēr rindai B ir problēmas. Šajā brīdī mēs varam optimizēt pieejamību vai konsekvenci.

Ja vēlamies optimizēt pieejamību, tad politika ha-promote-on-failure jāiestata iekšā vienmēr. Šī ir noklusējuma vērtība, tāpēc jūs varat vienkārši nenorādīt politiku vispār. Šajā gadījumā mēs būtībā pieļaujam kļūmes nesinhronizētos spoguļos. Tādējādi ziņojumi tiks zaudēti, bet rinda paliks lasāma un rakstāma.

Rīsi. 12. Rinda A tiek atgriezta atpakaļ uz Broker 3, nezaudējot ziņojumus. Rinda B atgriežas pie Broker 3 ar desmit zaudētiem ziņojumiem

Varam arī uzstādīt ha-promote-on-failure nozīmē when-synced. Šajā gadījumā tā vietā, lai atgrieztos pie spoguļa, rinda gaidīs, līdz Broker 1 ar saviem datiem atgriezīsies tiešsaistes režīmā. Pēc atgriešanās galvenā rinda atkal ir pieejama Broker 1 bez datu zudumiem. Pieejamība tiek upurēta datu drošībai. Bet tas ir riskants režīms, kas var pat izraisīt pilnīgu datu zudumu, ko mēs tuvākajā laikā apskatīsim.

Rīsi. 13. Rinda B paliek nepieejama pēc 1. brokera zaudēšanas

Jūs varat jautāt: "Vai labāk nekad neizmantot automātisko sinhronizāciju?" Atbilde ir tāda, ka sinhronizācija ir bloķēšanas darbība. Sinhronizācijas laikā galvenā rinda nevar veikt nekādas lasīšanas vai rakstīšanas darbības!

Apskatīsim piemēru. Tagad mums ir ļoti garas rindas. Kā viņi var izaugt līdz tādam izmēram? Vairāku iemeslu dēļ:

• Rindas netiek aktīvi izmantotas
• Tās ir ātrgaitas rindas, un šobrīd patērētāji ir lēni
• Tās ir ātrgaitas rindas, ir radusies kļūme, un patērētāji to panāk

Rīsi. 14. Divas lielas rindas ar dažādiem sinhronizācijas režīmiem

Tagad Broker 3 krīt.

Rīsi. 15. Brokeris 3 krīt, atstājot katrā rindā vienu meistaru un spoguli

Broker 3 atgriežas tiešsaistē un tiek izveidoti jauni spoguļi. Galvenā rinda A sāk replicēt esošos ziņojumus jaunajā spogulī, un šajā laikā rinda nav pieejama. Datu pavairošana aizņem divas stundas, kā rezultātā šai rindai ir divas stundas dīkstāves!

Tomēr rinda B ir pieejama visu periodu. Viņa upurēja dažas atlaišanas pieejamības dēļ.

Rīsi. 16. Sinhronizācijas laikā rinda paliek nepieejama

Pēc divām stundām kļūst pieejama arī rinda A, un tā var atkal sākt lasīt un rakstīt.

Atjauninājumi

Šī bloķējošā darbība sinhronizācijas laikā apgrūtina klasteru atjaunināšanu ar ļoti lielām rindām. Kādā brīdī galvenais mezgls ir jārestartē, kas nozīmē vai nu pārslēgšanos uz spoguli, vai rindas atspējošanu, kamēr serveris tiek jaunināts. Ja izvēlēsimies pāreju, mēs zaudēsim ziņojumus, ja spoguļi netiks sinhronizēti. Pēc noklusējuma brokera darbības pārtraukuma laikā kļūmjpārlēce uz nesinhronizētu spoguli netiek veikta. Tas nozīmē, ka tiklīdz brokeris atgriežas, mēs nezaudējam nevienu ziņojumu, vienīgais kaitējums bija vienkārša rinda. Uzvedības noteikumus, kad brokeris ir atvienots, nosaka politika ha-promote-on-shutdown. Varat iestatīt vienu no divām vērtībām:

• always= ir iespējota pāreja uz nesinhronizētiem spoguļiem
• when-synced= pāreja tikai uz sinhronizētu spoguli, pretējā gadījumā rinda kļūst nelasāma un neierakstāma. Rinda atgriežas apkalpošanā, tiklīdz atgriežas brokeris

Tā vai citādi, ar lielām rindām ir jāizvēlas starp datu zudumu vai nepieejamību.

Kad pieejamība uzlabo datu drošību

Pirms lēmuma pieņemšanas jāņem vērā vēl viens sarežģījums. Lai gan automātiskā sinhronizācija ir labāka atlaišanai, kā tā ietekmē datu drošību? Protams, ar labāku dublēšanu RabbitMQ ir mazāka iespēja zaudēt esošos ziņojumus, bet kā ir ar jaunajiem ziņojumiem no izdevējiem?

Šeit jums jāņem vērā sekojošais:

• Vai izdevējs varētu vienkārši atgriezt kļūdu un likt augšējam pakalpojumam vai lietotājam vēlāk mēģināt vēlreiz?
• Vai izdevējs var saglabāt ziņojumu lokāli vai datu bāzē, lai vēlāk mēģinātu vēlreiz?

Ja izdevējs var tikai atmest ziņojumu, tad faktiski pieejamības uzlabošana uzlabo arī datu drošību.

Tādējādi ir jāmeklē līdzsvars, un risinājums ir atkarīgs no konkrētās situācijas.

Problēmas ar ha-promote-on-failure=when-synced

Ideja ha-promote-on-failure= kad-sinhronizēts ir tas, ka mēs novēršam pāreju uz nesinhronizētu spoguli un tādējādi izvairāmies no datu zuduma. Rinda paliek nelasāma vai rakstāma. Tā vietā mēs cenšamies atgūt avarējušo brokeri ar neskartiem datiem, lai tas varētu atsākt darboties kā galvenais, nezaudējot datus.

Bet (un tas ir liels, bet), ja brokeris ir pazaudējis savus datus, tad mums ir liela problēma: rinda ir zaudēta! Visi dati ir pazuduši! Pat ja jums ir spoguļi, kas pārsvarā sasniedz galveno rindu, arī šie spoguļi tiek izmesti.

Lai atkārtoti pievienotu mezglu ar tādu pašu nosaukumu, mēs sakām klasterim aizmirst pazaudēto mezglu (ar komandu rabbitmqctl aizmirst_kopas_node) un sāciet jaunu brokeri ar tādu pašu saimniekdatora nosaukumu. Kamēr klasteris atceras zaudēto mezglu, tas atceras veco rindu un nesinhronizētos spoguļus. Kad klasterim tiek likts aizmirst bāreņu mezglu, tiek aizmirsta arī šī rinda. Tagad mums tas ir atkārtoti jādeklarē. Mēs zaudējām visus datus, lai gan mums bija spoguļi ar daļēju datu kopu. Labāk būtu pāriet uz nesinhronizētu spoguli!

Tāpēc manuāla sinhronizācija (un neveiksme sinhronizācijā) kombinācijā ar ha-promote-on-failure=when-synced, manuprāt, diezgan riskanti. Dokumenti saka, ka šī opcija pastāv datu drošībai, taču tā ir abpusēji griezīgs nazis.

Galvenā līdzsvara atjaunošana

Kā solīts, mēs atgriežamies pie problēmas, kas saistīta ar visu meistaru uzkrāšanos vienā vai vairākos mezglos. Tas var notikt pat mainīga klastera atjaunināšanas rezultātā. Trīs mezglu klasterī visas galvenās rindas tiks uzkrātas vienā vai divos mezglos.

Meistaru līdzsvara atjaunošana var būt problemātiska divu iemeslu dēļ:

• Nav labu instrumentu, lai veiktu līdzsvarošanu
• Rindas sinhronizācija

Līdzsvara atjaunošanai ir trešā puse iespraust, kas oficiāli netiek atbalstīts. Par trešo pušu spraudņiem RabbitMQ rokasgrāmatā teica: “Spraudnis nodrošina dažus papildu konfigurācijas un ziņošanas rīkus, taču RabbitMQ komanda to neatbalsta vai nepārbauda. Izmantojiet uz savu risku."

Ir vēl viens triks, kā pārvietot galveno rindu, izmantojot HA politikas. Rokasgrāmatā minēts skripts priekš šī. Tas darbojas šādi:

• Noņem visus spoguļus, izmantojot pagaidu politiku, kurai ir augstāka prioritāte nekā esošajai HA politikai.
• Maina HA pagaidu politiku, lai izmantotu mezgla režīmu, norādot mezglu, uz kuru jāpārsūta galvenā rinda.
• Sinhronizē push migrācijas rindu.
• Kad migrēšana ir pabeigta, pagaidu politika tiek dzēsta. Sākotnējā HA politika stājas spēkā un tiek izveidots nepieciešamais spoguļu skaits.

Negatīvā puse ir tāda, ka šī pieeja var nedarboties, ja jums ir lielas rindas vai stingras atlaišanas prasības.

Tagad redzēsim, kā RabbitMQ klasteri darbojas ar tīkla nodalījumiem.

Savienojuma zudums

Sadalītās sistēmas mezgli ir savienoti ar tīkla saitēm, un tīkla saites var un tiks atvienotas. Pārtraukumu biežums ir atkarīgs no vietējās infrastruktūras vai izvēlētā mākoņa uzticamības. Jebkurā gadījumā sadalītajām sistēmām ir jāspēj ar tām tikt galā. Atkal mums ir izvēle starp pieejamību un konsekvenci, un atkal labā ziņa ir tā, ka RabbitMQ nodrošina abas iespējas (tikai ne vienlaikus).

Izmantojot RabbitMQ, mums ir divas galvenās iespējas:

• Atļaut loģisko dalījumu (smadzeņu sadalīšana). Tas nodrošina pieejamību, bet var izraisīt datu zudumu.
• Atspējot loģisko atdalīšanu. Var izraisīt īslaicīgu pieejamības zudumu atkarībā no tā, kā klienti savienojas ar kopu. Var izraisīt arī pilnīgu nepieejamību divu mezglu klasterī.

Bet kas ir loģiskā atdalīšana? Tas notiek, kad klasteris sadalās divās daļās tīkla savienojumu zuduma dēļ. Katrā pusē spoguļi tiek paaugstināti par meistaru, lai galu galā vienā rindā būtu vairāki meistari.

Rīsi. 17. Galvenā rinda un divi spoguļi, katrs atsevišķā mezglā. Tad notiek tīkla kļūme un viens spogulis tiek atvienots. Atdalītais mezgls redz, ka pārējie divi ir nokrituši, un reklamē savus spoguļus kapteinim. Tagad mums ir divas galvenās rindas, gan rakstāmās, gan lasāmās.

Ja izdevēji nosūta datus abiem galvenajiem, mēs iegūstam divas atšķirīgas rindas kopijas.

RabbitMQ dažādie režīmi nodrošina pieejamību vai konsekvenci.

Ignorēšanas režīms (noklusējums)

Šis režīms nodrošina pieejamību. Pēc savienojuma zaudēšanas notiek loģiska atdalīšana. Pēc savienojuma atjaunošanas administratoram ir jāizlemj, kuram nodalījumam piešķirt prioritāti. Zaudētāja puse tiks restartēta, un visi tajā pusē uzkrātie dati tiks zaudēti.

Rīsi. 18. Trīs izdevēji ir saistīti ar trim brokeriem. Iekšēji klasteris visus pieprasījumus novirza uz galveno rindu pakalpojumā Broker 2.

Tagad mēs zaudējam Brokeri 3. Viņš redz, ka citi brokeri ir atkrituši un paaugstina savu spoguli par meistaru. Tādā veidā notiek loģiska atdalīšana.

Rīsi. 19.Loģiskais dalījums (split-brain). Ieraksti atrodas divās galvenajās rindās, un abas kopijas atšķiras.

Savienojamība tiek atjaunota, bet loģiskā atdalīšana paliek. Administratoram manuāli jāizvēlas zaudētāja puse. Tālāk norādītajā gadījumā administrators atsāknē Broker 3. Visi ziņojumi, kurus viņam neizdevās pārsūtīt, tiek zaudēti.

Rīsi. 20. Administrators atspējo Broker 3.

Rīsi. 21. Administrators palaiž brokeri 3 un tas pievienojas klasterim, zaudējot visus tur atstātos ziņojumus.

Savienojuma zuduma laikā un pēc tā atjaunošanas klasteris un šī rinda bija pieejama lasīšanai un rakstīšanai.

Automātiskās dziedināšanas režīms

Darbojas līdzīgi kā Ignorēt režīms, izņemot to, ka pats klasteris pēc savienojuma sadalīšanas un atjaunošanas automātiski izvēlas zaudēto pusi. Zaudētāja puse atgriežas klasterī tukša, un rinda zaudē visus ziņojumus, kas tika nosūtīti tikai uz šo pusi.

Pauzējiet mazākuma režīmu

Ja mēs nevēlamies atļaut loģisko sadalīšanu, mūsu vienīgā iespēja ir atmest lasīšanu un rakstīšanu mazākajā pusē pēc klastera nodalījuma. Kad brokeris redz, ka tas atrodas mazākajā pusē, tas aptur darbu, tas ir, slēdz visus esošos savienojumus un atsakās no jauniem. Reizi sekundē tas pārbauda savienojuma atjaunošanu. Kad savienojums ir atjaunots, tas atsāk darbību un pievienojas klasterim.

Rīsi. 22. Trīs izdevēji ir saistīti ar trim brokeriem. Iekšēji klasteris visus pieprasījumus novirza uz galveno rindu pakalpojumā Broker 2.

Pēc tam 1. un 2. brokeris atdalās no brokera 3. Tā vietā, lai reklamētu savu spoguli par galveno, brokeris 3 aptur darbību un kļūst nepieejams.

Rīsi. 23. Broker 3 aptur, atvieno visus klientus un noraida savienojuma pieprasījumus.

Kad savienojums ir atjaunots, tas atgriežas klasterī.

Apskatīsim citu piemēru, kur galvenā rinda atrodas brokerī 3.

Rīsi. 24. Galvenā rinda brokerā 3.

Tad notiek tāds pats savienojuma zudums. Broker 3 pauzes, jo tas atrodas mazākajā pusē. No otras puses mezgli redz, ka Broker 3 ir nokritis, tāpēc vecākais spogulis no Brokers 1 un 2 tiek paaugstināts par meistaru.

Rīsi. 25. Pāreja uz Broker 2, ja Broker 3 nav pieejams.

Kad savienojums ir atjaunots, brokeris 3 pievienosies klasterim.

Rīsi. 26. Klasteris ir atgriezies normālā režīmā.

Šeit ir svarīgi saprast, ka mēs iegūstam konsekvenci, taču varam arī nodrošināt pieejamību, ja Mēs veiksmīgi pārvedīsim klientus uz lielāko daļu sadaļas. Lielākajai daļai situāciju es personīgi izvēlētos Pause Minority režīmu, taču tas tiešām ir atkarīgs no konkrētā gadījuma.

Lai nodrošinātu pieejamību, ir svarīgi nodrošināt, lai klienti veiksmīgi izveidotu savienojumu ar resursdatoru. Apskatīsim mūsu iespējas.

Klientu savienojamības nodrošināšana

Mums ir vairākas iespējas, kā novirzīt klientus uz galveno klastera daļu vai darba mezgliem (pēc viena mezgla kļūmes) pēc savienojuma zaudēšanas. Pirmkārt, atcerēsimies, ka noteikta rinda ir mitināta noteiktā mezglā, bet maršrutēšana un politikas tiek replicētas visos mezglos. Klienti var izveidot savienojumu ar jebkuru mezglu, un iekšējā maršrutēšana viņus novirzīs tur, kur viņiem ir jāiet. Bet, kad mezgls ir apturēts, tas noraida savienojumus, tāpēc klientiem ir jāpievienojas citam mezglam. Ja mezgls nokrīt, viņš vispār maz var darīt.

Mūsu iespējas:

• Klasterim var piekļūt, izmantojot slodzes līdzsvarotāju, kas vienkārši pāriet cauri mezgliem, un klienti mēģina atkārtoti izveidot savienojumu, līdz tas ir izdevies. Ja mezgls nedarbojas vai ir apturēts, mēģinājumi izveidot savienojumu ar šo mezglu neizdosies, bet nākamie mēģinājumi tiks novirzīti uz citiem serveriem (apkārtējā veidā). Tas ir piemērots īstermiņa savienojuma zuduma vai nolaistu servera gadījumā, kas tiks ātri atjaunots.
• Piekļūstiet klasterim, izmantojot slodzes līdzsvarotāju, un noņemiet apturētos/neizdevušos mezglus no saraksta, tiklīdz tie tiek atklāti. Ja mēs to darīsim ātri un klienti varēs atkārtoti mēģināt izveidot savienojumu, mēs sasniegsim pastāvīgu pieejamību.
• Sniedziet katram klientam visu mezglu sarakstu, un klients nejauši izvēlas vienu no tiem savienojuma laikā. Ja, mēģinot izveidot savienojumu, tiek parādīts kļūdas ziņojums, tas pāriet uz nākamo mezglu sarakstā, līdz tiek izveidots savienojums.
• Noņemiet trafiku no neveiksmīga/apturēta mezgla, izmantojot DNS. Tas tiek darīts, izmantojot nelielu TTL.

Atzinumi

RabbitMQ klasterēšanai ir savas priekšrocības un trūkumi. Nopietnākie trūkumi ir šādi:

• pievienojoties klasterim, mezgli izmet savus datus;
• bloķējot sinhronizāciju, rinda kļūst nepieejama.

Visi sarežģītie lēmumi izriet no šīm divām arhitektūras iezīmēm. Ja RabbitMQ varētu saglabāt datus, kad klasteris tiek atkārtoti pievienots, sinhronizācija būtu ātrāka. Ja tas varētu nebloķēt sinhronizāciju, tas labāk atbalstītu lielas rindas. Šo divu problēmu novēršana ievērojami uzlabotu RabbitMQ kā kļūmju izturīgas un ļoti pieejamas ziņojumapmaiņas tehnoloģijas veiktspēju. Es vilcināšos ieteikt RabbitMQ ar klasterizāciju šādās situācijās:

• Neuzticams tīkls.
• Neuzticama krātuve.
• Ļoti garas rindas.

Runājot par augstas pieejamības iestatījumiem, ņemiet vērā tālāk minēto.

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (Vai autoheal)
• pastāvīgas ziņas
• nodrošināt klientu savienojumu ar aktīvo mezglu, ja kāds mezgls neizdodas

Lai nodrošinātu konsekvenci (datu drošību), ņemiet vērā šādus iestatījumus:

• Izdevējs apstiprina un manuāli apstiprina patērētāju puses
• ha-promote-on-failure=when-synced, ja izdevēji vēlāk var mēģināt vēlreiz un ja jums ir ļoti uzticama krātuve! Citādi likt =always.
• ha-sync-mode=automatic (bet lielām neaktīvām rindām var būt nepieciešams manuālais režīms; arī apsveriet, vai nepieejamības dēļ ziņojumi netiks pazaudēti)
• Apturēt mazākuma režīmu
• pastāvīgas ziņas

Mēs vēl neesam aptvēruši visus defektu tolerances un augstas pieejamības jautājumus; piemēram, kā droši veikt administratīvās procedūras (piemēram, slīdošos atjauninājumus). Mums ir arī jārunā par federāciju un Shovel spraudni.

Ja esmu vēl kaut ko palaidis garām, lūdzu, dariet man zināmu.

Skatīt arī manu post, kur es veicu haosu RabbitMQ klasterī, izmantojot Docker un Blockade, lai pārbaudītu dažus šajā rakstā aprakstītos ziņojumu zaudēšanas scenārijus.

Iepriekšējie raksti sērijā:
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

Avots: www.habr.com