Uvumilivu wa makosa na upatikanaji wa juu ni mada kubwa, kwa hivyo tutatoa makala tofauti kwa RabbitMQ na Kafka. Nakala hii inahusu RabbitMQ, na inayofuata inahusu Kafka, kwa kulinganisha na RabbitMQ. Hii ni makala ndefu, kwa hivyo jifanye vizuri.
Hebu tuangalie mikakati ya kuvumilia makosa, uthabiti, na upatikanaji wa juu (HA) na usuluhishi ambao kila mkakati hufanya. RabbitMQ inaweza kukimbia kwenye kundi la nodi - na kisha kuainishwa kama mfumo uliosambazwa. Linapokuja suala la mifumo iliyosambazwa, mara nyingi tunazungumza juu ya uthabiti na upatikanaji.
Dhana hizi zinaelezea jinsi mfumo unavyofanya kazi unaposhindwa. Kushindwa kwa muunganisho wa mtandao, kushindwa kwa seva, hitilafu ya diski kuu, kutopatikana kwa seva kwa muda kwa sababu ya mkusanyiko wa takataka, kupoteza pakiti, au kupungua kwa muunganisho wa mtandao. Yote hii inaweza kusababisha upotezaji wa data au migogoro. Inabadilika kuwa haiwezekani kuweka mfumo ambao ni sawa kabisa (hakuna upotezaji wa data, hakuna tofauti ya data) na inapatikana (itakubali kusoma na kuandika) kwa hali zote za kutofaulu.
Tutaona kwamba uthabiti na upatikanaji ziko kwenye ncha tofauti za wigo, na unahitaji kuchagua njia ya kuboresha. Habari njema ni kwamba kwa RabbitMQ chaguo hili linawezekana. Una aina hizi za viunzi vya "nerdy" ili kuhamisha salio kuelekea uthabiti mkubwa au ufikivu zaidi.
Tutazingatia maalum ambayo usanidi husababisha upotezaji wa data kwa sababu ya rekodi zilizothibitishwa. Kuna mlolongo wa uwajibikaji kati ya wachapishaji, madalali na watumiaji. Mara baada ya ujumbe kutumwa kwa wakala, ni kazi yake kutopoteza ujumbe. Wakati wakala anakubali kupokea kwa mchapishaji ujumbe, hatutarajii kuwa utapotea. Lakini tutaona kwamba hii inaweza kutokea kulingana na usanidi wako wa wakala na mchapishaji.
Kanuni za Ustahimilivu wa Njia Moja
Kupanga Foleni/Upangaji Ustahimilivu
Kuna aina mbili za foleni katika RabbitMQ: ya kudumu na isiyo ya kudumu. Foleni zote zimehifadhiwa kwenye hifadhidata ya Mnesia. Foleni zinazodumu hutangazwa tena mwanzoni mwa nodi na hivyo kunusurika kuanzishwa upya, kuacha kufanya kazi kwa mfumo, au kuacha kufanya kazi kwa seva (ilimradi data iendelee). Hii inamaanisha kuwa mradi tu utangaza uelekezaji (kubadilishana) na foleni kuwa thabiti, miundombinu ya foleni/uelekezaji itarejea mtandaoni.
Foleni tete na uelekezaji huondolewa wakati nodi imewashwa upya.
Ujumbe unaoendelea
Kwa sababu tu foleni ni ya kudumu haimaanishi kuwa ujumbe wake wote utanusurika kuanzishwa upya kwa nodi. Ujumbe tu uliowekwa na mchapishaji kama endelevu (inayoendelea). Ujumbe unaoendelea huunda mzigo wa ziada kwa wakala, lakini ikiwa upotezaji wa ujumbe haukubaliki, basi hakuna chaguo lingine.
Mchele. 1. Matrix ya kudumu
Kuunganisha kwa kuakisi foleni
Ili kunusurika kupotea kwa wakala, tunahitaji kupunguzwa kazi. Tunaweza kuchanganya nodi nyingi za RabbitMQ kwenye kundi, na kisha kuongeza upungufu wa ziada kwa kuiga foleni kati ya nodi nyingi. Kwa njia hii, ikiwa nodi moja itashindwa, hatupotezi data na kubaki inapatikana.
Uakisi wa foleni:
- foleni moja kuu (bwana), ambayo inapokea amri zote za kuandika na kusoma
- kioo kimoja au zaidi zinazopokea ujumbe na metadata zote kutoka kwa foleni kuu. Vioo hivi havipo kwa ajili ya kuongeza, lakini kwa ajili ya upunguzaji.
Mchele. 2. Uakisi wa foleni
Kuakisi huwekwa na sera inayofaa. Ndani yake unaweza kuchagua mgawo wa replication na hata nodes ambayo foleni inapaswa kuwa iko. Mifano:
ha-mode: allha-mode: exactly, ha-params: 2(bwana mmoja na kioo kimoja)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
Mchapishaji uthibitisho
Ili kufikia rekodi thabiti, Uthibitishaji wa Mchapishaji unahitajika. Bila wao, kuna hatari ya ujumbe kupotea. Uthibitisho unatumwa kwa mchapishaji baada ya ujumbe kuandikwa kwenye diski. RabbitMQ huandika ujumbe kwa diski si baada ya kupokea, lakini kwa mara kwa mara, katika eneo la milliseconds mia kadhaa. Wakati foleni inaakisiwa, uthibitisho unatumwa tu baada ya vioo vyote pia kuandika nakala yao ya ujumbe kwenye diski. Hii ina maana kwamba kutumia uthibitishaji kunaongeza muda, lakini ikiwa usalama wa data ni muhimu, basi ni muhimu.
Foleni ya kushindwa
Dalali anapoacha kazi au kuanguka, viongozi wote wa foleni (mabwana) kwenye nodi hiyo huanguka pamoja nayo. Kikundi kisha huchagua kioo cha zamani zaidi cha kila bwana na kukikuza kama bwana mpya.
Mchele. 3. Foleni nyingi za vioo na sera zake
Broker 3 huenda chini. Kumbuka kuwa kioo cha Foleni C kwenye Dalali 2 kinapandishwa hadhi kuwa bora. Pia kumbuka kuwa kioo kipya kimeundwa kwa ajili ya Foleni C kwenye Dalali 1. RabbitMQ daima hujaribu kudumisha kipengele cha urudufishaji kilichobainishwa katika sera zako.
Mchele. 4. Broker 3 inashindwa, na kusababisha foleni C kushindwa
Dalali 1 anayefuata ataanguka! Tumebakiza dalali mmoja tu. Kioo cha Foleni B kimepandishwa hadhi kuwa bora.
Mtini. Xnumx
Tumerejesha Dalali 1. Bila kujali jinsi data inavyostahimili hasara na urejeshaji wa wakala, ujumbe wote wa foleni unaoakisiwa hutupwa unapowashwa upya. Hii ni muhimu kuzingatia kwa sababu kutakuwa na matokeo. Tutaangalia athari hizi hivi karibuni. Kwa hivyo Broker 1 sasa ni mwanachama wa kundi hili tena, na kikundi hiki kinajaribu kutii sera na kwa hivyo kuunda vioo kwenye Dalali 1.
Katika kesi hii, upotezaji wa Broker 1 ulikamilika, kama ilivyokuwa data, kwa hivyo Foleni B isiyo na kioo ilipotea kabisa.
Mchele. 6. Broker 1 anarudi kwenye huduma
Broker 3 amerejea mtandaoni, kwa hivyo foleni A na B hupata vioo vilivyoundwa juu yake ili kukidhi sera zao za HA. Lakini sasa foleni zote kuu ziko kwenye nodi moja! Hii sio bora, usambazaji hata kati ya nodi ni bora. Kwa bahati mbaya, hakuna chaguo nyingi hapa za kusawazisha tena mabwana. Tutarejea suala hili baadaye kwa sababu tunahitaji kuangalia ulandanishi wa foleni kwanza.
Mchele. 7. Broker 3 anarudi kwenye huduma. Foleni zote kuu kwenye nodi moja!
Kwa hivyo sasa unapaswa kuwa na wazo la jinsi vioo hutoa upungufu na uvumilivu wa makosa. Hii inahakikisha upatikanaji katika tukio la kushindwa kwa nodi moja na kulinda dhidi ya kupoteza data. Lakini bado hatujamaliza, kwa sababu kwa kweli ni ngumu zaidi.
Sawazisha
Wakati wa kuunda kioo kipya, ujumbe wote mpya utaigwa kwa kioo hiki na wengine wowote. Kuhusu data iliyopo kwenye foleni kuu, tunaweza kuiiga kwa kioo kipya, ambacho kinakuwa nakala kamili ya bwana. Tunaweza pia kuchagua kutorudia ujumbe uliopo na kuruhusu foleni kuu na kioo kipya viungane kwa wakati, huku jumbe mpya zinazofika mkiani na ujumbe uliopo ukiacha kichwa cha foleni kuu.
Usawazishaji huu unafanywa kiotomatiki au kwa mikono na unadhibitiwa kwa kutumia sera ya foleni. Hebu tuangalie mfano.
Tuna foleni mbili za vioo. Foleni A inasawazishwa kiotomatiki, na Foleni B inasawazishwa mwenyewe. Foleni zote mbili zina jumbe kumi.
Mchele. 8. Foleni mbili zilizo na hali tofauti za ulandanishi
Sasa tunampoteza Dalali 3.
Mchele. 9. Dalali 3 alianguka
Broker 3 anarudi kwenye huduma. Kundi hili huunda kioo kwa kila foleni kwenye nodi mpya na kusawazisha kiotomatiki Foleni A mpya na bwana. Hata hivyo, kioo cha Foleni B mpya kinasalia tupu. Kwa njia hii tuna upungufu kamili kwenye Foleni A na kioo kimoja tu cha ujumbe uliopo wa Foleni B.
Mchele. 10. Kioo kipya cha Foleni A hupokea ujumbe wote uliopo, lakini kioo kipya cha Foleni B hakipokei.
Ujumbe kumi zaidi hufika katika foleni zote mbili. Dalali 2 kisha huacha kufanya kazi na Foleni A kurudi kwenye kioo cha zamani zaidi, ambacho kiko kwenye Dalali 1. Hakuna data iliyopotea inaposhindikana. Katika Foleni B, kuna jumbe ishirini katika bwana na kumi pekee kwenye kioo kwa sababu foleni hii haikuwahi kuigiza jumbe kumi asili.
Mchele. 11. Foleni A inarudishwa kwa Dalali 1 bila kupoteza ujumbe
Ujumbe kumi zaidi hufika katika foleni zote mbili. Sasa Broker 1 inaacha kufanya kazi. Foleni A hubadilika kwa urahisi hadi kwenye kioo bila kupoteza ujumbe. Hata hivyo, Foleni B ina matatizo. Katika hatua hii tunaweza kuboresha upatikanaji au uthabiti.
Ikiwa tunataka kuboresha ufikivu, basi sera ha-kuza-kwa-kushindwa inapaswa kusakinishwa ndani daima. Hii ndiyo thamani chaguo-msingi, kwa hivyo huwezi kubainisha sera hata kidogo. Katika kesi hii, kimsingi tunaruhusu kushindwa katika vioo ambavyo havijasawazishwa. Hii itasababisha ujumbe kupotea, lakini foleni itaendelea kusomeka na kuandikwa.
Mchele. 12. Foleni A inarudishwa kwa Dalali 3 bila kupoteza ujumbe. Foleni B inarudishwa hadi kwa Dalali 3 na ujumbe kumi umepotea
Tunaweza pia kufunga ha-promote-on-failure kwenye maana when-synced. Katika kesi hii, badala ya kurudi kwenye kioo, foleni itasubiri hadi Broker 1 na data yake inarudi kwenye hali ya mtandaoni. Baada ya kurejea, foleni kuu inarudi kwenye Broker 1 bila kupoteza data yoyote. Upatikanaji hutolewa kwa usalama wa data. Lakini hii ni hali ya hatari ambayo inaweza hata kusababisha hasara kamili ya data, ambayo tutaangalia hivi karibuni.
Mchele. 13. Foleni B bado haipatikani baada ya kupoteza Dalali 1
Unaweza kuuliza, "Je, ni bora kutotumia ulandanishi otomatiki?" Jibu ni kwamba maingiliano ni operesheni ya kuzuia. Wakati wa maingiliano, foleni kuu haiwezi kufanya shughuli zozote za kusoma au kuandika!
Hebu tuangalie mfano. Sasa tuna foleni ndefu sana. Wanawezaje kukua kufikia ukubwa kama huo? Kwa sababu kadhaa:
- Foleni hazitumiki kikamilifu
- Hizi ni foleni za kasi kubwa, na hivi sasa watumiaji ni polepole
- Ni foleni za kasi kubwa, kumekuwa na hitilafu na watumiaji wanashika kasi.
Mchele. 14. Foleni mbili kubwa zilizo na hali tofauti za ulandanishi
Sasa Broker 3 anaanguka.
Mchele. 15. Broker 3 huanguka, na kuacha bwana mmoja na kioo katika kila foleni
Broker 3 anarudi mtandaoni na vioo vipya vinaundwa. Foleni Kuu A huanza kunakili ujumbe uliopo kwenye kioo kipya, na kwa wakati huu Foleni haipatikani. Inachukua saa mbili kurudia data, na kusababisha saa mbili za muda wa kutokuwepo kwa Foleni hii!
Hata hivyo, Foleni B bado inapatikana katika kipindi chote. Alijinyima upungufu fulani kwa ufikivu.
Mchele. 16. Foleni bado haipatikani wakati wa kusawazisha
Baada ya saa mbili, Foleni A pia inapatikana na inaweza kuanza kukubali kusomwa na kuandika tena.
Updates
Tabia hii ya kuzuia wakati wa kusawazisha inafanya kuwa vigumu kusasisha makundi yenye foleni kubwa sana. Wakati fulani, nodi kuu inahitaji kuanzishwa upya, ambayo ina maana ama kubadili kioo au kuzima foleni wakati seva inasasishwa. Tukichagua kubadilisha, tutapoteza ujumbe ikiwa vioo havitasawazishwa. Kwa chaguo-msingi, wakati wa kukatika kwa wakala, kushindwa kwa kioo kisichosawazishwa haifanyiki. Hii ina maana kwamba mara tu broker anarudi, hatupoteza ujumbe wowote, uharibifu pekee ulikuwa foleni rahisi. Kanuni za tabia wakati wakala amekatwa huwekwa na sera ha-promote-on-shutdown. Unaweza kuweka moja ya maadili mawili:
always= mpito hadi vioo visivyosawazishwa umewezeshwawhen-synced= mpito kwa kioo kilichosawazishwa tu, vinginevyo foleni inakuwa isiyosomeka na isiyoweza kuandikwa. Foleni inarejea kwenye huduma mara tu wakala anaporejea
Kwa njia moja au nyingine, ukiwa na foleni kubwa unapaswa kuchagua kati ya kupoteza data na kutopatikana.
Wakati Upatikanaji Unaboresha Usalama wa Data
Kuna tatizo moja zaidi la kuzingatia kabla ya kufanya uamuzi. Ingawa ulandanishi wa kiotomatiki ni bora kwa upunguzaji, unaathirije usalama wa data? Bila shaka, kwa upungufu bora zaidi, RabbitMQ ina uwezekano mdogo wa kupoteza ujumbe uliopo, lakini vipi kuhusu ujumbe mpya kutoka kwa wachapishaji?
Hapa unahitaji kuzingatia yafuatayo:
- Je, mchapishaji anaweza kurudisha hitilafu na kuwa na huduma ya juu ya mkondo au mtumiaji ajaribu tena baadaye?
- Je, mchapishaji anaweza kuhifadhi ujumbe ndani ya nchi au katika hifadhidata ili kujaribu tena baadaye?
Ikiwa mchapishaji anaweza tu kutupa ujumbe, basi kwa kweli, kuboresha ufikiaji pia kunaboresha usalama wa data.
Kwa hivyo, usawa lazima utafutwe, na suluhisho inategemea hali maalum.
Matatizo na ha-promote-on-failure=when-synced
Wazo ha-kuza-kwa-kushindwa= inaposawazishwa ni kwamba tunazuia kubadili hadi kioo kisichosawazishwa na hivyo kuepuka upotevu wa data. Foleni bado haisomeki au kuandikwa. Badala yake, tunajaribu kurejesha wakala aliyeanguka na data yake ikiwa haijakamilika ili iweze kuanza kufanya kazi kama bwana bila kupoteza data.
Lakini (na hii ni kubwa lakini) ikiwa broker amepoteza data yake, basi tuna shida kubwa: foleni imepotea! Data zote zimepotea! Hata ikiwa una vioo ambavyo mara nyingi hukutana na foleni kuu, vioo hivyo hutupwa pia.
Ili kuongeza tena nodi iliyo na jina moja, tunaambia nguzo kusahau nodi iliyopotea (na amri. rabbitmqctl forget_cluster_nodi) na uanzishe wakala mpya kwa jina lile lile la mwenyeji. Wakati nguzo inakumbuka nodi iliyopotea, inakumbuka foleni ya zamani na vioo visivyosawazishwa. Wakati nguzo inapoambiwa kusahau nodi ya watoto yatima, foleni hiyo pia husahaulika. Sasa tunahitaji kutangaza tena. Tulipoteza data yote, ingawa tulikuwa na vioo vilivyo na seti ya data. Itakuwa bora kubadili kwenye kioo kisichosawazishwa!
Kwa hivyo, maingiliano ya mwongozo (na kushindwa kusawazisha) pamoja na ha-promote-on-failure=when-synced, kwa maoni yangu, hatari kabisa. Hati zinasema chaguo hili lipo kwa usalama wa data, lakini ni kisu chenye ncha mbili.
Mwalimu kusawazisha
Kama ilivyoahidiwa, tunarudi kwenye shida ya mkusanyiko wa mabwana wote kwenye nodi moja au kadhaa. Hii inaweza kutokea hata kama matokeo ya sasisho la safu inayozunguka. Katika kundi la nodi tatu, foleni zote kuu zitajilimbikiza kwenye nodi moja au mbili.
Kusawazisha mabwana kunaweza kuwa shida kwa sababu mbili:
- Hakuna zana nzuri za kufanya kusawazisha tena
- Usawazishaji wa foleni
Kuna mtu wa tatu kwa kusawazisha tena , ambayo haijaungwa mkono rasmi. Kuhusu programu-jalizi za watu wengine kwenye mwongozo wa RabbitMQ : βProgramu-jalizi hutoa baadhi ya zana za ziada za usanidi na kuripoti, lakini hazitumiki au kuthibitishwa na timu ya RabbitMQ. Tumia kwa hatari yako mwenyewe."
Kuna ujanja mwingine wa kusonga foleni kuu kupitia sera za HA. Mwongozo unataja kwa hii; kwa hili. Inafanya kazi kama hii:
- Huondoa vioo vyote kwa kutumia sera ya muda ambayo ina kipaumbele cha juu kuliko sera iliyopo ya HA.
- Hubadilisha sera ya muda ya HA ili kutumia modi ya nodi, ikibainisha nodi ambayo foleni kuu inapaswa kuhamishiwa.
- Husawazisha foleni ya uhamishaji wa msukumo.
- Baada ya uhamishaji kukamilika, sera ya muda hufutwa. Sera ya awali ya HA inatekelezwa na nambari inayotakiwa ya vioo huundwa.
Upande wa chini ni kwamba mbinu hii inaweza isifanye kazi ikiwa una foleni kubwa au mahitaji madhubuti ya kupunguza.
Sasa hebu tuone jinsi nguzo za RabbitMQ zinavyofanya kazi na sehemu za mtandao.
Kupoteza muunganisho
Node za mfumo uliosambazwa zimeunganishwa na viungo vya mtandao, na viungo vya mtandao vinaweza na vitakatwa. Mzunguko wa kukatika hutegemea miundombinu ya ndani au kuegemea kwa wingu iliyochaguliwa. Kwa hali yoyote, mifumo iliyosambazwa lazima iweze kukabiliana nao. Kwa mara nyingine tena tuna chaguo kati ya upatikanaji na uthabiti, na tena habari njema ni kwamba RabbitMQ hutoa chaguzi zote mbili (sio kwa wakati mmoja).
Na RabbitMQ tuna chaguzi kuu mbili:
- Ruhusu mgawanyiko wa kimantiki (mgawanyiko-ubongo). Hii inahakikisha upatikanaji, lakini inaweza kusababisha kupoteza data.
- Zima utengano wa kimantiki. Huenda ikasababisha upotevu wa muda mfupi wa upatikanaji kulingana na jinsi wateja wanavyounganisha kwenye kundi. Inaweza pia kusababisha kutopatikana kabisa katika kundi la nodi mbili.
Lakini utengano wa kimantiki ni nini? Huu ndio wakati nguzo inagawanyika mara mbili kwa sababu ya upotezaji wa miunganisho ya mtandao. Kwa kila upande, vioo vinakuzwa kwa bwana, ili hatimaye kuna mabwana kadhaa kwa foleni.
Mchele. 17. Foleni kuu na vioo viwili, kila moja kwenye node tofauti. Kisha kushindwa kwa mtandao hutokea na kioo kimoja kinajitenga. Node iliyotengwa inaona kwamba wengine wawili wameanguka na kukuza vioo vyake kwa bwana. Sasa tuna foleni kuu mbili, zinazoweza kuandikwa na kusomeka.
Wachapishaji wakituma data kwa wasimamizi wote wawili, tutaishia na nakala mbili tofauti za foleni.
Njia tofauti za RabbitMQ hutoa upatikanaji au uthabiti.
Puuza hali (chaguo-msingi)
Hali hii inahakikisha ufikivu. Baada ya kupoteza uunganisho, kujitenga kwa mantiki hutokea. Baada ya muunganisho kurejeshwa, msimamizi lazima aamue ni kizigeu gani cha kutoa kipaumbele. Upande uliopotea utaanzishwa upya na data yote iliyokusanywa upande huo itapotea.
Mchele. 18. Wahubiri watatu wanahusishwa na madalali watatu. Ndani, nguzo huelekeza maombi yote kwenye foleni kuu kwenye Dalali 2.
Sasa tunapoteza Broker 3. Anaona kwamba madalali wengine wameanguka na kukuza kioo chake kwa bwana. Hivi ndivyo utengano wa kimantiki hutokea.
Mchele. 19. Mgawanyiko wa kimantiki (mgawanyiko-ubongo). Rekodi huingia kwenye foleni kuu mbili, na nakala hizo mbili zinatofautiana.
Muunganisho umerejeshwa, lakini utengano wa kimantiki unabaki. Msimamizi lazima achague upande unaopotea. Katika kesi iliyo hapa chini, msimamizi huwasha tena Broker 3. Ujumbe wote ambao hakuweza kusambaza umepotea.
Mchele. 20. Msimamizi anazima Dalali 3.
Mchele. 21. Msimamizi anaanza Broker 3 na inajiunga na nguzo, kupoteza ujumbe wote ambao uliachwa hapo.
Wakati wa kupoteza muunganisho na baada ya kurejeshwa kwake, nguzo na foleni hii zilipatikana kwa kusoma na kuandika.
Hali ya kujiponya
Inafanya kazi sawa na modi ya Kupuuza, isipokuwa kwamba nguzo yenyewe huchagua kiotomati upande unaopotea baada ya kugawanyika na kurejesha muunganisho. Upande unaopotea unarudi kwenye nguzo tupu, na foleni inapoteza ujumbe wote ambao ulitumwa upande huo pekee.
Sitisha Hali ya Wachache
Ikiwa hatutaki kuruhusu ugawaji wa kimantiki, basi chaguo letu pekee ni kutupa usomaji na uandishi kwa upande mdogo baada ya kugawanya nguzo. Wakati broker anaona kuwa iko upande mdogo, inasimamisha kazi, yaani, inafunga uhusiano wote uliopo na kukataa mpya yoyote. Mara moja kwa sekunde hukagua marejesho ya muunganisho. Mara tu muunganisho ukirejeshwa, huanza tena kufanya kazi na kujiunga na nguzo.
Mchele. 22. Wahubiri watatu wanahusishwa na madalali watatu. Ndani, nguzo huelekeza maombi yote kwenye foleni kuu kwenye Dalali 2.
Madalali 1 na 2 kisha wakatengana kutoka kwa Dalali 3. Badala ya kukuza kioo chao kuwa bwana, Broker 3 anasimamisha na hapatikani.
Mchele. 23. Broker 3 husitisha, hutenganisha wateja wote, na hukataa maombi ya muunganisho.
Mara tu muunganisho ukirejeshwa, unarudi kwenye nguzo.
Wacha tuangalie mfano mwingine ambapo foleni kuu iko kwenye Broker 3.
Mchele. 24. Foleni kuu kwenye Dalali 3.
Kisha hasara sawa ya uunganisho hutokea. Dalali 3 anasimama kwa sababu yuko upande mdogo. Kwa upande mwingine, nodi zinaona kuwa Broker 3 imeanguka, kwa hivyo kioo cha zamani kutoka kwa Brokers 1 na 2 kinapandishwa cheo na kuwa bwana.
Mchele. 25. Mpito hadi kwa Dalali 2 ikiwa Dalali 3 hapatikani.
Muunganisho ukirejeshwa, Broker 3 atajiunga na kikundi.
Mchele. 26. Nguzo imerejea kwa uendeshaji wa kawaida.
Jambo la muhimu kuelewa hapa ni kwamba tunapata uthabiti, lakini pia tunaweza kupata upatikanaji, ikiwa Tutahamisha wateja kwa mafanikio sehemu nyingi. Kwa hali nyingi, mimi binafsi ningechagua modi ya Sitisha Wachache, lakini inategemea kesi ya mtu binafsi.
Ili kuhakikisha upatikanaji, ni muhimu kuhakikisha kuwa wateja wanaunganishwa kwa ufanisi na mwenyeji. Wacha tuangalie chaguzi zetu.
Kuhakikisha Muunganisho wa Wateja
Tuna chaguo kadhaa za jinsi ya kuelekeza wateja kwenye sehemu kuu ya nguzo au kwa nodes za kufanya kazi (baada ya node moja kushindwa) baada ya kupoteza uunganisho. Kwanza, tukumbuke kwamba foleni mahususi inapangishwa kwenye nodi mahususi, lakini uelekezaji na sera zinaigwa kwenye nodi zote. Wateja wanaweza kuunganisha kwenye nodi yoyote, na uelekezaji wa ndani utawaelekeza wanapohitaji kwenda. Lakini wakati nodi imesimamishwa, inakataa miunganisho, kwa hivyo wateja lazima waunganishe kwenye nodi nyingine. Ikiwa nodi itaanguka, kuna kidogo anaweza kufanya wakati wote.
Chaguzi zetu:
- Kundi hili linapatikana kwa kutumia kisawazisha cha mizigo ambacho huzunguka kwa urahisi kupitia nodi na wateja hujaribu kuunganisha tena hadi kufaulu. Ikiwa nodi iko chini au imesimamishwa, basi majaribio ya kuunganisha kwenye node hiyo yatashindwa, lakini majaribio ya baadaye yataenda kwa seva nyingine (kwa mtindo wa robin ya pande zote). Hii inafaa kwa upotezaji wa muda mfupi wa muunganisho au seva iliyopunguzwa ambayo italetwa haraka.
- Fikia nguzo kupitia kisawazisha mzigo na uondoe nodi zilizosimamishwa/zilizoshindwa kutoka kwenye orodha mara tu zinapogunduliwa. Ikiwa tutafanya hivi haraka, na ikiwa wateja wanaweza kujaribu tena muunganisho, basi tutafikia upatikanaji wa mara kwa mara.
- Mpe kila mteja orodha ya nodi zote, na mteja anachagua moja kwa moja wakati wa kuunganisha. Ikiwa inapokea hitilafu wakati wa kujaribu kuunganisha, huenda kwenye nodi inayofuata kwenye orodha mpaka iunganishe.
- Ondoa trafiki kutoka kwa nodi iliyoshindwa/iliyosimamishwa kwa kutumia DNS. Hii inafanywa kwa kutumia TTL ndogo.
Matokeo
RabbitMQ nguzo ina faida na hasara zake. Hasara kubwa zaidi ni kwamba:
- wakati wa kujiunga na nguzo, nodi hutupa data zao;
- kuzuia maingiliano husababisha foleni kutopatikana.
Maamuzi yote magumu yanatokana na vipengele hivi viwili vya usanifu. Ikiwa RabbitMQ inaweza kuhifadhi data wakati nguzo imeunganishwa tena, basi ulandanishi ungekuwa haraka zaidi. Ikiwa ingekuwa na uwezo wa kusawazisha bila kuzuia, ingesaidia vyema foleni kubwa. Kurekebisha masuala haya mawili kungeboresha sana utendakazi wa RabbitMQ kama teknolojia inayostahimili makosa na inayopatikana sana ya utumaji ujumbe. Ningesita kupendekeza RabbitMQ na nguzo katika hali zifuatazo:
- Mtandao usioaminika.
- Hifadhi isiyoaminika.
- Foleni ndefu sana.
Linapokuja suala la mipangilio ya upatikanaji wa juu, zingatia yafuatayo:
ha-promote-on-failure=alwaysha-sync-mode=manualcluster_partition_handling=ignore(Auautoheal)- ujumbe unaoendelea
- hakikisha wateja wanaunganishwa kwenye nodi inayotumika wakati nodi fulani itashindwa
Kwa uthabiti (usalama wa data), zingatia mipangilio ifuatayo:
- Mchapishaji Anathibitisha na Shukrani za Mwongozo kwa upande wa watumiaji
ha-promote-on-failure=when-synced, ikiwa wachapishaji wanaweza kujaribu tena baadaye na ikiwa una hifadhi ya kuaminika sana! Vinginevyo weka=always.ha-sync-mode=automatic(lakini kwa foleni kubwa zisizofanya kazi, modi ya mwongozo inaweza kuhitajika; pia, zingatia kama kutopatikana kutasababisha ujumbe kupotea)- Sitisha hali ya Wachache
- ujumbe unaoendelea
Bado hatujashughulikia maswala yote ya uvumilivu wa makosa na upatikanaji wa juu; kwa mfano, jinsi ya kutekeleza taratibu za usimamizi kwa usalama (kama vile kusasisha). Tunahitaji pia kuzungumza juu ya shirikisho na programu-jalizi ya Jembe.
Ikiwa nimekosa kitu kingine chochote, tafadhali nijulishe.
Tazama pia yangu , ambapo mimi hufanya uharibifu kwenye nguzo ya RabbitMQ kwa kutumia Docker na Blockade kujaribu baadhi ya hali za upotezaji wa ujumbe zilizoelezewa katika nakala hii.
Nakala zilizotangulia katika safu:
Nambari 1 -
Nambari 2 -
Nambari 3 -
Chanzo: mapenzi.com