В makala ya mwisho tuliangalia mkusanyiko wa RabbitMQ kwa uvumilivu wa makosa na upatikanaji wa juu. Sasa hebu tuchimbue sana Apache Kafka.

Hapa kitengo cha replication ni kizigeu. Kila mada ina sehemu moja au zaidi. Kila sehemu ina kiongozi aliye na au asiye na wafuasi. Wakati wa kuunda mada, unataja idadi ya partitions na mgawo wa kurudia. Thamani ya kawaida ni 3, ambayo ina maana replicas tatu: kiongozi mmoja na wafuasi wawili.

Mchele. 1. Sehemu nne zinasambazwa kati ya madalali watatu

Maombi yote ya kusoma na kuandika huenda kwa kiongozi. Wafuasi hutuma maombi mara kwa mara kwa kiongozi ili kupokea jumbe za hivi punde. Wateja kamwe hawageuki kwa wafuasi; mwisho unapatikana tu kwa upunguzaji na uvumilivu wa makosa.

Kushindwa kwa kizigeu

Wakati broker anashindwa, viongozi wa sehemu kadhaa mara nyingi hushindwa. Katika kila mmoja wao, mfuasi kutoka node nyingine anakuwa kiongozi. Kwa kweli, hii sio wakati wote, kwani sababu ya maingiliano pia huathiri: ikiwa kuna wafuasi waliosawazishwa, na ikiwa sivyo, basi ikiwa kubadili kwa nakala isiyosawazishwa inaruhusiwa. Lakini tusifanye mambo magumu kwa sasa.

Dalali 3 anaondoka kwenye mtandao, na kiongozi mpya anachaguliwa kwa sehemu ya 2 katika wakala 2.

Mchele. 2. Broker 3 afariki na mfuasi wake kwenye broker 2 anachaguliwa kuwa kiongozi mpya wa partition 2.

Kisha wakala 1 huondoka na sehemu ya 1 pia hupoteza kiongozi wake, ambaye jukumu lake hupitishwa kwa wakala 2.

Mchele. 3. Kuna dalali mmoja amesalia. Viongozi wote wako kwenye wakala mmoja na hakuna sifuri

Wakala 1 anaporudi mtandaoni, huongeza wafuasi wanne, na hivyo kutoa upungufu fulani kwa kila kizigeu. Lakini viongozi wote bado walibaki kwenye broker 2.

Mchele. 4. Viongozi kubaki kwenye madalali 2

Wakala 3 anapokuja, tunarudi kwenye nakala tatu kwa kila kizigeu. Lakini viongozi wote bado wako kwenye broker 2.

Mchele. 5. Uwekaji usio na usawa wa viongozi baada ya kurejeshwa kwa madalali 1 na 3

Kafka ina zana ya kusawazisha kiongozi bora kuliko RabbitMQ. Hapo, ilibidi utumie programu-jalizi ya mtu wa tatu au hati ambayo ilibadilisha sera za kuhamisha nodi kuu kwa kupunguza upungufu wakati wa uhamiaji. Kwa kuongezea, kwa foleni kubwa tulilazimika kukubali kutopatikana wakati wa maingiliano.

Kafka ina dhana ya "nakili zinazopendekezwa" kwa jukumu la kiongozi. Vigawanyiko vya mada vinapoundwa, Kafka hujaribu kusambaza viongozi sawasawa katika sehemu zote na kuwawekea alama viongozi hao wa kwanza kama inavyopendelewa. Baada ya muda, kutokana na kuwasha upya seva, kushindwa, na kukatika kwa muunganisho, viongozi wanaweza kuishia kwenye nodi nyingine, kama ilivyo katika hali mbaya iliyoelezwa hapo juu.

Ili kurekebisha hii, Kafka inatoa chaguzi mbili:

• Chaguo auto.leader.rebalance.enable=kweli huruhusu nodi ya kidhibiti kuwagawia tena viongozi kiotomatiki kwa nakala zinazopendekezwa na hivyo kurejesha usambazaji sawa.
• Msimamizi anaweza kuendesha hati kafka-preferred-replica-election.sh kwa kukabidhiwa upya kwa mikono.

Mchele. 6. Replicas baada ya kusawazisha upya

Hili lilikuwa toleo lililorahisishwa la kutofaulu, lakini ukweli ni ngumu zaidi, ingawa hakuna kitu ngumu sana hapa. Yote inategemea nakala zilizosawazishwa (Replicas za Usawazishaji, ISR).

Nakala Zilizosawazishwa (ISR)

ISR ni seti ya nakala za kizigeu ambacho kinachukuliwa kuwa "kilichosawazishwa" (katika-usawazishaji). Kuna kiongozi, lakini kunaweza kusiwe na wafuasi. Mfuasi anachukuliwa kuwa amesawazishwa ikiwa ametoa nakala kamili za ujumbe wote wa kiongozi kabla ya muda kuisha. replica.lag.time.max.ms.

Mfuasi huondolewa kutoka kwa seti ya ISR ikiwa:

• haikufanya ombi la kuchagua kwa muda replica.lag.time.max.ms (anadhaniwa amekufa)
• haikuweza kusasisha wakati wa muda replica.lag.time.max.ms (inazingatiwa polepole)

Wafuasi hufanya maombi ya sampuli katika muda replica.fetch. wait.max.ms, ambayo ni chaguomsingi hadi 500ms.

Ili kueleza wazi madhumuni ya ISR, tunahitaji kuangalia uthibitisho kutoka kwa mtayarishaji na baadhi ya matukio ya kushindwa. Watayarishaji wanaweza kuchagua wakala atakapotuma uthibitisho:

• acks=0, uthibitisho haujatumwa
• acks=1, uthibitisho unatumwa baada ya kiongozi kuandika ujumbe kwa kumbukumbu ya eneo lake
• acks=all, uthibitisho unatumwa baada ya nakala zote katika ISR kuandika ujumbe kwa kumbukumbu za ndani.

Katika istilahi ya Kafka, ikiwa ISR imehifadhi ujumbe, "imejitolea". Acks=all ndio chaguo salama zaidi, lakini pia huongeza ucheleweshaji zaidi. Wacha tuangalie mifano miwili ya kutofaulu na jinsi chaguzi tofauti za 'acks' zinavyoingiliana na dhana ya ISR.

Acks=1 na ISR

Katika mfano huu, tutaona kwamba ikiwa kiongozi hatasubiri kila ujumbe kutoka kwa wafuasi wote kuokolewa, basi kupoteza data kunawezekana ikiwa kiongozi atashindwa. Kusogeza hadi kwa mfuasi ambaye hajasawazishwa kunaweza kuwashwa au kuzimwa kwa kuweka kuwezesha.uchaguzi.wa.najisi.

Katika mfano huu, mtengenezaji ana thamani acks=1. Sehemu hiyo inasambazwa kwa madalali wote watatu. Broker 3 yuko nyuma, alilandanishwa na kiongozi sekunde nane zilizopita na sasa yuko nyuma ya jumbe 7456. Broker 1 alikuwa sekunde moja tu nyuma. Mtayarishaji wetu hutuma ujumbe na anapokea haraka ack nyuma, bila ya juu ya wafuasi wa polepole au wafu ambao kiongozi hajasubiri.

Mchele. 7. ISR yenye nakala tatu

Broker 2 inashindwa na mtayarishaji anapokea hitilafu ya uunganisho. Baada ya uongozi kupita kwa wakala 1, tunapoteza ujumbe 123. Mfuasi kwenye wakala 1 alikuwa sehemu ya ISR, lakini haikusawazishwa kikamilifu na kiongozi ilipoanguka.

Mchele. 8. Ujumbe hupotea unapoanguka

Katika usanidi bootstrap.servers Mtengenezaji ana madalali kadhaa walioorodheshwa na anaweza kumuuliza wakala mwingine ambaye ndiye kiongozi mpya wa sehemu. Kisha huanzisha muunganisho kwa wakala 1 na kuendelea kutuma ujumbe.

Mchele. 9. Kutuma ujumbe kunaendelea baada ya mapumziko mafupi

Broker 3 yuko nyuma zaidi. Hufanya maombi ya kuleta lakini haiwezi kusawazisha. Hii inaweza kuwa kutokana na muunganisho wa mtandao polepole kati ya madalali, suala la uhifadhi, n.k. Imeondolewa kwenye ISR. Sasa ISR ina nakala moja - kiongozi! Mtengenezaji anaendelea kutuma ujumbe na kupokea uthibitisho.

Mchele. 10. Mfuasi kwenye broker 3 ameondolewa kwenye ISR

Dalali 1 anashuka na jukumu la uongozi linaenda kwa wakala 3 na upotezaji wa jumbe 15286! Mtengenezaji hupokea ujumbe wa hitilafu ya uunganisho. Mpito kwa kiongozi nje ya ISR uliwezekana tu kutokana na mpangilio uchaguzi.mchafu.wa.kiongozi.kuwezesha=kweli. Ikiwa imewekwa ndani uongo, basi mpito haungetokea na maombi yote ya kusoma na kuandika yangekataliwa. Katika hali hii, tunasubiri wakala 1 arudi na data yake kamilifu kwenye nakala, ambayo itachukua tena uongozi.

Mchele. 11. Broker 1 huanguka. Wakati kushindwa kunatokea, idadi kubwa ya ujumbe hupotea

Mtayarishaji huanzisha uhusiano na wakala wa mwisho na anaona kwamba sasa ndiye kiongozi wa sehemu hiyo. Anaanza kutuma ujumbe kwa wakala 3.

Mchele. 12. Baada ya mapumziko mafupi, ujumbe hutumwa tena kwa sehemu ya 0

Tuliona kwamba, mbali na kukatizwa kwa muda mfupi ili kuanzisha miunganisho mipya na kutafuta kiongozi mpya, mtengenezaji alikuwa akituma ujumbe kila mara. Usanidi huu unahakikisha upatikanaji kwa gharama ya uthabiti (usalama wa data). Kafka alipoteza maelfu ya ujumbe lakini aliendelea kukubali maandishi mapya.

Acks=yote na ISR

Wacha turudie hali hii tena, lakini na acks=yote. Broker 3 ina muda wa kusubiri wastani wa sekunde nne. Mtengenezaji hutuma ujumbe na acks=yote, na sasa haipati jibu la haraka. Kiongozi anasubiri ujumbe uhifadhiwe na nakala zote kwenye ISR.

Mchele. 13. ISR yenye nakala tatu. Moja ni polepole, na kusababisha ucheleweshaji wa kurekodi

Baada ya sekunde nne za ucheleweshaji zaidi, wakala 2 hutuma alama. Nakala zote sasa zimesasishwa kikamilifu.

Mchele. 14. Nakala zote huhifadhi ujumbe na kutuma ack

Broker 3 sasa iko nyuma zaidi na kuondolewa kutoka kwa ISR. Muda wa kusubiri umepunguzwa kwa kiasi kikubwa kwa sababu hakuna nakala za polepole zilizosalia katika ISR. Broker 2 sasa anasubiri wakala 1 pekee, na ana upungufu wa wastani wa 500 ms.

Mchele. 15. Replica kwenye broker 3 imeondolewa kwenye ISR

Kisha wakala 2 huanguka na uongozi hupita kwa wakala 1 bila kupoteza ujumbe.

Mchele. 16. Broker 2 huanguka

Mtengenezaji hupata kiongozi mpya na kuanza kutuma ujumbe kwake. Muda wa kusubiri umepunguzwa zaidi kwa sababu ISR sasa ina nakala moja! Kwa hivyo chaguo acks=yote haina kuongeza redundancy.

Mchele. 17. Replica kwenye broker 1 inaongoza bila kupoteza ujumbe

Kisha broker 1 anaanguka na kuongoza huenda kwa broker 3 na kupoteza ujumbe 14238!

Mchele. 18. Dalali wa 1 hufa na mabadiliko ya uongozi na mipangilio isiyo safi husababisha upotezaji mkubwa wa data

Hatukuweza kusakinisha chaguo kuwezesha.uchaguzi.wa.najisi kwenye maana kweli. Kwa chaguo-msingi ni sawa uongo. Mipangilio acks=yote с uchaguzi.mchafu.wa.kiongozi.kuwezesha=kweli hutoa ufikiaji kwa usalama wa data ulioongezwa. Lakini kama unavyoona, bado tunaweza kupoteza ujumbe.

Lakini vipi ikiwa tunataka kuongeza usalama wa data? Unaweza kuweka najisi.kiongozi.uchaguzi.wezesha = uongo, lakini hii si lazima itulinde kutokana na upotevu wa data. Ikiwa kiongozi alianguka kwa bidii na kuchukua data nayo, basi ujumbe bado umepotea, pamoja na upatikanaji hupotea mpaka msimamizi atakaporejesha hali hiyo.

Ni bora kuhakikisha kuwa ujumbe wote ni wa ziada, na vinginevyo utupe rekodi. Kisha, angalau kutoka kwa mtazamo wa wakala, kupoteza data kunawezekana tu katika tukio la kushindwa mara mbili au zaidi kwa wakati mmoja.

Acks=all, min.insync.replicas na ISR

Na usanidi wa mada min.insync.replicas Tunaongeza kiwango cha usalama wa data. Wacha tupitie tena sehemu ya mwisho ya hali iliyotangulia, lakini wakati huu na min.insync.replicas=2.

Kwa hivyo broker 2 ana kiongozi wa replica na mfuasi kwenye broker 3 anaondolewa kwenye ISR.

Mchele. 19. ISR kutoka kwa nakala mbili

Dalali 2 anaanguka na uongozi unapita kwa wakala 1 bila kupoteza ujumbe. Lakini sasa ISR ina nakala moja tu. Hii haifikii nambari ya chini ya kupokea rekodi, na kwa hivyo wakala hujibu jaribio la kuandika kwa hitilafu NotEnoughReplicas.

Mchele. 20. Idadi ya ISR ni moja chini kuliko ilivyobainishwa katika min.insync.replicas

Mipangilio hii inatoa dhabihu upatikanaji wa uthabiti. Kabla ya kukubali ujumbe, tunahakikisha kuwa umeandikwa kwa angalau nakala mbili. Hii inampa mtengenezaji kujiamini zaidi. Hapa, upotezaji wa ujumbe unawezekana tu ikiwa nakala mbili zitashindwa kwa wakati mmoja katika muda mfupi hadi ujumbe urudiwe kwa mfuasi wa ziada, ambayo haiwezekani. Lakini ikiwa wewe ni mbishi sana, unaweza kuweka kipengele cha kurudia rudia hadi 5, na min.insync.replicas by 3. Hapa madalali watatu lazima waanguke kwa wakati mmoja ili kupoteza rekodi! Bila shaka, unalipa kwa uaminifu huu katika latency ya ziada.

Wakati ufikiaji ni muhimu kwa usalama wa data

Kama ilivyo kesi na RabbitMQ, wakati mwingine ufikiaji ni muhimu kwa usalama wa data. Hapa ndio unahitaji kufikiria:

• 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 jibu ni hapana, basi kuboresha upatikanaji kunaboresha usalama wa data. Utapoteza data kidogo ukichagua upatikanaji badala ya kutorekodi. Kwa hivyo, yote inakuja kutafuta usawa, na uamuzi unategemea hali maalum.

Maana ya ISR

Kitengo cha ISR hukuruhusu kuchagua uwiano bora kati ya usalama wa data na muda wa kusubiri. Kwa mfano, hakikisha upatikanaji katika tukio la kushindwa kwa nakala nyingi, kupunguza athari za nakala zilizokufa au za polepole katika suala la muda wa kusubiri.

Tunachagua maana sisi wenyewe replica.lag.time.max.ms kulingana na mahitaji yako. Kimsingi, kigezo hiki kinamaanisha ni kiasi gani cha kuchelewa tuko tayari kukubali wakati acks=yote. Thamani chaguo-msingi ni sekunde kumi. Ikiwa hii ni ndefu sana kwako, unaweza kuipunguza. Kisha mzunguko wa mabadiliko katika ISR utaongezeka, kwani wafuasi wataondolewa na kuongezwa mara nyingi zaidi.

RabbitMQ ni seti tu ya vioo vinavyohitaji kuigwa. Vioo vya polepole huanzisha utulivu wa ziada, na vioo vilivyokufa vinaweza kusubiri hadi pakiti zinazoangalia upatikanaji wa kila nodi (tiki ya neti) ili kujibu. ISR ni njia ya kufurahisha ya kuzuia maswala haya ya latency. Lakini tunahatarisha kupoteza upungufu kwani ISR ​​inaweza tu kushuka hadi kwa kiongozi. Ili kuepuka hatari hii, tumia mpangilio min.insync.replicas.

Dhamana ya uunganisho wa mteja

Katika mipangilio bootstrap.servers mtayarishaji na mtumiaji anaweza kubainisha madalali mbalimbali kwa ajili ya kuunganisha wateja. Wazo ni kwamba wakati nodi moja inashuka, kuna vipuri kadhaa vilivyobaki ambavyo mteja anaweza kufungua unganisho. Hawa si lazima wawe viongozi wa sehemu, bali ni ubao wa upakiaji wa awali. Mteja anaweza kuwauliza ni nodi gani inasimamia kiongozi wa kizigeu cha kusoma/kuandika.

Katika RabbitMQ, wateja wanaweza kuunganisha kwa nodi yoyote, na uelekezaji wa ndani hutuma ombi mahali inapohitaji kwenda. Hii ina maana kwamba unaweza kufunga usawazishaji wa mzigo mbele ya RabbitMQ. Kafka inahitaji wateja kuunganishwa kwenye nodi inayopangisha kiongozi anayelingana wa kizigeu. Katika hali hiyo, huwezi kufunga mizani ya mzigo. Orodha bootstrap.servers Ni muhimu kwamba wateja wanaweza kufikia na kupata nodi sahihi baada ya kutofaulu.

Usanifu wa Makubaliano ya Kafka

Hadi sasa, hatujazingatia jinsi nguzo inavyojifunza kuhusu kuanguka kwa wakala na jinsi kiongozi mpya anachaguliwa. Ili kuelewa jinsi Kafka inavyofanya kazi na sehemu za mtandao, kwanza unahitaji kuelewa usanifu wa makubaliano.

Kila nguzo ya Kafka imetumwa pamoja na kundi la Zookeeper, ambayo ni huduma ya maafikiano iliyosambazwa ambayo inaruhusu mfumo kufikia maafikiano kuhusu hali fulani, ikiweka kipaumbele uthabiti juu ya upatikanaji. Idhini ya nodi nyingi za Zookeeper inahitajika ili kuidhinisha shughuli za kusoma na kuandika.

Mtunza wanyama huhifadhi hali ya nguzo:

• Orodha ya mada, sehemu, usanidi, nakala za kiongozi wa sasa, nakala zinazopendekezwa.
• Washiriki wa nguzo. Kila dalali hupiga nguzo ya Zookeeper. Iwapo haitapokea ping ndani ya muda maalum, basi Zookeeper hurekodi wakala kama hayupo.
• Kuchagua nodes kuu na vipuri kwa mtawala.

Nodi ya mtawala ni mojawapo ya madalali wa Kafka ambao wana jukumu la kuchagua viongozi wa replica. Zookeeper hutuma arifa kwa mtawala kuhusu uanachama wa kikundi na mabadiliko ya mada, na mtawala lazima afanyie kazi mabadiliko haya.

Kwa mfano, hebu tuchukue mada mpya yenye sehemu kumi na kipengele cha kurudufu cha 3. Mdhibiti lazima achague kiongozi kwa kila kizigeu, akijaribu kusambaza viongozi kikamilifu kati ya madalali.

Kwa kila kidhibiti cha sehemu:

• inasasisha habari katika Zookeeper kuhusu ISR na kiongozi;
• Hutuma Agizo la KiongoziNaISR kwa kila wakala anayepangisha nakala ya kizigeu hiki, kuwajulisha madalali kuhusu ISR na kiongozi.

Dalali aliye na kiongozi anapoanguka, Zookeeper hutuma arifa kwa mtawala, na huchagua kiongozi mpya. Tena, kidhibiti kwanza husasisha Zookeeper na kisha kutuma amri kwa kila wakala kuwaarifu kuhusu mabadiliko ya uongozi.

Kila kiongozi ana jukumu la kuajiri ISRs. Mipangilio replica.lag.time.max.ms huamua nani ataingia huko. Wakati ISR ​​inabadilika, kiongozi hupeleka habari mpya kwa Zookeeper.

Zookeeper kila wakati huarifiwa juu ya mabadiliko yoyote ili ikitokea kutofaulu, mabadiliko ya usimamizi kwa kiongozi mpya.

Mchele. 21. Makubaliano ya Kafka

Itifaki ya kurudia

Kuelewa maelezo ya urudufishaji hukusaidia kuelewa vyema hali zinazowezekana za upotezaji wa data.

Hoja za sampuli, Log End Offset (LEO) na Highwater Mark (HW)

Tulizingatia kwamba wafuasi mara kwa mara hutuma maombi ya kuleta kwa kiongozi. Muda wa kawaida ni 500ms. Hii inatofautiana na RabbitMQ kwa kuwa katika uigaji wa RabbitMQ haijaanzishwa na kioo cha foleni bali na bwana. Bwana anasukuma mabadiliko kwenye vioo.

Kiongozi na wafuasi wote huhifadhi lebo ya Log End Offset (LEO) na Highwater (HW). Alama ya LEO huhifadhi uwiano wa ujumbe wa mwisho katika nakala ya ndani, na HW inashikilia suluhu ya ahadi ya mwisho. Kumbuka kuwa kwa hali ya kujitolea, ujumbe lazima uendelezwe kwenye nakala zote za ISR. Hii inamaanisha kuwa LEO huwa mbele kidogo kuliko HW.

Kiongozi anapopokea ujumbe, huihifadhi ndani ya nchi. Mfuasi hufanya ombi la kuleta kwa kusambaza LEO yake. Kisha kiongozi hutuma kundi la ujumbe kuanzia LEO hii na pia hutuma HW ya sasa. Wakati kiongozi anapokea taarifa kwamba nakala zote zimehifadhi ujumbe katika sehemu fulani, husogeza alama ya HW. Ni kiongozi pekee anayeweza kuhamisha HW, na hivyo wafuasi wote watajua thamani ya sasa katika majibu ya ombi lao. Hii ina maana kwamba wafuasi wanaweza kubaki nyuma ya kiongozi katika ujumbe na maarifa ya HW. Wateja hupokea ujumbe tu hadi HW ya sasa.

Kumbuka kuwa "iliendelea" inamaanisha kuandikwa kwa kumbukumbu, sio kwa diski. Kwa utendakazi, Kafka inasawazisha kwa diski kwa muda maalum. RabbitMQ pia ina muda huo, lakini itatuma kukiri kwa mchapishaji tu baada ya bwana na vioo vyote kuandika ujumbe kwenye diski. Watengenezaji wa Kafka, kwa sababu za utendaji, waliamua kutuma ack mara tu ujumbe umeandikwa kwenye kumbukumbu. Kafka huweka dau kwamba upunguzaji wa pesa hupunguza hatari ya kuhifadhi kwa ufupi ujumbe unaokubalika kwenye kumbukumbu pekee.

Kushindwa kwa kiongozi

Kiongozi anapoanguka, Zookeeper huarifu kidhibiti, na huchagua nakala ya kiongozi mpya. Kiongozi mpya anaweka alama mpya ya HW kulingana na LEO yake. Wafuasi hupokea habari kuhusu kiongozi mpya. Kulingana na toleo la Kafka, mfuasi atachagua moja ya hali mbili:

1. Itapunguza kumbukumbu ya ndani kwa HW inayojulikana na kutuma ombi kwa kiongozi mpya kwa ujumbe baada ya alama hii.
2. Tutatuma ombi kwa kiongozi ili kujua HW wakati alichaguliwa kuwa kiongozi, na kisha kupunguza logi kwa kukabiliana na hii. Kisha itaanza kufanya maombi ya kuleta mara kwa mara kuanzia ulinganifu huu.

Mfuasi anaweza kuhitaji kupunguza logi kwa sababu zifuatazo:

• Kiongozi anaposhindwa, mfuasi wa kwanza katika seti ya ISR aliyesajiliwa na Zookeeper hushinda uchaguzi na kuwa kiongozi. Wafuasi wote kwenye ISR, ingawa wanazingatiwa "katika usawazishaji," wanaweza kuwa hawajapokea nakala za ujumbe wote kutoka kwa kiongozi wa zamani. Inawezekana kabisa kwamba mfuasi aliyeangaziwa hana nakala iliyosasishwa zaidi. Kafka inahakikisha kuwa hakuna tofauti kati ya nakala. Kwa hivyo, ili kuepusha hitilafu, kila mfuasi lazima apunguze kumbukumbu yake kwa thamani ya HW ya kiongozi mpya wakati wa kuchaguliwa kwake. Hii ni sababu nyingine ya kuweka acks=yote muhimu sana kwa uthabiti.
• Ujumbe huandikwa mara kwa mara kwenye diski. Ikiwa nodi zote za nguzo zitashindwa kwa wakati mmoja, basi nakala zilizo na tofauti tofauti zitahifadhiwa kwenye diski. Inawezekana madalali watakaporudi mtandaoni, kiongozi mpya atakayechaguliwa atakuwa nyuma ya wafuasi wake kwa sababu aliokolewa kabla ya wengine.

Kuungana tena na nguzo

Wakati wa kuunganisha tena nguzo, nakala hufanya sawa na wakati kiongozi anaposhindwa: huangalia nakala ya kiongozi na kupunguza kumbukumbu zao hadi HW yake (wakati wa uchaguzi). Kwa kulinganisha, RabbitMQ kwa usawa huchukulia nodi zilizounganishwa kama mpya kabisa. Katika visa vyote viwili, wakala hutupa hali yoyote iliyopo. Ikiwa maingiliano ya kiotomatiki yanatumiwa, basi bwana lazima arudie kabisa maudhui yote ya sasa kwenye kioo kipya kwa njia ya "acha dunia nzima isubiri". Bwana hakubali shughuli zozote za kusoma au kuandika wakati wa operesheni hii. Mbinu hii inaleta matatizo katika foleni kubwa.

Kafka ni logi iliyosambazwa na kwa ujumla huhifadhi ujumbe zaidi kuliko foleni ya RabbitMQ, ambapo data huondolewa kwenye foleni baada ya kusomwa. Foleni zinazoendelea zinapaswa kubaki ndogo kiasi. Lakini Kafka ni logi iliyo na sera yake ya kuhifadhi, ambayo inaweza kuweka muda wa siku au wiki. Kuzuia foleni na mbinu kamili ya ulandanishi haikubaliki kabisa kwa logi iliyosambazwa. Badala yake, wafuasi wa Kafka wanapunguza tu kumbukumbu zao kwa HW ya kiongozi (wakati wa kuchaguliwa kwake) ikiwa nakala yao iko mbele ya kiongozi. Katika hali inayowezekana zaidi, mfuasi anapokuwa nyuma, huanza tu kufanya maombi ya kuleta kuanzia na LEO yake ya sasa.

Wafuasi wapya au waliojiunga tena huanza nje ya ISR na hawashiriki katika ahadi. Wanafanya kazi tu pamoja na kikundi, wakipokea ujumbe haraka iwezekanavyo hadi wapate kiongozi na kuingia kwenye ISR. Hakuna kufunga ndani na hakuna haja ya kutupa data yako yote.

Kupoteza muunganisho

Kafka ina vijenzi zaidi kuliko RabbitMQ, kwa hivyo ina seti changamano zaidi ya tabia wakati nguzo inapokatika. Lakini Kafka hapo awali iliundwa kwa vikundi, kwa hivyo suluhisho zimefikiriwa vizuri sana.

Ifuatayo ni hali kadhaa za kushindwa kwa muunganisho:

• Tukio la 1: Mfuasi haoni kiongozi, lakini bado anamwona Mlinzi wa Hifadhi ya wanyama.
• Tukio la 2: Kiongozi haoni wafuasi wowote, lakini bado anamwona Mchungaji wa Zookeeper.
• Tukio la 3: Mfuasi anamwona kiongozi, lakini haoni Mlinzi wa Zoo.
• Tukio la 4: Kiongozi anaona wafuasi, lakini haoni Mlinzi wa Zoo.
• Tukio la 5: Mfuasi amejitenga kabisa na nodi zingine zote mbili za Kafka na Zookeeper.
• Tukio la 6: Kiongozi ametenganishwa kabisa na nodi zingine zote mbili za Kafka na Zookeeper.
• Tukio la 7: Nodi ya kidhibiti cha Kafka haiwezi kuona nodi nyingine ya Kafka.
• Tukio la 8: Kidhibiti cha Kafka hakioni Mlinzi wa Zookeeper.

Kila hali ina tabia yake mwenyewe.

Tukio la 1: Mfuasi haoni kiongozi, lakini bado anamwona Mlinzi wa Zookeeper

Mchele. 22. Mfano wa 1: ISR ya nakala tatu

Kushindwa kwa muunganisho hutenganisha wakala 3 kutoka kwa wakala 1 na 2, lakini sio kutoka kwa Zookeeper. Broker 3 hawezi tena kutuma maombi ya kuleta. Baada ya muda kupita replica.lag.time.max.ms imeondolewa kutoka kwa ISR na haishiriki katika ahadi za ujumbe. Muunganisho ukisharejeshwa, utaanza tena maombi ya kuleta na kujiunga na ISR itakapokutana na kiongozi. Zookeeper itaendelea kupokea pings na kudhani kuwa wakala yuko hai na yuko mzima.

Mchele. 23. Mfano wa 1: Dalali ataondolewa kwenye ISR ikiwa hakuna ombi la kuleta litapokelewa kutoka kwake ndani ya muda wa replica.lag.time.max.ms

Hakuna ubongo uliogawanyika au kusimamishwa kwa nodi kama katika RabbitMQ. Badala yake, upotezaji wa kazi hupunguzwa.

Tukio la 2: Kiongozi haoni wafuasi wowote, lakini bado anamwona Mchungaji wa Zookeeper

Mchele. 24. Igizo 2. Kiongozi na wafuasi wawili

Uchanganuzi wa muunganisho wa mtandao hutenganisha kiongozi kutoka kwa wafuasi, lakini wakala bado anaweza kuona Zookeeper. Kama ilivyo katika hali ya kwanza, ISR inapungua, lakini wakati huu kwa kiongozi pekee kwani wafuasi wote huacha kutuma maombi ya kuleta. Tena, hakuna mgawanyiko wa kimantiki. Badala yake, kuna upotevu wa kutotumia tena kwa ujumbe mpya hadi muunganisho urejeshwe. Zookeeper anaendelea kupokea pings na anaamini kuwa wakala yuko hai na yuko mzima.

Mchele. 25. Mfano 2. ISR imepungua kwa kiongozi pekee

Tukio la 3. Mfuasi anamwona kiongozi, lakini haoni Mlinzi wa Zoo

Mfuasi ametenganishwa na Zookeeper, lakini sio kutoka kwa wakala aliye na kiongozi. Kwa hivyo, mfuasi anaendelea kutuma maombi ya kuleta na kuwa mwanachama wa ISR. Zookeeper haipokei tena pings na kusajili ajali ya wakala, lakini kwa kuwa ni mfuasi tu, hakuna matokeo baada ya kupona.

Mchele. 26. Mfano wa 3: Mfuasi anaendelea kutuma maombi ya kuleta kwa kiongozi

Tukio la 4. Kiongozi anaona wafuasi, lakini haoni Mchungaji wa Zookeeper

Mchele. 27. Igizo 4. Kiongozi na wafuasi wawili

Kiongozi ametenganishwa na Zookeeper, lakini sio kutoka kwa madalali walio na wafuasi.

Mchele. 28. Mfano wa 4: Kiongozi kutengwa na Zookeeper

Baada ya muda, Zookeeper atasajili kutofaulu kwa wakala na kumjulisha mtawala kuihusu. Atachagua kiongozi mpya kati ya wafuasi wake. Hata hivyo, kiongozi wa awali ataendelea kufikiri kuwa ndiye kiongozi na ataendelea kukubali viingilio kutoka chuki=1. Wafuasi hawamtumii maombi ya kuleta tena, kwa hivyo atawachukulia kuwa wamekufa na kujaribu kupunguza ISR yenyewe. Lakini kwa kuwa haina muunganisho wa Zookeeper, haitaweza kufanya hivi, na wakati huo itakataa kukubali maingizo mengine zaidi.

Сообщения acks=yote haitapokea kibali kwa sababu ISR huwasha nakala zote kwanza, na ujumbe hauwafikii. Wakati kiongozi wa awali anajaribu kuwaondoa kutoka kwa ISR, haitaweza kufanya hivyo na itaacha kukubali ujumbe wowote hata kidogo.

Wateja hivi karibuni wanaona mabadiliko ya kiongozi na kuanza kutuma rekodi kwa seva mpya. Mara tu mtandao ukirejeshwa, kiongozi wa awali anaona kwamba yeye si kiongozi tena na hupunguza logi yake kwa thamani ya HW ambayo kiongozi mpya alikuwa nayo wakati wa kushindwa kuzuia kutofautiana kwa kumbukumbu. Kisha itaanza kutuma maombi ya kuleta kwa kiongozi mpya. Rekodi zote kutoka kwa kiongozi asilia ambazo hazijaigwa kwa kiongozi mpya zimepotea. Hiyo ni, ujumbe ambao haukukubaliwa na kiongozi wa awali katika sekunde hizo chache wakati viongozi wawili wakifanya kazi utapotea.

Mchele. 29. Mfano 4. Kiongozi kwenye wakala 1 anakuwa mfuasi baada ya mtandao kurejeshwa.

Tukio la 5: Mfuasi amejitenga kabisa na nodi zingine zote mbili za Kafka na Zookeeper

Mfuasi ametengwa kabisa na nodi zingine za Kafka na Zookeeper. Anajiondoa tu kutoka kwa ISR hadi mtandao urejeshwe, na kisha kupatana na wengine.

Mchele. 30. Tukio la 5: Mfuasi aliyetengwa anaondolewa kwenye ISR

Tukio la 6: Kiongozi amejitenga kabisa na nodi zingine za Kafka na Zookeeper

Mchele. 31. Igizo 6. Kiongozi na wafuasi wawili

Kiongozi ametengwa kabisa na wafuasi wake, mtawala na Zookeeper. Kwa muda mfupi itaendelea kukubali maingizo kutoka chuki=1.

Mchele. 32. Mfano wa 6: Kumtenga kiongozi kutoka kwa maeneo mengine ya Kafka na Zookeeper.

Kutopokea maombi baada ya kuisha muda wake replica.lag.time.max.ms, itajaribu kupunguza ISR yenyewe, lakini haitaweza kufanya hivyo kwa sababu hakuna mawasiliano na Zookeeper, basi itaacha kukubali kuandika.

Wakati huo huo, Zookeeper ataweka alama kwa wakala aliyetengwa kuwa amekufa na mtawala atamchagua kiongozi mpya.

Mchele. 33. Hali 6. Viongozi wawili

Kiongozi asilia anaweza kukubali maingizo kwa sekunde chache, lakini kisha ataacha kukubali ujumbe wowote. Wateja husasishwa kila baada ya sekunde 60 na metadata ya hivi punde. Watafahamishwa kuhusu mabadiliko ya kiongozi na wataanza kutuma maingizo kwa kiongozi mpya.

Mchele. 34. Tukio la 6: Watengenezaji wabadilishia kiongozi mpya

Maingizo yote yaliyothibitishwa yaliyofanywa na kiongozi wa awali tangu kupotea kwa muunganisho yatapotea. Mara tu mtandao ukirejeshwa, kiongozi wa asili atagundua kupitia Zookeeper kuwa sio kiongozi tena. Kisha itapunguza kumbukumbu yake kwa HW ya kiongozi mpya wakati wa uchaguzi na kuanza kutuma maombi kama mfuasi.

Mchele. 35. Mfano wa 6: Kiongozi wa awali anakuwa mfuasi baada ya muunganisho wa mtandao kurejeshwa

Katika hali hii, kujitenga kwa mantiki kunaweza kutokea kwa muda mfupi, lakini tu ikiwa chuki=1 и min.insync.replicas pia 1. Utengano wa kimantiki huisha moja kwa moja ama baada ya mtandao kurejeshwa, wakati kiongozi wa awali anapotambua kwamba yeye si kiongozi tena, au wakati wateja wote wanatambua kwamba kiongozi amebadilika na kuanza kumwandikia kiongozi mpya - chochote kitakachotokea kwanza. Kwa hali yoyote, baadhi ya ujumbe utapotea, lakini tu na chuki=1.

Kuna lahaja nyingine ya hali hii ambapo, kabla tu ya mtandao kugawanyika, wafuasi walirudi nyuma na kiongozi akashinikiza ISR kuwa yeye tu. Kisha inakuwa pekee kwa sababu ya upotezaji wa muunganisho. Kiongozi mpya anachaguliwa, lakini kiongozi wa awali anaendelea kukubali maingizo, hata acks=yote, kwa sababu hakuna mwingine katika ISR isipokuwa yeye. Rekodi hizi zitapotea mara tu mtandao utakaporejeshwa. Njia pekee ya kuepuka chaguo hili ni min.insync.replicas = 2.

Tukio la 7: Njia ya Kidhibiti cha Kafka Haiwezi Kuona Njia Nyingine ya Kafka

Kwa ujumla, mara tu unganisho na nodi ya Kafka inapotea, mtawala hataweza kusambaza habari yoyote ya mabadiliko ya kiongozi kwake. Katika hali mbaya zaidi, hii itasababisha utengano wa kimantiki wa muda mfupi, kama ilivyo katika hali ya 6. Mara nyingi zaidi kuliko hivyo, wakala hawezi kuwa mgombea wa uongozi ikiwa mwisho atashindwa.

Tukio la 8: Kidhibiti cha Kafka hakioni Mlinzi wa Zookeeper

Mlinzi wa Zookeeper hatapokea ping kutoka kwa kidhibiti kilichoanguka na atachagua nodi mpya ya Kafka kama kidhibiti. Kidhibiti asili kinaweza kuendelea kujionyesha hivyo, lakini hakipokei arifa kutoka kwa Zookeeper, kwa hivyo hakitakuwa na kazi zozote za kufanya. Mara baada ya mtandao kurejeshwa, atatambua kwamba yeye si mtawala tena, lakini amekuwa node ya kawaida ya Kafka.

Hitimisho kutoka kwa matukio

Tunaona kwamba kupotea kwa muunganisho wa mfuasi hakusababishi upotevu wa ujumbe, lakini hupunguza kwa muda uhitaji tena hadi mtandao urejeshwe. Hii, bila shaka, inaweza kusababisha kupoteza data ikiwa nodes moja au zaidi zimepotea.

Ikiwa kiongozi atatenganishwa na Zookeeper kwa sababu ya kupoteza muunganisho, hii inaweza kusababisha ujumbe kupotea kutoka. chuki=1. Ukosefu wa mawasiliano na Zookeeper husababisha mgawanyiko mfupi wa kimantiki na viongozi hao wawili. Tatizo hili linatatuliwa na parameter acks=yote.

Parameter min.insync.replicas katika nakala mbili au zaidi hutoa uhakikisho wa ziada kwamba matukio kama haya ya muda mfupi hayatasababisha ujumbe uliopotea kama ilivyo katika Mfano wa 6.

Muhtasari wa Ujumbe Uliopotea

Wacha tuorodheshe njia zote unazoweza kupoteza data huko Kafka:

• Kushindwa kwa kiongozi yeyote ikiwa ujumbe ulithibitishwa kwa kutumia chuki=1
• Mpito wowote mchafu wa uongozi, yaani, kwa mfuasi aliye nje ya ISR, hata na acks=yote
• Kumtenga kiongozi kutoka kwa Zookeeper ikiwa ujumbe ulithibitishwa kwa kutumia chuki=1
• Kutengwa kabisa kwa kiongozi ambaye tayari amepunguza kikundi cha ISR kuwa yeye mwenyewe. Barua pepe zote zitapotea, hata acks=yote. Hii ni kweli tu ikiwa min.insync.replicas=1.
• Kushindwa kwa wakati mmoja kwa nodi zote za kizigeu. Kwa sababu ujumbe unakubaliwa kutoka kwa kumbukumbu, baadhi bado hazijaandikwa kwenye diski. Baada ya kuwasha upya seva, baadhi ya ujumbe unaweza kukosa.

Mabadiliko machafu ya uongozi yanaweza kuepukwa kwa kuyazuia au kuhakikisha angalau kupunguzwa kazi mara mbili. Configuration ya kudumu zaidi ni mchanganyiko acks=yote и min.insync.replicas zaidi ya 1.

Ulinganisho wa moja kwa moja wa kuaminika kwa RabbitMQ na Kafka

Ili kuhakikisha kutegemewa na upatikanaji wa juu, majukwaa yote mawili yanatekeleza mfumo wa urudufishaji wa msingi na upili. Hata hivyo, RabbitMQ ina kisigino cha Achilles. Wakati wa kuunganisha tena baada ya kushindwa, nodi hutupa data zao na maingiliano yamezuiwa. Ujanja huu maradufu unatilia shaka maisha marefu ya foleni kubwa katika RabbitMQ. Utalazimika kukubali kupunguzwa kwa muda au muda mrefu wa kuzuia. Kupunguza upungufu huongeza hatari ya upotezaji mkubwa wa data. Lakini ikiwa foleni ni ndogo, basi kwa ajili ya upungufu, muda mfupi wa kutokuwepo (sekunde chache) unaweza kushughulikiwa kwa kutumia majaribio ya mara kwa mara ya kuunganisha.

Kafka hana tatizo hili. Inatupa data tu kutoka kwa hatua ya tofauti kati ya kiongozi na mfuasi. Data yote iliyoshirikiwa imehifadhiwa. Kwa kuongeza, replication haizuii mfumo. Kiongozi anaendelea kukubali machapisho huku mfuasi mpya akipata, kwa hivyo kwa washiriki, kujiunga au kujiunga tena na nguzo inakuwa kazi ndogo. Bila shaka, bado kuna masuala kama vile kipimo data cha mtandao wakati wa urudufishaji. Ukiongeza wafuasi wengi kwa wakati mmoja, unaweza kukutana na kikomo cha kipimo data.

RabbitMQ ni bora kuliko Kafka kwa kutegemewa wakati seva nyingi kwenye nguzo zinashindwa kwa wakati mmoja. Kama tulivyokwisha sema, RabbitMQ hutuma uthibitisho kwa mchapishaji tu baada ya ujumbe kuandikwa kwa diski na bwana na vioo vyote. Lakini hii inaongeza latency ya ziada kwa sababu mbili:

• fsync kila milisekunde mia chache
• Kushindwa kwa kioo kunaweza kuzingatiwa tu baada ya maisha ya pakiti zinazoangalia upatikanaji wa kila nodi (tick ya wavu) imekwisha. Ikiwa kioo kinapungua au kuanguka, hii inaongeza kuchelewa.

Dau la Kafka ni kwamba ikiwa ujumbe utahifadhiwa katika sehemu nyingi, unaweza kukubali ujumbe mara tu unapoingia kwenye kumbukumbu. Kwa sababu hii, kuna hatari ya kupoteza ujumbe wa aina yoyote (hata acks=yote, min.insync.replicas=2) katika kesi ya kushindwa kwa wakati mmoja.

Kwa ujumla, Kafka huonyesha utendakazi bora wa programu na imeundwa kuanzia chini hadi kwa vikundi. Idadi ya wafuasi inaweza kuongezeka hadi 11 ikiwa ni lazima kwa kuaminika. Kipengele cha kurudia 5 na idadi ya chini ya nakala katika ulandanishi min.insync.replicas=3 itafanya upotezaji wa ujumbe kuwa tukio la nadra sana. Ikiwa miundombinu yako inaweza kusaidia uwiano huu wa urudufishaji na kiwango cha upunguzaji wa uwezo, basi unaweza kuchagua chaguo hili.

RabbitMQ nguzo ni nzuri kwa foleni ndogo. Lakini hata foleni ndogo zinaweza kukua haraka kunapokuwa na msongamano mkubwa wa magari. Mara foleni zinapokuwa kubwa, itabidi ufanye maamuzi magumu kati ya upatikanaji na kutegemewa. Kuunganisha kwa RabbitMQ kunafaa zaidi kwa hali zisizo za kawaida ambapo manufaa ya unyumbufu wa RabbitMQ yanashinda hasara zozote za mkusanyiko wake.

Dawa moja ya kuathiriwa na RabbitMQ kwa foleni kubwa ni kuzigawanya katika foleni nyingi ndogo. Ikiwa hauitaji kuagiza kamili ya foleni nzima, lakini ujumbe unaofaa tu (kwa mfano, ujumbe kutoka kwa mteja maalum), au usiamuru chochote, basi chaguo hili linakubalika: angalia mradi wangu. Msawazishaji upya kugawanya foleni (mradi bado uko katika hatua ya awali).

Hatimaye, usisahau kuhusu idadi ya hitilafu katika njia za kuunganisha na kurudia za RabbitMQ na Kafka. Baada ya muda, mifumo imekomaa zaidi na thabiti, lakini hakuna ujumbe utakaowahi kuwa salama kwa 100% dhidi ya upotevu! Aidha, ajali kubwa hutokea katika vituo vya data!

Ikiwa nilikosa kitu, nilifanya makosa, au hukubaliani na pointi yoyote, jisikie huru kuandika maoni au kuwasiliana nami.

Mara nyingi mimi huulizwa: "Nini cha kuchagua, Kafka au RabbitMQ?", "Ni jukwaa gani bora?". Ukweli ni kwamba inategemea sana hali yako, uzoefu wa sasa, n.k. Ninasita kutoa maoni yangu kwa sababu itakuwa ni kurahisisha kupita kiasi kupendekeza jukwaa moja kwa kesi zote za matumizi na vikwazo vinavyowezekana. Niliandika mfululizo huu wa makala ili uweze kuunda maoni yako mwenyewe.

Ninataka kusema kwamba mifumo yote miwili ni viongozi katika eneo hili. Ninaweza kuwa na upendeleo kidogo kwa sababu kutokana na uzoefu wangu na miradi mimi huwa nathamini vitu kama vile kuagiza ujumbe uliohakikishwa na kutegemewa.

Ninaona teknolojia zingine ambazo hazina uaminifu huu na kuagiza kwa uhakika, basi ninaangalia RabbitMQ na Kafka na kutambua thamani ya ajabu ya mifumo hii yote miwili.

Chanzo: mapenzi.com