Toleremo al misfunkciadoj kaj alta havebleco estas grandaj temoj, do ni dediĉos apartajn artikolojn al RabbitMQ kaj Kafka. Tiu ĉi artikolo temas pri RabbitMQ, kaj la venonta temas pri Kafka, kompare kun RabbitMQ. Ĉi tio estas longa artikolo, do komfortiĝu.
Ni rigardu la strategiojn pri misfunkciado, konsistenco kaj alta havebleco (HA) kaj la kompromisoj kiujn ĉiu strategio faras. RabbitMQ povas funkcii per areto de nodoj - kaj tiam estas klasifikita kiel distribuita sistemo. Kiam temas pri distribuitaj sistemoj, ni ofte parolas pri konsistenco kaj havebleco.
Ĉi tiuj konceptoj priskribas kiel sistemo kondutas kiam ĝi malsukcesas. Malsukceso de retkonekto, fiasko de servilo, malfunkcio de malmola disko, servilo provizora malhavebleco pro rubkolekto, paka perdo aŭ malrapidiĝo de retkonekto. Ĉio ĉi povas konduki al datumperdo aŭ konfliktoj. Montriĝas, ke estas preskaŭ neeble konstrui sistemon kiu estas kaj tute konsekvenca (neniu datumperdo, neniu datuma diverĝo) kaj disponebla (akceptos legadon kaj skribadon) por ĉiuj malsukcesaj scenaroj.
Ni vidos, ke konsistenco kaj havebleco estas ĉe kontraŭaj finoj de la spektro, kaj vi devas elekti, kiun manieron optimumigi. La bona novaĵo estas, ke kun RabbitMQ ĉi tiu elekto eblas. Vi havas ĉi tiujn specojn de "nerdaj" leviloj por ŝanĝi la ekvilibron al pli granda konsistenco aŭ pli granda alirebleco.
Ni atentos specialan al kiuj agordoj kondukas al datumperdo pro konfirmitaj registroj. Estas ĉeno de respondeco inter eldonistoj, makleristoj kaj konsumantoj. Post kiam la mesaĝo estas transdonita al la makleristo, estas lia tasko ne perdi la mesaĝon. Kiam la makleristo agnoskas la ricevon de la eldonejo de la mesaĝo, ni ne atendas ke ĝi estos perdita. Sed ni vidos, ke tio efektive povas okazi depende de via makleristo kaj eldonejo agordo.
Single Node Resilience Primitives
Rezigna Vidovikado/Vado
Estas du specoj de vostoj en RabbitMQ: daŭraj kaj ne-daŭraj. Ĉiuj atendovicoj estas konservitaj en la Mnesia datumbazo. Daŭreblaj atendovicoj estas re-reklamitaj ĉe noda ekfunkciigo kaj tiel postvivas rekomencojn, sistemkraŝojn aŭ servilkraŝojn (kondiĉe la datenoj estas persistitaj). Ĉi tio signifas, ke kondiĉe ke vi deklaras ke enrutado (interŝanĝo) kaj vico estas rezistema, la vica/voja infrastrukturo revenos interrete.
Volatilaj atendovicoj kaj vojigo estas forigitaj kiam la nodo estas rekomencita.
Konstantaj mesaĝoj
Nur ĉar vico estas daŭrema ne signifas ke ĉiuj ĝiaj mesaĝoj postvivos nodan rekomencon. Nur mesaĝoj fiksitaj de la eldonejo kiel daŭrigebla (persistenta). Konstantaj mesaĝoj kreas plian ŝarĝon sur la makleristo, sed se mesaĝperdo estas neakceptebla, tiam ne ekzistas alia eblo.
Rizo. 1. Daŭrigebla matrico
Agrupiĝo kun vostospegulado
Por postvivi la perdon de makleristo, ni bezonas redundon. Ni povas kombini plurajn RabbitMQ-nodojn en areton, kaj poste aldoni plian redundon per reproduktado de vostoj inter pluraj nodoj. Tiel, se unu nodo malsukcesas, ni ne perdas datumojn kaj restas disponeblaj.
Vicospegulado:
- unu ĉefa atendovico (majstro), kiu ricevas ĉiujn skribajn kaj legajn komandojn
- unu aŭ pluraj speguloj kiuj ricevas ĉiujn mesaĝojn kaj metadatenojn de la ĉefa atendovico. Ĉi tiuj speguloj ne estas tie por grimpi, sed nur por redundo.
Rizo. 2. Vicospegulado
Spegulo estas agordita de la taŭga politiko. En ĝi vi povas elekti la reproduktan koeficienton kaj eĉ la nodojn, sur kiuj la vico devas troviĝi. Ekzemploj:
ha-mode: allha-mode: exactly, ha-params: 2(unu majstro kaj unu spegulo)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
Konfirmo de la eldonisto
Por atingi konsekvencan registradon, Eldonisto Konfirmoj estas postulataj. Sen ili, estas risko ke mesaĝoj perdiĝas. Konfirmo estas sendita al la eldonisto post kiam la mesaĝo estas skribita al disko. RabbitMQ skribas mesaĝojn al disko ne post ricevo, sed periode, en la regiono de kelkcent milisekundoj. Kiam vico estas spegulita, agnosko estas sendita nur post kiam ĉiuj speguloj ankaŭ skribis sian kopion de la mesaĝo al disko. Ĉi tio signifas, ke uzi konfirmojn aldonas latentecon, sed se datumsekureco estas grava, tiam ili estas necesaj.
Malsukcesa atendovico
Kiam makleristo forlasas aŭ kraŝas, ĉiuj vicogvidantoj (majstroj) sur tiu nodo kraŝas kune kun ĝi. La areto tiam elektas la plej malnovan spegulon de ĉiu majstro kaj antaŭenigas ĝin kiel la nova majstro.
Rizo. 3. Multoblaj spegulaj vostoj kaj iliaj politikoj
Makleristo 3 iras malsupren. Notu, ke la Queue C spegulo sur Broker 2 estas promociita al majstro. Rimarku ankaŭ, ke nova spegulo estis kreita por Queue C ĉe Broker 1. RabbitMQ ĉiam provas konservi la reproduktan faktoron specifitan en viaj politikoj.
Rizo. 4. Makleristo 3 malsukcesas, kaŭzante vicon C malsukcesi
La sekva Broker 1 falas! Restas al ni nur unu makleristo. La Queue B-spegulo estas promociita al majstro.
Fig. Xnumx
Ni revenis Makleristo 1. Sendepende de kiom bone la datumoj postvivas la perdon kaj reakiron de la makleristo, ĉiuj spegulitaj vostomesaĝoj estas forĵetitaj post rekomenco. Ĉi tio gravas noti ĉar estos konsekvencoj. Ni rigardos ĉi tiujn implicojn baldaŭ. Do Broker 1 nun estas membro de la areto denove, kaj la areto provas plenumi la politikojn kaj tial kreas spegulojn sur Broker 1.
En ĉi tiu kazo, la perdo de Broker 1 estis kompleta, same kiel la datumoj, do la nespegulita Queue B estis tute perdita.
Rizo. 6. Makleristo 1 revenas al servo
Makleristo 3 estas denove enreta, do vicoj A kaj B reakiras la spegulojn kreitajn sur ĝi por kontentigi siajn HA-politikojn. Sed nun ĉiuj ĉefaj atendovicoj estas sur unu nodo! Ĉi tio ne estas ideala, egala distribuo inter nodoj estas pli bona. Bedaŭrinde, ĉi tie ne ekzistas multe da ebloj por reekvilibrigi majstrojn. Ni revenos al ĉi tiu afero poste ĉar ni unue devas rigardi la vicsinkronigon.
Rizo. 7. Makleristo 3 revenas al servo. Ĉiuj ĉefaj atendovicoj sur unu nodo!
Do nun vi devus havi ideon pri kiel speguloj provizas redundon kaj misfunkciadon. Ĉi tio certigas haveblecon en la okazaĵo de ununura noda fiasko kaj protektas kontraŭ datumperdo. Sed ni ankoraŭ ne finis, ĉar fakte ĝi estas multe pli komplika.
Sinkondi
Kreante novan spegulon, ĉiuj novaj mesaĝoj ĉiam estos reproduktitaj al ĉi tiu spegulo kaj al iuj aliaj. Koncerne la ekzistantajn datumojn en la majstra vosto, ni povas reprodukti ĝin al nova spegulo, kiu fariĝas kompleta kopio de la majstro. Ni ankaŭ povas elekti ne reprodukti ekzistantajn mesaĝojn kaj lasi la ĉefvicon kaj la novan spegulon konverĝi en tempo, kun novaj mesaĝoj alvenantaj ĉe la vosto kaj ekzistantaj mesaĝoj forlasantaj la kapon de la ĉefvico.
Ĉi tiu sinkronigo estas farita aŭtomate aŭ permane kaj estas administrita per vicpolitiko. Ni rigardu ekzemplon.
Ni havas du spegulajn atendovicojn. Queue A estas sinkronigita aŭtomate, kaj Queue B estas sinkronigita permane. Ambaŭ vicoj enhavas dek mesaĝojn.
Rizo. 8. Du vostoj kun malsamaj sinkronigaj reĝimoj
Nun ni perdas Broker 3.
Rizo. 9. Makleristo 3 falis
Makleristo 3 revenas al servo. La areto kreas spegulon por ĉiu atendovico sur la nova nodo kaj aŭtomate sinkronigas la novan Queue A kun la majstro. Tamen, la spegulo de la nova Queue B restas malplena. Tiel ni havas plenan redundon en Queue A kaj nur unu spegulon por ekzistantaj Queue B mesaĝoj.
Rizo. 10. La nova spegulo de Queue A ricevas ĉiujn ekzistantajn mesaĝojn, sed la nova spegulo de Queue B ne.
Dek pliaj mesaĝoj alvenas en ambaŭ atendovicoj. Broker 2 tiam kraŝas kaj Queue A ruliĝas reen al la plej malnova spegulo, kiu estas sur Broker 1. Ne estas datumperdo kiam ĝi malsukcesas. En Queue B, ekzistas dudek mesaĝoj en la majstro kaj nur dek en la spegulo ĉar tiu atendovico neniam reproduktis la originajn dek mesaĝojn.
Rizo. 11. Queue A ruliĝas reen al Broker 1 sen perdi mesaĝojn
Dek pliaj mesaĝoj alvenas en ambaŭ atendovicoj. Nun kraŝas Broker 1. Queue A facile ŝanĝas al la spegulo sen perdi mesaĝojn. Tamen, Queue B havas problemojn. Je ĉi tiu punkto ni povas optimumigi aŭ haveblecon aŭ konsistencon.
Se ni volas optimumigi alireblecon, tiam la politiko ha-promoti-sur-malsukceso devus esti instalita en ĉiam. Ĉi tiu estas la defaŭlta valoro, do vi tute ne povas specifi la politikon. En ĉi tiu kazo, ni esence permesas malsukcesojn en nesinkronigitaj speguloj. Ĉi tio kaŭzos mesaĝojn perdi, sed la vico restos legebla kaj skribebla.
Rizo. 12. Queue A estas rulita reen al Broker 3 sen perdi mesaĝojn. Queue B revenas al Broker 3 kun dek mesaĝoj perditaj
Ni ankaŭ povas instali ha-promote-on-failure en signifon when-synced. En ĉi tiu kazo, anstataŭ reveni al la spegulo, la atendovico atendos ĝis Broker 1 kun siaj datumoj revenos al interreta reĝimo. Post kiam ĝi revenas, la ĉefa atendovico estas reen sur Broker 1 sen ia datumperdo. Havebleco estas oferita por sekureco de datumoj. Sed ĉi tio estas riska reĝimo, kiu eĉ povas konduki al kompleta perdo de datumoj, kiun ni rigardos baldaŭ.
Rizo. 13. Queue B restas neatingebla post perdo de Broker 1
Vi eble demandis, "Ĉu estas pli bone neniam uzi aŭtomatan sinkronigon?" La respondo estas, ke sinkronigado estas bloka operacio. Dum sinkronigado, la ĉefa vico ne povas fari ajnajn legajn aŭ skribajn operaciojn!
Ni rigardu ekzemplon. Nun ni havas tre longajn vicojn. Kiel ili povas kreski al tia grandeco? Pro pluraj kialoj:
- Vicoj ne estas aktive uzataj
- Ĉi tiuj estas altrapidaj atendovicoj, kaj nun konsumantoj malrapidas
- Temas pri altrapidaj vicoj, okazis problemo kaj konsumantoj atingas
Rizo. 14. Du grandaj vostoj kun malsamaj sinkronigaj reĝimoj
Nun Broker 3 falas.
Rizo. 15. Makleristo 3 falas, lasante unu majstron kaj spegulon en ĉiu atendovico
Broker 3 revenas interrete kaj novaj speguloj estas kreitaj. Ĉefa Queue A komencas reprodukti ekzistantajn mesaĝojn al la nova spegulo, kaj dum ĉi tiu tempo la Queue estas neatingebla. Necesas du horoj por reprodukti la datumojn, rezultigante du horojn da malfunkcio por ĉi tiu Vico!
Tamen, Queue B restas havebla dum la tuta periodo. Ŝi oferis iom da redundo por alirebleco.
Rizo. 16. Vico restas neatingebla dum sinkronigado
Post du horoj, Queue A ankaŭ iĝas havebla kaj povas komenci akcepti legadojn kaj skribaĵojn denove.
Ĝisdatigoj
Ĉi tiu blokada konduto dum sinkronigado malfaciligas ĝisdatigi aretojn kun tre grandaj atendovicoj. En iu momento, la majstra nodo devas esti rekomencita, kio signifas aŭ ŝanĝi al spegulo aŭ malŝalti la atendovicon dum la servilo estas ĝisdatigita. Se ni elektas transiri, ni perdos mesaĝojn se la speguloj ne estas sinkronigitaj. Defaŭlte, dum makleristo-malfunkcio, malsukceso al nesinkronigita spegulo ne estas farita. Ĉi tio signifas, ke tuj kiam la makleristo revenas, ni ne perdas mesaĝojn, la sola damaĝo estis simpla vosto. Reguloj de konduto kiam makleristo estas malkonektita estas fiksitaj de politiko ha-promote-on-shutdown. Vi povas agordi unu el du valoroj:
always= transiro al nesinkronigitaj speguloj estas ebligitawhen-synced= transiro al sinkronigita spegulo nur, alie la vico iĝas nelegebla kaj neskribebla. La atendovico revenas al servo tuj kiam la makleristo revenas
Unu maniero aŭ alia, kun grandaj vostoj vi devas elekti inter datumperdo kaj malhavebleco.
Kiam Havebleco Plibonigas Datuman Sekurecon
Estas unu plia komplikaĵo por konsideri antaŭ ol fari decidon. Dum aŭtomata sinkronigo estas pli bona por redundo, kiel ĝi influas sekurecon de datumoj? Kompreneble, kun pli bona redundo, RabbitMQ malpli verŝajne perdos ekzistantajn mesaĝojn, sed kio pri novaj mesaĝoj de eldonejoj?
Ĉi tie vi devas konsideri la jenajn:
- Ĉu la eldonisto povus simple resendi eraron kaj havi la kontraŭfluan servon aŭ uzanton provi denove poste?
- Ĉu la eldonisto povas konservi la mesaĝon loke aŭ en datumbazo por provi denove poste?
Se la eldonisto povas nur forĵeti la mesaĝon, tiam fakte, plibonigo de alirebleco ankaŭ plibonigas la sekurecon de datumoj.
Tiel oni devas serĉi ekvilibron, kaj la solvo dependas de la specifa situacio.
Problemoj kun ha-promote-on-failure=kiam-sinkronigita
Ideo ha-promoti-sur-malsukceso= kiam-sinkronigita estas ke ni malhelpas ŝanĝi al nesinkronigita spegulo kaj tiel evitas datumperdon. La vico restas nelegebla aŭ skribebla. Anstataŭe, ni provas reakiri la kraŝintan makleriston kun ĝiaj datumoj sendifektaj por ke ĝi povu rekomenci funkcii kiel majstro sen datumperdo.
Sed (kaj ĉi tio estas granda sed) se la makleristo perdis siajn datumojn, tiam ni havas grandan problemon: la vosto estas perdita! Ĉiuj datumoj malaperis! Eĉ se vi havas spegulojn, kiuj plejparte atingas la ĉefan vicon, ankaŭ tiuj speguloj estas forĵetitaj.
Por re-aldoni nodon kun la sama nomo, ni diras al la areto forgesi la perditan nodon (kun la komando rabbitmqctl forget_cluster_node) kaj komencu novan makleriston kun la sama gastiga nomo. Dum la areto memoras la perditan nodon, ĝi memoras la malnovan atendovicon kaj nesinkronigitajn spegulojn. Kiam areto estas rakontita forgesi orfigitan nodon, tiu atendovico ankaŭ estas forgesita. Nun ni devas denove deklari ĝin. Ni perdis ĉiujn datumojn, kvankam ni havis spegulojn kun parta aro de datumoj. Pli bone estus ŝanĝi al nesinkronigita spegulo!
Tial, mana sinkronigo (kaj malsukceso sinkronigi) en kombinaĵo kun ha-promote-on-failure=when-synced, laŭ mi, sufiĉe riska. La dokumentoj diras, ke ĉi tiu opcio ekzistas por datuma sekureco, sed ĝi estas duobla tranĉilo.
Majstra rebalancado
Kiel promesite, ni revenas al la problemo de la amasiĝo de ĉiuj majstroj sur unu aŭ pluraj nodoj. Ĉi tio eĉ povas okazi kiel rezulto de ruliĝanta areto ĝisdatigo. En tri-noda areto, ĉiuj majstraj atendovicoj akumuliĝos sur unu aŭ du nodoj.
Reekvilibrigi majstrojn povas esti problema pro du kialoj:
- Ne ekzistas bonaj iloj por fari rebalancadon
- Sinkronigado de vostovico
Estas tria partio por rebalancado , kiu ne estas oficiale subtenata. Koncerne triajn kromaĵojn en la manlibro de RabbitMQ : "La kromaĵo provizas kelkajn pliajn agordajn kaj raportajn ilojn, sed ne estas subtenata aŭ kontrolita de la teamo RabbitMQ. Uzu je via propra risko."
Estas alia lertaĵo por movi la ĉefvicon tra HA-politikoj. La manlibro mencias por ĉi tio. Ĝi funkcias tiel:
- Forigas ĉiujn spegulojn uzante provizoran politikon, kiu havas pli altan prioritaton ol la ekzistanta HA-politiko.
- Ŝanĝas la provizoran politikon de HA por uzi nodan reĝimon, precizigante la nodon al kiu la majstra atendovico devas esti transdonita.
- Sinkronigas la atendovicon por puŝa migrado.
- Post kiam migrado estas kompleta, forigas la provizoran politikon. La komenca HA-politiko efektiviĝas kaj la bezonata nombro da speguloj estas kreita.
La malavantaĝo estas, ke ĉi tiu aliro eble ne funkcias se vi havas grandajn atendovicojn aŭ striktajn redundajn postulojn.
Nun ni vidu kiel RabbitMQ-aretoj funkcias kun retaj sekcioj.
Perdo de konektebleco
La nodoj de distribuita sistemo estas konektitaj per retaj ligiloj, kaj retaj ligiloj povas kaj estos malkonektitaj. La ofteco de malfunkcioj dependas de la loka infrastrukturo aŭ la fidindeco de la elektita nubo. Ĉiukaze, distribuitaj sistemoj devas povi trakti ilin. Denove ni havas elekton inter havebleco kaj konsistenco, kaj denove la bona novaĵo estas, ke RabbitMQ disponigas ambaŭ eblojn (nur ne samtempe).
Kun RabbitMQ ni havas du ĉefajn eblojn:
- Permesu logikan dividon (split-brain). Ĉi tio certigas haveblecon, sed povas kaŭzi perdon de datumoj.
- Malebligu logikan apartigon. Povas rezultigi mallongdaŭran perdon de havebleco depende de kiel klientoj konektas al la areto. Povas ankaŭ konduki al kompleta malhavebleco en du-noda areto.
Sed kio estas logika apartigo? Jen kiam areto disiĝas en du pro perdo de retkonektoj. Sur ĉiu flanko, la speguloj estas promociitaj al majstro, tiel ke ekzistas poste pluraj majstroj per turno.
Rizo. 17. Ĉefa vosto kaj du speguloj, ĉiu sur aparta nodo. Tiam reta fiasko okazas kaj unu spegulo iĝas dekroĉita. La apartigita nodo vidas ke la aliaj du defalis kaj antaŭenigas siajn spegulojn al la majstro. Ni nun havas du ĉefajn atendovicojn, kaj skribeblajn kaj legeblajn.
Se eldonejoj sendas datumojn al ambaŭ majstroj, ni finas kun du diverĝaj kopioj de la vico.
La malsamaj reĝimoj de RabbitMQ disponigas aŭ haveblecon aŭ konsistencon.
Ignori reĝimon (defaŭlte)
Ĉi tiu reĝimo certigas alireblecon. Post la perdo de konektebleco, okazas logika disiĝo. Post kiam konektebleco estas restarigita, la administranto devas decidi al kiu sekcio por doni prioritaton. La perdanta flanko estos rekomencita kaj ĉiuj amasigitaj datumoj sur tiu flanko estos perditaj.
Rizo. 18. Tri eldonejoj estas asociitaj kun tri makleristoj. Interne, la areto direktas ĉiujn petojn al la ĉefa atendovico sur Broker 2.
Nun ni perdas Broker 3. Li vidas, ke aliaj makleristoj defalis kaj promocias sian spegulon al la majstro. Tiel okazas logika disiĝo.
Rizo. 19. Logika divido (split-cerbo). Rekordoj eniras du ĉefajn atendovicojn, kaj la du kopioj diverĝas.
Konektebleco estas restarigita, sed logika apartigo restas. La administranto devas permane elekti la perdantan flankon. En la suba kazo, la administranto rekomencas Broker 3. Ĉiuj mesaĝoj, kiujn li ne sukcesis transdoni, estas perditaj.
Rizo. 20. La administranto malŝaltas Broker 3.
Rizo. 21. La administranto komencas Broker 3 kaj ĝi aliĝas al la areto, perdante ĉiujn mesaĝojn, kiuj estis lasitaj tie.
Dum la perdo de konektebleco kaj post ĝia restarigo, la areto kaj ĉi tiu vico estis disponeblaj por legado kaj skribo.
Aŭtomata resaniga reĝimo
Funkcias simile al Ignori reĝimo, krom ke la areto mem aŭtomate elektas la perdantan flankon post disigo kaj restarigo de konektebleco. La perdanta flanko revenas al la areto malplena, kaj la atendovico perdas ĉiujn mesaĝojn kiuj estis senditaj nur al tiu flanko.
Paŭzi Minoritatan Reĝimon
Se ni ne volas permesi logikan dispartigon, tiam nia sola opcio estas forĵeti legadojn kaj skribojn sur la pli malgranda flanko post la grapoldisko. Kiam la makleristo vidas, ke ĝi estas sur la pli malgranda flanko, ĝi malakceptas laboron, tio estas, ĝi fermas ĉiujn ekzistantajn konektojn kaj rifuzas iujn novajn. Unufoje por sekundo ĝi kontrolas por konektebleca restarigo. Post kiam konektebleco estas restarigita, ĝi rekomencas operacion kaj aliĝas al la areto.
Rizo. 22. Tri eldonejoj estas asociitaj kun tri makleristoj. Interne, la areto direktas ĉiujn petojn al la ĉefa atendovico sur Broker 2.
Makleristoj 1 kaj 2 tiam disiĝas de Broker 3. Anstataŭ antaŭenigi sian spegulon al majstro, Broker 3 suspendas kaj iĝas neatingebla.
Rizo. 23. Makleristo 3 paŭzas, malkonektas ĉiujn klientojn kaj malakceptas konektajn petojn.
Post kiam konektebleco estas restarigita, ĝi revenas al la areto.
Ni rigardu alian ekzemplon, kie la ĉefa vico estas sur Broker 3.
Rizo. 24. Ĉefa vosto ĉe Broker 3.
Tiam okazas la sama perdo de konektebleco. Makleristo 3 paŭzas ĉar ĝi estas sur la pli malgranda flanko. Aliflanke, la nodoj vidas, ke Broker 3 defalis, do la pli malnova spegulo de Brokers 1 kaj 2 estas promociita al majstro.
Rizo. 25. Transiro al Broker 2 se Broker 3 ne disponeblas.
Kiam konektebleco estas restarigita, Broker 3 aliĝos al la areto.
Rizo. 26. La areto revenis al normala funkciado.
La grava afero por kompreni ĉi tie estas, ke ni ricevas konsistencon, sed ni ankaŭ povas akiri haveblecon, se Ni sukcese translokigos klientojn al plejparto de la sekcio. Por plej multaj situacioj, mi persone elektus la reĝimon de Paŭzo Minoritato, sed ĝi vere dependas de la individua kazo.
Por certigi haveblecon, gravas certigi, ke klientoj sukcese konektas al la gastiganto. Ni rigardu niajn eblojn.
Certigante Klientan Konektecon
Ni havas plurajn eblojn kiel direkti klientojn al la ĉefa parto de la areto aŭ al labornodoj (post kiam unu nodo malsukcesas) post perdo de konektebleco. Unue, ni memoru, ke specifa vosto estas gastigita sur specifa nodo, sed vojigo kaj politikoj estas reproduktitaj tra ĉiuj nodoj. Klientoj povas konektiĝi al iu ajn nodo, kaj interna vojigo direktos ilin kien ili devas iri. Sed kiam nodo estas malakceptita, ĝi malakceptas konektojn, do klientoj devas konektiĝi al alia nodo. Se la nodo defalas, estas malmulte, kion li povas fari.
Niaj elektoj:
- La areto estas alirita per ŝarĝbalancilo, kiu simple cirkulas tra la nodoj kaj klientoj reprovas konekti ĝis sukceso. Se nodo estas malfunkcia aŭ suspendita, tiam provoj konekti al tiu nodo malsukcesos, sed postaj provoj iros al aliaj serviloj (en cirkla-subskribolista modo). Ĉi tio taŭgas por mallongdaŭra perdo de konektebleco aŭ malfunkciigita servilo, kiu estos rapide restarigita.
- Aliru la areton per ŝarĝbalancilo kaj forigu suspenditajn/malsukcesajn nodojn de la listo tuj kiam ili estas detektitaj. Se ni faros tion rapide, kaj se klientoj povas reprovi la konekton, tiam ni atingos konstantan haveblecon.
- Donu al ĉiu kliento liston de ĉiuj nodoj, kaj la kliento hazarde elektas unu el ili dum la konekto. Se ĝi ricevas eraron kiam ĝi provas konektiĝi, ĝi moviĝas al la sekva nodo en la listo ĝis ĝi konektas.
- Forigu trafikon de malsukcesa/interrompita nodo uzante DNS. Ĉi tio estas farita uzante malgrandan TTL.
trovoj
RabbitMQ-grupo havas siajn avantaĝojn kaj malavantaĝojn. La plej gravaj malavantaĝoj estas tio:
- aliĝante al areto, nodoj forĵetas siajn datumojn;
- blokado de sinkronigado igas la atendovico iĝi neatingebla.
Ĉiuj malfacilaj decidoj devenas de ĉi tiuj du arkitekturaj trajtoj. Se RabbitMQ povus ŝpari datumojn kiam la areto estas rekunigita, tiam sinkronigo estus pli rapida. Se ĝi estus kapabla je ne-bloka sinkronigo, ĝi pli bone subtenus grandajn atendovicojn. Ripari ĉi tiujn du problemojn multe plibonigus la agadon de RabbitMQ kiel mistolerema kaj tre havebla mesaĝa teknologio. Mi hezitus rekomendi RabbitMQ kun clustering en la sekvaj situacioj:
- Nefidinda reto.
- Nefidinda stokado.
- Tre longaj vicoj.
Se temas pri agordoj de alta havebleco, konsideru la jenajn:
ha-promote-on-failure=alwaysha-sync-mode=manualcluster_partition_handling=ignore(aŭautoheal)- persistaj mesaĝoj
- certigu, ke klientoj konektas al la aktiva nodo kiam iu nodo malsukcesas
Por konsistenco (datumsekureco), konsideru la sekvajn agordojn:
- Eldonisto Konfirmas kaj Manlibron Agnoskoj sur la konsumanto flanko
ha-promote-on-failure=when-synced, se la eldonejoj povas provi denove poste kaj se vi havas tre fidindan stokadon! Alie metu=always.ha-sync-mode=automatic(sed por grandaj neaktivaj vostoj povas esti bezonata mana reĝimo; ankaŭ konsideru ĉu nehavebleco kaŭzos mesaĝojn perdi)- Paŭzi minoritatan reĝimon
- persistaj mesaĝoj
Ni ankoraŭ ne kovris ĉiujn aferojn pri faŭltoleremo kaj alta havebleco; ekzemple, kiel sekure plenumi administrajn procedurojn (kiel ruliĝantaj ĝisdatigoj). Ni devas ankaŭ paroli pri federacio kaj la kromaĵo Ŝovelilo.
Se mi maltrafis ion alian, bonvolu sciigi min.
Vidu ankaŭ mian , kie mi faras ĥaoson sur RabbitMQ-areto uzante Docker kaj Blockade por testi kelkajn el la mesaĝaj perdscenaroj priskribitaj en ĉi tiu artikolo.
Antaŭaj artikoloj en la serio:
numero 1 -
numero 2 -
numero 3 -
fonto: www.habr.com