В huling artikulo tiningnan namin ang RabbitMQ clustering para sa fault tolerance at mataas na availability. Ngayon ay humukay tayo ng malalim sa Apache Kafka.

Dito ang yunit ng pagtitiklop ay ang pagkahati. Ang bawat paksa ay may isa o higit pang mga seksyon. Ang bawat seksyon ay may pinuno na mayroon man o walang tagasunod. Kapag lumilikha ng isang paksa, tinukoy mo ang bilang ng mga partisyon at ang koepisyent ng pagtitiklop. Ang karaniwang halaga ay 3, na nangangahulugang tatlong replika: isang pinuno at dalawang tagasunod.

kanin. 1. Apat na seksyon ang ibinahagi sa tatlong broker

Ang lahat ng mga kahilingan sa pagbasa at pagsulat ay mapupunta sa pinuno. Pana-panahong nagpapadala ang mga tagasunod ng mga kahilingan sa pinuno upang makatanggap ng mga pinakabagong mensahe. Ang mga mamimili ay hindi kailanman lumingon sa mga tagasunod; ang huli ay umiiral lamang para sa kalabisan at pagpapahintulot sa pagkakamali.

Pagkabigo ng partisyon

Kapag ang isang broker ay nabigo, ang mga pinuno ng ilang mga seksyon ay madalas na nabigo. Sa bawat isa sa kanila, isang tagasunod mula sa ibang node ang nagiging pinuno. Sa katunayan, hindi ito palaging nangyayari, dahil ang kadahilanan ng pag-synchronize ay nakakaimpluwensya rin: kung mayroong mga naka-synchronize na tagasunod, at kung hindi, kung ang paglipat sa isang hindi naka-synchronize na replica ay pinapayagan. Ngunit huwag nating gawing kumplikado ang mga bagay sa ngayon.

Ang Broker 3 ay umalis sa network, at isang bagong pinuno ang nahalal para sa seksyon 2 sa broker 2.

kanin. 2. Namatay ang Broker 3 at ang kanyang tagasunod sa broker 2 ay nahalal bilang bagong pinuno ng partition 2

Pagkatapos ang broker 1 ay umalis at ang seksyon 1 ay nawalan din ng pinuno nito, na ang tungkulin ay ipinapasa sa broker 2.

kanin. 3. May isang broker na natitira. Ang lahat ng mga lider ay nasa isang broker na may zero redundancy

Kapag bumalik online ang broker 1, nagdaragdag ito ng apat na tagasunod, na nagbibigay ng kaunting redundancy sa bawat partition. Ngunit ang lahat ng mga pinuno ay nanatili pa rin sa broker 2.

kanin. 4. Ang mga pinuno ay nananatili sa broker 2

Kapag lumabas ang broker 3, bumalik tayo sa tatlong replika bawat partition. Ngunit ang lahat ng mga pinuno ay nasa broker 2 pa rin.

kanin. 5. Hindi balanseng paglalagay ng mga pinuno pagkatapos ng pagpapanumbalik ng mga broker 1 at 3

May tool ang Kafka para sa mas mahusay na pagbalanse ng pinuno kaysa sa RabbitMQ. Doon, kailangan mong gumamit ng third-party na plugin o script na nagbago sa mga patakaran para sa paglipat ng master node sa pamamagitan ng pagbabawas ng redundancy sa panahon ng paglipat. Bilang karagdagan, para sa malalaking pila kailangan naming tanggapin ang kawalan ng kakayahang magamit sa panahon ng pag-synchronize.

Ang Kafka ay may konsepto ng "ginustong mga replika" para sa tungkulin ng pinuno. Kapag ginawa ang mga partition ng paksa, sinusubukan ng Kafka na ipamahagi ang mga pinuno nang pantay-pantay sa mga node at minarkahan ang mga unang pinuno bilang mas gusto. Sa paglipas ng panahon, dahil sa mga pag-reboot ng server, pagkabigo, at pagkasira ng koneksyon, maaaring mapunta ang mga pinuno sa iba pang mga node, tulad ng sa matinding kaso na inilarawan sa itaas.

Upang ayusin ito, nag-aalok ang Kafka ng dalawang pagpipilian:

Pagpipilian auto.leader.rebalance.enable=true nagbibigay-daan sa controller node na awtomatikong muling italaga ang mga pinuno pabalik sa mga ginustong replika at sa gayon ay maibalik ang pare-parehong pamamahagi.
Maaaring patakbuhin ng administrator ang script kafka-preferred-replica-election.sh para sa manu-manong muling pagtatalaga.

kanin. 6. Mga replika pagkatapos ng muling pagbabalanse

Ito ay isang pinasimple na bersyon ng kabiguan, ngunit ang katotohanan ay mas kumplikado, kahit na walang masyadong kumplikado dito. Ang lahat ay bumaba sa mga naka-synchronize na replika (In-Sync Replicas, ISR).

Naka-synchronize na Replicas (ISR)

Ang ISR ay isang hanay ng mga replika ng isang partition na itinuturing na "naka-synchronize" (in-sync). May pinuno, ngunit maaaring walang tagasunod. Itinuturing na naka-synchronize ang isang tagasunod kung nakagawa ito ng mga eksaktong kopya ng lahat ng mensahe ng pinuno bago mag-expire ang agwat. replica.lag.time.max.ms.

Ang isang tagasunod ay aalisin mula sa hanay ng ISR kung ito ay:

ay hindi gumawa ng kahilingan upang pumili para sa pagitan replica.lag.time.max.ms (pinaniniwalaang patay)
hindi nagawang mag-update sa panahon ng agwat replica.lag.time.max.ms (itinuring na mabagal)

Gumagawa ang mga tagasunod ng mga kahilingan sa pag-sample sa pagitan replica.fetch.wait.max.ms, na nagde-default sa 500ms.

Upang malinaw na ipaliwanag ang layunin ng ISR, kailangan nating tingnan ang mga kumpirmasyon mula sa producer at ilang mga senaryo ng pagkabigo. Maaaring pumili ang mga producer kapag nagpadala ang broker ng kumpirmasyon:

acks=0, hindi ipinadala ang kumpirmasyon
acks=1, ipinapadala ang kumpirmasyon pagkatapos magsulat ng mensahe ang pinuno sa kanyang lokal na log
acks=all, ang kumpirmasyon ay ipinadala pagkatapos maisulat ng lahat ng mga replika sa ISR ang mensahe sa mga lokal na log

Sa terminolohiya ng Kafka, kung ang ISR ay nag-save ng isang mensahe, ito ay "nakatuon". Ang Acks=all ay ang pinakaligtas na opsyon, ngunit nagdaragdag din ng karagdagang pagkaantala. Tingnan natin ang dalawang halimbawa ng kabiguan at kung paano nakikipag-ugnayan ang iba't ibang opsyon sa 'acks' sa konsepto ng ISR.

Acks=1 at ISR

Sa halimbawang ito, makikita natin na kung ang pinuno ay hindi maghintay para sa bawat mensahe mula sa lahat ng mga tagasunod na mai-save, kung gayon ang pagkawala ng data ay posible kung ang pinuno ay nabigo. Ang pag-navigate sa isang hindi naka-sync na tagasunod ay maaaring paganahin o hindi paganahin sa pamamagitan ng pagtatakda hindi malinis.pinuno.eleksiyon.paganahin.

Sa halimbawang ito, ang tagagawa ay may value acks=1. Ang seksyon ay ipinamamahagi sa lahat ng tatlong broker. Nasa likod ang Broker 3, naka-synchronize ito sa pinuno walong segundo na ang nakalipas at ngayon ay nasa likod na ng 7456 na mensahe. Ang Broker 1 ay nasa likod lamang ng isang segundo. Ang aming producer ay nagpapadala ng mensahe at mabilis na nakatanggap ng ack back, nang walang overhead ng mabagal o patay na mga tagasunod na hindi hinihintay ng pinuno.

kanin. 7. ISR na may tatlong replika

Nabigo ang Broker 2 at nakatanggap ang producer ng error sa koneksyon. Pagkatapos maipasa ang pamumuno sa broker 1, mawawalan tayo ng 123 mensahe. Ang tagasunod sa broker 1 ay bahagi ng ISR, ngunit hindi ganap na naka-synchronize sa pinuno nang bumagsak ito.

kanin. 8. Nawala ang mga mensahe kapag nag-crash ito

Sa pagsasaayos bootstrap.servers Ang tagagawa ay may ilang mga broker na nakalista at maaaring magtanong sa isa pang broker kung sino ang bagong pinuno ng seksyon. Pagkatapos ay nagtatatag ito ng koneksyon sa broker 1 at patuloy na nagpapadala ng mga mensahe.

kanin. 9. Magpapatuloy ang pagpapadala ng mga mensahe pagkatapos ng maikling pahinga

Ang Broker 3 ay mas malayo pa. Gumagawa ito ng mga kahilingan sa pagkuha ngunit hindi makapag-sync. Maaaring dahil ito sa mabagal na koneksyon sa network sa pagitan ng mga broker, isyu sa storage, atbp. Ito ay inalis sa ISR. Ngayon ang ISR ay binubuo ng isang replika - ang pinuno! Ang tagagawa ay patuloy na nagpapadala ng mga mensahe at tumatanggap ng mga kumpirmasyon.

kanin. 10. Ang tagasunod sa broker 3 ay tinanggal mula sa ISR

Bumaba ang Broker 1 at ang tungkulin ng pamumuno ay napupunta sa broker 3 na nawala ang 15286 na mensahe! Nakatanggap ang tagagawa ng mensahe ng error sa koneksyon. Ang paglipat sa isang pinuno sa labas ng ISR ay posible lamang dahil sa setting unclean.leader.election.enable=true. Kung ito ay naka-install sa hindi totoo, kung gayon ang paglipat ay hindi magaganap at ang lahat ng mga kahilingan sa pagbasa at pagsulat ay tatanggihan. Sa kasong ito, hinihintay namin ang broker 1 na bumalik kasama ang kanyang buo na data sa replica, na muling kukuha sa pamumuno.

kanin. 11. Bumagsak ang Broker 1. Kapag naganap ang isang pagkabigo, isang malaking bilang ng mga mensahe ang mawawala

Ang producer ay nagtatatag ng isang koneksyon sa huling broker at nakita na siya na ngayon ang pinuno ng seksyon. Nagsisimula siyang magpadala ng mga mensahe sa broker 3.

kanin. 12. Pagkatapos ng maikling pahinga, ipapadala muli ang mga mensahe sa seksyon 0

Nakita namin na, bukod sa mga maiikling pagkaantala upang magtatag ng mga bagong koneksyon at maghanap ng bagong pinuno, ang tagagawa ay patuloy na nagpapadala ng mga mensahe. Tinitiyak ng pagsasaayos na ito ang pagkakaroon sa kapinsalaan ng pagkakapare-pareho (seguridad ng data). Nawalan ng libu-libong mensahe si Kafka ngunit patuloy na tumanggap ng mga bagong pagsusulat.

Acks=lahat at ISR

Ulitin natin muli ang senaryo na ito, ngunit sa acks=lahat. Ang Broker 3 ay may average na latency na apat na segundo. Ang tagagawa ay nagpapadala ng mensahe na may acks=lahat, at ngayon ay hindi nakakatanggap ng mabilis na tugon. Ang pinuno ay naghihintay para sa mensahe na mai-save ng lahat ng mga replika sa ISR.

kanin. 13. ISR na may tatlong replika. Ang isa ay mabagal, na nagreresulta sa pagkaantala sa pag-record

Pagkatapos ng apat na segundo ng karagdagang pagkaantala, nagpapadala ang broker 2 ng ack. Ang lahat ng mga replika ay ganap na ngayong na-update.

kanin. 14. Lahat ng mga replika ay nagse-save ng mga mensahe at nagpapadala ng ack

Ang Broker 3 ay mas nahuhulog na ngayon at tinanggal mula sa ISR. Ang latency ay makabuluhang nabawasan dahil walang mabagal na replika na natitira sa ISR. Naghihintay na lang ngayon ang Broker 2 para sa broker 1, at mayroon siyang average na lag na 500 ms.

kanin. 15. Ang replica sa broker 3 ay tinanggal mula sa ISR

Pagkatapos ay bumagsak ang broker 2 at pumasa ang pamumuno sa broker 1 nang hindi nawawala ang mga mensahe.

kanin. 16. Bumagsak ang Broker 2

Nakahanap ang tagagawa ng isang bagong pinuno at nagsimulang magpadala ng mga mensahe sa kanya. Ang latency ay mas nabawasan dahil ang ISR ay binubuo na ngayon ng isang replica! Samakatuwid ang pagpipilian acks=lahat hindi nagdaragdag ng kalabisan.

kanin. 17. Nangunguna ang replika sa broker 1 nang hindi nawawala ang mga mensahe

Pagkatapos ay nag-crash ang broker 1 at napupunta ang lead sa broker 3 na may pagkawala ng 14238 na mensahe!

kanin. 18. Namatay ang Broker 1 at ang paglipat ng pamumuno na may hindi malinis na setting ay nagreresulta sa malawak na pagkawala ng data

Hindi namin mai-install ang opsyon hindi malinis.pinuno.eleksiyon.paganahin sa kahulugan totoo. Bilang default, ito ay katumbas hindi totoo. Mga setting acks=lahat с unclean.leader.election.enable=true nagbibigay ng accessibility na may ilang karagdagang seguridad ng data. Ngunit tulad ng nakikita mo, maaari pa rin tayong mawalan ng mga mensahe.

Ngunit paano kung gusto nating dagdagan ang seguridad ng data? Maaari mong ilagay hindi malinis.pinuno.election.enable = mali, ngunit hindi ito nangangahulugang protektahan kami mula sa pagkawala ng data. Kung ang pinuno ay nahulog nang husto at kinuha ang data kasama nito, kung gayon ang mga mensahe ay mawawala pa rin, at ang availability ay mawawala hanggang sa ibalik ng administrator ang sitwasyon.

Mas mainam na tiyakin na ang lahat ng mga mensahe ay kalabisan, at kung hindi man ay itapon ang pag-record. Pagkatapos, hindi bababa sa mula sa punto ng view ng broker, ang pagkawala ng data ay posible lamang sa kaganapan ng dalawa o higit pang magkasabay na pagkabigo.

Acks=all, min.insync.replicas at ISR

Sa pagsasaayos ng paksa min.insync.replicas Pinapataas namin ang antas ng seguridad ng data. Balikan natin ang huling bahagi ng nakaraang senaryo, ngunit sa pagkakataong ito min.insync.replicas=2.

Kaya ang broker 2 ay may replica leader at ang tagasunod sa broker 3 ay tinanggal sa ISR.

kanin. 19. ISR mula sa dalawang replika

Bumagsak ang Broker 2 at pumasa ang liderato sa broker 1 nang hindi nawawala ang mga mensahe. Ngunit ngayon ang ISR ay binubuo lamang ng isang replika. Hindi nito natutugunan ang pinakamababang bilang upang makatanggap ng mga tala, at samakatuwid ay tumugon ang broker sa pagtatangkang sumulat nang may error NotEnoughReplicas.

kanin. 20. Ang bilang ng mga ISR ay isang mas mababa kaysa sa tinukoy sa min.insync.replicas

Isinasakripisyo ng configuration na ito ang availability para sa consistency. Bago tanggapin ang isang mensahe, tinitiyak namin na ito ay nakasulat sa hindi bababa sa dalawang replika. Nagbibigay ito ng higit na kumpiyansa sa tagagawa. Dito, ang pagkawala ng mensahe ay posible lamang kung ang dalawang replika ay nabigo nang sabay-sabay sa isang maikling pagitan hanggang ang mensahe ay ginagaya sa isang karagdagang tagasunod, na malamang na hindi. Ngunit kung ikaw ay sobrang paranoid, maaari mong itakda ang replication factor sa 5, at min.insync.replicas sa pamamagitan ng 3. Narito ang tatlong broker ay dapat mahulog sa parehong oras upang mawala ang record! Siyempre, babayaran mo ang pagiging maaasahan na ito sa karagdagang latency.

Kapag kailangan ang accessibility para sa seguridad ng data

Tulad ng sa kaso may RabbitMQ, minsan kailangan ang accessibility para sa seguridad ng data. Narito ang kailangan mong pag-isipan:

Maaari bang ibalik lamang ng publisher ang isang error at subukang muli ang upstream na serbisyo o user sa ibang pagkakataon?
Maaari bang i-save ng publisher ang mensahe nang lokal o sa isang database upang subukang muli sa ibang pagkakataon?

Kung ang sagot ay hindi, ang pag-optimize sa availability ay nagpapabuti sa seguridad ng data. Mas kaunting data ang mawawala sa iyo kung pipiliin mo ang availability sa halip na hindi mag-record. Kaya, ang lahat ay bumaba sa paghahanap ng balanse, at ang desisyon ay nakasalalay sa partikular na sitwasyon.

Ang kahulugan ng ISR

Binibigyang-daan ka ng ISR suite na piliin ang pinakamainam na balanse sa pagitan ng seguridad ng data at latency. Halimbawa, tiyakin ang availability kung sakaling mabigo ang karamihan ng mga replika, pinapaliit ang epekto ng patay o mabagal na mga replika sa mga tuntunin ng latency.

Kami mismo ang pumili ng kahulugan replica.lag.time.max.ms ayon sa iyong mga pangangailangan. Sa pangkalahatan, ang parameter na ito ay nangangahulugan kung gaano katagal ang pagkaantala na handa nating tanggapin kung kailan acks=lahat. Ang default na halaga ay sampung segundo. Kung ito ay masyadong mahaba para sa iyo, maaari mong bawasan ito. Pagkatapos ang dalas ng mga pagbabago sa ISR ay tataas, dahil ang mga tagasunod ay aalisin at idaragdag nang mas madalas.

Ang RabbitMQ ay isang hanay lamang ng mga salamin na kailangang kopyahin. Ang mga mabagal na salamin ay nagpapakilala ng karagdagang latency, at ang mga patay na salamin ay maaaring maghintay hanggang sa tumugon ang mga packet na tumitingin sa availability ng bawat node (net tick). Ang ISR ay isang kawili-wiling paraan upang maiwasan ang mga isyu sa latency na ito. Ngunit nanganganib tayong mawalan ng redundancy dahil ang ISR ay maaari lamang lumiit sa pinuno. Upang maiwasan ang panganib na ito, gamitin ang setting min.insync.replicas.

Garantiya sa koneksyon ng kliyente

Sa mga setting bootstrap.servers maaaring tukuyin ng producer at consumer ang maraming broker para sa pagkonekta ng mga kliyente. Ang ideya ay kapag ang isang node ay bumaba, may ilang mga ekstrang natitira kung saan ang kliyente ay maaaring magbukas ng isang koneksyon. Ang mga ito ay hindi kinakailangang mga pinuno ng seksyon, ngunit isang pambuwelo lamang para sa paunang pag-load. Maaaring tanungin sila ng kliyente kung aling node ang nagho-host ng read/write partition leader.

Sa RabbitMQ, maaaring kumonekta ang mga kliyente sa anumang node, at ipinapadala ng internal routing ang kahilingan sa kung saan ito kailangang pumunta. Nangangahulugan ito na maaari kang mag-install ng load balancer sa harap ng RabbitMQ. Ang Kafka ay nangangailangan ng mga kliyente na kumonekta sa node na nagho-host ng kaukulang pinuno ng partisyon. Sa ganoong sitwasyon, hindi ka makakapag-install ng load balancer. Listahan bootstrap.servers Napakahalaga na ma-access ng mga kliyente at mahanap ang mga tamang node pagkatapos ng pagkabigo.

Arkitektura ng Kafka Consensus

Hanggang ngayon, hindi namin isinasaalang-alang kung paano natututo ang cluster tungkol sa pagbagsak ng broker at kung paano inihalal ang isang bagong pinuno. Upang maunawaan kung paano gumagana ang Kafka sa mga partisyon ng network, kailangan mo munang maunawaan ang consensus architecture.

Ang bawat Kafka cluster ay naka-deploy kasama ng Zookeeper cluster, na isang distributed consensus service na nagbibigay-daan sa system na maabot ang consensus sa ilang partikular na estado, na inuuna ang consistency kaysa availability. Ang pahintulot ng karamihan ng mga Zookeeper node ay kinakailangan upang aprubahan ang mga operasyon sa pagbasa at pagsulat.

Iniimbak ng Zookeeper ang estado ng cluster:

Listahan ng mga paksa, seksyon, pagsasaayos, kasalukuyang mga replika ng pinuno, mga ginustong replika.
Mga miyembro ng cluster. Ang bawat broker ay nagpi-ping sa Zookeeper cluster. Kung hindi ito nakatanggap ng ping sa loob ng tinukoy na tagal ng panahon, itatala ng Zookeeper ang broker bilang hindi available.
Pagpili ng pangunahing at ekstrang node para sa controller.

Ang controller node ay isa sa mga Kafka broker na responsable sa pagpili ng mga pinuno ng replika. Nagpapadala ang Zookeeper ng mga notification sa controller tungkol sa cluster membership at mga pagbabago sa paksa, at dapat kumilos ang controller sa mga pagbabagong ito.

Halimbawa, kumuha tayo ng bagong paksa na may sampung partition at replication factor na 3. Ang controller ay dapat pumili ng pinuno para sa bawat partition, sinusubukang mahusay na ipamahagi ang mga lider sa mga broker.

Para sa bawat controller ng seksyon:

nag-a-update ng impormasyon sa Zookeeper tungkol sa ISR at pinuno;
Nagpapadala ng LeaderAndISRCmand sa bawat broker na nagho-host ng replica ng partition na ito, na nagpapaalam sa mga broker tungkol sa ISR at sa pinuno.

Kapag bumagsak ang isang broker na may lider, nagpapadala ang Zookeeper ng notification sa controller, at pipili ito ng bagong pinuno. Muli, ina-update muna ng controller ang Zookeeper at pagkatapos ay nagpapadala ng command sa bawat broker na nag-aabiso sa kanila ng pagbabago sa pamumuno.

Ang bawat pinuno ay may pananagutan sa pag-recruit ng mga ISR. Mga setting replica.lag.time.max.ms tinutukoy kung sino ang papasok doon. Kapag nagbago ang ISR, nagpapadala ang pinuno ng bagong impormasyon sa Zookeeper.

Ang Zookeeper ay palaging ipaalam sa anumang mga pagbabago upang sa kaganapan ng isang pagkabigo, ang pamamahala ay maayos na lumipat sa isang bagong pinuno.

kanin. 21. Kafka Consensus

Protocol ng pagtitiklop

Ang pag-unawa sa mga detalye ng pagtitiklop ay nakakatulong sa iyong mas maunawaan ang mga posibleng sitwasyon ng pagkawala ng data.

Mga sampling query, Log End Offset (LEO) at Highwater Mark (HW)

Isinasaalang-alang namin na pana-panahong nagpapadala ang mga tagasunod ng mga kahilingan sa pagkuha sa pinuno. Ang default na pagitan ay 500ms. Ito ay naiiba sa RabbitMQ dahil sa RabbitMQ ang pagtitiklop ay hindi pinasimulan ng queue mirror ngunit ng master. Tinutulak ng master ang mga pagbabago sa mga salamin.

Ise-save ng pinuno at lahat ng tagasunod ang Log End Offset (LEO) at ang Highwater (HW) na label. Iniimbak ng LEO mark ang offset ng huling mensahe sa lokal na replica, at ang HW ang nagtataglay ng offset ng huling commit. Tandaan na para sa katayuan ng commit, ang mensahe ay dapat ipagpatuloy sa lahat ng mga replika ng ISR. Nangangahulugan ito na ang LEO ay karaniwang nauuna nang bahagya sa HW.

Kapag ang pinuno ay nakatanggap ng isang mensahe, iniimbak ito sa lokal. Ang tagasunod ay gumagawa ng isang kahilingan sa pagkuha sa pamamagitan ng pagpapadala ng kanyang LEO. Ang pinuno ay nagpapadala ng isang batch ng mga mensahe simula sa LEO na ito at nagpapadala din ng kasalukuyang HW. Kapag ang pinuno ay nakatanggap ng impormasyon na ang lahat ng mga replika ay nag-imbak ng mensahe sa ibinigay na offset, ito ay gumagalaw sa marka ng HW. Ang pinuno lang ang makakagalaw sa HW, at sa gayon ay malalaman ng lahat ng mga tagasunod ang kasalukuyang halaga sa mga tugon sa kanilang kahilingan. Nangangahulugan ito na ang mga tagasunod ay maaaring mahuli sa lider sa parehong mensahe at kaalaman sa HW. Ang mga mamimili ay tumatanggap lamang ng mga mensahe hanggang sa kasalukuyang HW.

Tandaan na ang ibig sabihin ng "nagpumilit" ay nakasulat sa memorya, hindi sa disk. Para sa pagganap, nagsi-synchronize ang Kafka sa disk sa isang partikular na agwat. Ang RabbitMQ ay mayroon ding ganoong agwat, ngunit magpapadala lamang ito ng pagkilala sa publisher pagkatapos na maisulat ng master at ng lahat ng salamin ang mensahe sa disk. Ang mga developer ng Kafka, para sa mga kadahilanan ng pagganap, ay nagpasya na magpadala ng isang ack sa sandaling maisulat sa memorya ang mensahe. Pustahan si Kafka na binabawasan ng redundancy ang panganib ng panandaliang pag-iimbak ng mga kinikilalang mensahe sa memorya lamang.

Kabiguan ng pinuno

Kapag bumagsak ang isang pinuno, aabisuhan ng Zookeeper ang controller, at pipili ito ng bagong replika ng pinuno. Ang bagong pinuno ay nagtatakda ng bagong marka ng HW ayon sa kanyang LEO. Pagkatapos ay makakatanggap ang mga tagasunod ng impormasyon tungkol sa bagong pinuno. Depende sa bersyon ng Kafka, pipili ang tagasunod ng isa sa dalawang senaryo:

Puputulin nito ang lokal na log sa isang kilalang HW at magpapadala ng kahilingan sa bagong pinuno para sa mga mensahe pagkatapos ng markang ito.
Magpapadala ng kahilingan sa pinuno upang malaman ang HW sa oras na siya ay nahalal na pinuno, at pagkatapos ay putulin ang log sa offset na ito. Magsisimula itong gumawa ng mga pana-panahong kahilingan sa pagkuha simula sa offset na ito.

Maaaring kailanganin ng isang tagasunod na putulin ang log para sa mga sumusunod na dahilan:

Kapag nabigo ang isang pinuno, ang unang tagasunod sa set ng ISR na nakarehistro sa Zookeeper ang mananalo sa halalan at magiging pinuno. Ang lahat ng mga tagasunod sa ISR, bagama't itinuturing na "naka-sync," ay maaaring hindi nakatanggap ng mga kopya ng lahat ng mga mensahe mula sa dating pinuno. Ganap na posible na ang itinatampok na tagasunod ay walang pinakabagong kopya. Tinitiyak ng Kafka na walang pagkakaiba sa pagitan ng mga replika. Kaya, upang maiwasan ang mga pagkakaiba, dapat putulin ng bawat tagasunod ang log nito sa halaga ng HW ng bagong pinuno sa oras ng kanyang halalan. Ito ay isa pang dahilan kung bakit ang setting acks=lahat napakahalaga para sa pagkakapare-pareho.
Ang mga mensahe ay pana-panahong isinusulat sa disk. Kung ang lahat ng mga cluster node ay nabigo sa parehong oras, pagkatapos ay ang mga replika na may iba't ibang mga offset ay maiimbak sa mga disk. Posible na kapag ang mga broker ay bumalik sa online, ang bagong pinuno na nahalal ay nasa likod ng kanyang mga tagasunod dahil siya ay na-save sa disk bago ang iba.

Reunion kasama ang kumpol

Kapag muling sumasali sa cluster, ang mga replika ay katulad ng kapag nabigo ang isang pinuno: tinitingnan nila ang replika ng pinuno at pinuputol ang kanilang log sa HW nito (sa oras ng halalan). Sa paghahambing, pantay na tinatrato ng RabbitMQ ang mga muling pinagsamang node bilang ganap na bago. Sa parehong mga kaso, itinatapon ng broker ang anumang kasalukuyang estado. Kung ginamit ang awtomatikong pag-synchronize, dapat na ganap na kopyahin ng master ang lahat ng kasalukuyang nilalaman sa bagong salamin sa paraang "hayaan ang buong mundo na maghintay". Ang master ay hindi tumatanggap ng anumang read o write na mga operasyon sa panahon ng operasyong ito. Ang diskarte na ito ay lumilikha ng mga problema sa malalaking pila.

Ang Kafka ay isang distributed log at sa pangkalahatan ay nag-iimbak ito ng mas maraming mensahe kaysa sa isang RabbitMQ queue, kung saan ang data ay tinanggal mula sa queue pagkatapos itong basahin. Ang mga aktibong pila ay dapat manatiling medyo maliit. Ngunit ang Kafka ay isang log na may sariling patakaran sa pagpapanatili, na maaaring magtakda ng panahon ng mga araw o linggo. Ang pagharang sa pila at buong diskarte sa pag-synchronize ay ganap na hindi katanggap-tanggap para sa isang distributed log. Sa halip, pinuputol lang ng mga tagasunod ng Kafka ang kanilang log sa HW ng pinuno (sa oras ng kanyang halalan) kung ang kanilang kopya ay nauuna sa pinuno. Sa mas malamang na kaso, kapag nasa likod ang follower, magsisimula lang itong gumawa ng mga kahilingan sa pagkuha simula sa kasalukuyang LEO nito.

Ang mga bago o muling sumaling mga tagasunod ay nagsisimula sa labas ng ISR at hindi nakikilahok sa mga commit. Nagtatrabaho lang sila sa tabi ng grupo, tumatanggap ng mga mensahe nang mabilis hangga't maaari hanggang sa maabutan nila ang pinuno at makapasok sa ISR. Walang lock-in at hindi na kailangang itapon ang lahat ng iyong data.

Pagkawala ng koneksyon

Ang Kafka ay may higit pang mga bahagi kaysa sa RabbitMQ, kaya mayroon itong mas kumplikadong hanay ng mga pag-uugali kapag ang cluster ay nadiskonekta. Ngunit ang Kafka ay orihinal na idinisenyo para sa mga kumpol, kaya ang mga solusyon ay pinag-isipang mabuti.

Nasa ibaba ang ilang senaryo ng pagkabigo sa koneksyon:

Scenario 1: Ang tagasunod ay hindi nakikita ang pinuno, ngunit nakikita pa rin ang Zookeeper.
Sitwasyon 2: Ang pinuno ay walang nakikitang mga tagasunod, ngunit nakikita pa rin ang Zookeeper.
Sitwasyon 3: Nakikita ng tagasunod ang pinuno, ngunit hindi nakikita ang Zookeeper.
Scenario 4: Nakikita ng pinuno ang mga tagasunod, ngunit hindi nakikita ang Zookeeper.
Sitwasyon 5: Ang tagasunod ay ganap na hiwalay sa iba pang mga Kafka node at Zookeeper.
Scenario 6: Ang pinuno ay ganap na hiwalay sa parehong iba pang mga Kafka node at Zookeeper.
Scenario 7: Ang Kafka controller node ay hindi makakita ng isa pang Kafka node.
Sitwasyon 8: Hindi nakikita ng Kafka controller ang Zookeeper.

Ang bawat senaryo ay may sariling pag-uugali.

Sitwasyon 1: Hindi nakikita ng tagasunod ang pinuno, ngunit nakikita pa rin ang Zookeeper

kanin. 22. Sitwasyon 1: ISR ng tatlong replika

Ang pagkabigo sa koneksyon ay naghihiwalay sa broker 3 mula sa mga broker 1 at 2, ngunit hindi mula sa Zookeeper. Hindi na makakapagpadala ang Broker 3 ng mga kahilingan sa pagkuha. Pagkalipas ng panahon replica.lag.time.max.ms inalis ito sa ISR at hindi nakikilahok sa mga message commit. Kapag naibalik ang koneksyon, ipagpapatuloy nito ang mga kahilingan sa pagkuha at sasali sa ISR kapag naabutan nito ang pinuno. Ang Zookeeper ay patuloy na makakatanggap ng mga ping at ipagpalagay na ang broker ay buhay at maayos.

kanin. 23. Sitwasyon 1: Ang broker ay aalisin mula sa ISR kung walang natanggap na kahilingan sa pagkuha mula dito sa loob ng pagitan ng replica.lag.time.max.ms

Walang split-brain o node suspension tulad ng sa RabbitMQ. Sa halip, nababawasan ang redundancy.

Scenario 2: Walang nakikitang followers si Leader, pero nakikita pa rin niya ang Zookeeper

kanin. 24. Sitwasyon 2. Pinuno at dalawang tagasunod

Ang isang breakdown sa network connectivity ay naghihiwalay sa lider mula sa mga tagasubaybay, ngunit makikita pa rin ng broker ang Zookeeper. Tulad ng sa unang senaryo, lumiliit ang ISR, ngunit sa pagkakataong ito ay sa pinuno lamang dahil ang lahat ng mga tagasunod ay huminto sa pagpapadala ng mga kahilingan sa pagkuha. Muli, walang lohikal na dibisyon. Sa halip, may pagkawala ng redundancy para sa mga bagong mensahe hanggang sa maibalik ang pagkakakonekta. Ang Zookeeper ay patuloy na nakakatanggap ng mga ping at naniniwala na ang broker ay buhay at maayos.

kanin. 25. Sitwasyon 2. Ang ISR ay lumiit lamang sa pinuno

Sitwasyon 3. Nakikita ng tagasunod ang pinuno, ngunit hindi nakikita ang Zookeeper

Ang tagasunod ay hiwalay sa Zookeeper, ngunit hindi mula sa broker na may pinuno. Bilang resulta, ang tagasubaybay ay patuloy na gumagawa ng mga kahilingan sa pagkuha at maging miyembro ng ISR. Ang Zookeeper ay hindi na nakakatanggap ng mga ping at nagrerehistro ng isang pag-crash ng broker, ngunit dahil ito ay isang tagasunod lamang, walang mga kahihinatnan pagkatapos ng pagbawi.

kanin. 26. Sitwasyon 3: Ang tagasunod ay patuloy na nagpapadala ng mga kahilingan sa pagkuha sa pinuno

Sitwasyon 4. Nakikita ng pinuno ang mga tagasunod, ngunit hindi nakikita ang Zookeeper

kanin. 27. Sitwasyon 4. Pinuno at dalawang tagasunod

Ang pinuno ay hiwalay sa Zookeeper, ngunit hindi sa mga broker na may mga tagasunod.

kanin. 28. Sitwasyon 4: Pinuno na nakahiwalay sa Zookeeper

Pagkaraan ng ilang oras, magrerehistro ang Zookeeper ng pagkabigo ng broker at aabisuhan ang controller tungkol dito. Pipili siya ng bagong pinuno sa kanyang mga tagasunod. Gayunpaman, patuloy na iisipin ng orihinal na pinuno na ito ang pinuno at patuloy na tatanggap ng mga entry mula sa acks=1. Ang mga tagasunod ay hindi na nagpapadala sa kanya ng mga kahilingan sa pagkuha, kaya ituturing niyang patay na ang mga ito at susubukang paliitin ang ISR sa sarili nito. Ngunit dahil wala itong koneksyon sa Zookeeper, hindi nito magagawa ito, at sa puntong iyon ay tatangging tanggapin ang anumang karagdagang mga entry.

Сообщения acks=lahat ay hindi makakatanggap ng isang pagkilala dahil ang ISR ay unang nag-on sa lahat ng mga replika, at ang mga mensahe ay hindi nakakarating sa kanila. Kapag sinubukan ng orihinal na pinuno na tanggalin sila sa ISR, hindi nito magagawa ito at hihinto sa pagtanggap ng anumang mensahe.

Sa lalong madaling panahon napansin ng mga kliyente ang pagbabago sa pinuno at nagsimulang magpadala ng mga tala sa bagong server. Kapag naibalik na ang network, makikita ng orihinal na pinuno na hindi na ito pinuno at pinuputol nito ang log nito sa halaga ng HW na mayroon ang bagong pinuno sa oras ng pagkabigo na maiwasan ang divergence ng log. Magsisimula itong magpadala ng mga kahilingan sa pagkuha sa bagong pinuno. Ang lahat ng mga tala mula sa orihinal na pinuno na hindi ginagaya sa bagong pinuno ay nawala. Ibig sabihin, mawawala ang mga mensaheng hindi kinilala ng orihinal na pinuno sa ilang segundong nagtatrabaho ang dalawang lider.

kanin. 29. Sitwasyon 4. Ang pinuno sa broker 1 ay nagiging tagasunod pagkatapos maibalik ang network

Sitwasyon 5: Ang tagasunod ay ganap na hiwalay sa iba pang mga Kafka node at Zookeeper

Ang tagasunod ay ganap na nakahiwalay sa parehong iba pang mga Kafka node at Zookeeper. Inalis lang niya ang kanyang sarili mula sa ISR hanggang sa maibalik ang network, at pagkatapos ay maabutan ang iba.

kanin. 30. Sitwasyon 5: Ang nakahiwalay na tagasunod ay tinanggal sa ISR

Scenario 6: Ang pinuno ay ganap na hiwalay sa parehong iba pang mga Kafka node at Zookeeper

kanin. 31. Sitwasyon 6. Pinuno at dalawang tagasunod

Ang pinuno ay ganap na nakahiwalay sa kanyang mga tagasunod, ang controller at Zookeeper. Para sa isang maikling panahon ito ay patuloy na tatanggap ng mga entry mula sa acks=1.

kanin. 32. Sitwasyon 6: Ihiwalay ang pinuno mula sa iba pang mga node ng Kafka at Zookeeper

Hindi nakatanggap ng mga kahilingan pagkatapos mag-expire replica.lag.time.max.ms, susubukan nitong paliitin ang ISR sa sarili nito, ngunit hindi ito magagawa dahil walang komunikasyon sa Zookeeper, pagkatapos ay hihinto ito sa pagtanggap ng mga pagsusulat.

Samantala, markahan ng Zookeeper ang nakahiwalay na broker bilang patay at ang controller ay pipili ng bagong pinuno.

kanin. 33. Sitwasyon 6. Dalawang pinuno

Ang orihinal na pinuno ay maaaring tumanggap ng mga entry sa loob ng ilang segundo, ngunit pagkatapos ay huminto sa pagtanggap ng anumang mga mensahe. Ina-update ang mga kliyente tuwing 60 segundo gamit ang pinakabagong metadata. Ipapaalam sa kanila ang pagbabago ng pinuno at magsisimulang magpadala ng mga entry sa bagong pinuno.

kanin. 34. Sitwasyon 6: Lumipat ang mga tagagawa sa isang bagong pinuno

Ang lahat ng nakumpirmang mga entry na ginawa ng orihinal na pinuno dahil ang pagkawala ng koneksyon ay mawawala. Kapag naibalik na ang network, matutuklasan ng orihinal na pinuno sa pamamagitan ng Zookeeper na hindi na ito ang pinuno. Pagkatapos ay puputulin nito ang log nito sa HW ng bagong pinuno sa oras ng halalan at magsisimulang magpadala ng mga kahilingan bilang tagasunod.

kanin. 35. Sitwasyon 6: Ang orihinal na pinuno ay nagiging tagasunod pagkatapos maibalik ang pagkakakonekta ng network

Sa sitwasyong ito, maaaring mangyari ang lohikal na paghihiwalay sa loob ng maikling panahon, ngunit kung acks=1 и min.insync.replicas din 1. Awtomatikong natatapos ang lohikal na paghihiwalay pagkatapos maibalik ang network, kapag napagtanto ng orihinal na pinuno na hindi na siya ang pinuno, o kapag napagtanto ng lahat ng kliyente na nagbago ang pinuno at nagsimulang sumulat sa bagong pinuno - alinman ang mauna. Sa anumang kaso, ang ilang mga mensahe ay mawawala, ngunit sa acks=1.

May isa pang variant ng senaryo na ito kung saan, bago maghiwalay ang network, nahuli ang mga tagasunod at inipit ng pinuno ang ISR sa sarili lang niya. Pagkatapos ay nagiging isolated ito dahil sa pagkawala ng koneksyon. Ang isang bagong pinuno ay nahalal, ngunit ang orihinal na pinuno ay patuloy na tumatanggap ng mga entry, kahit na acks=lahat, dahil walang ibang tao sa ISR maliban sa kanya. Ang mga rekord na ito ay mawawala sa sandaling maibalik ang network. Ang tanging paraan upang maiwasan ang pagpipiliang ito ay min.insync.replicas = 2.

Sitwasyon 7: Ang Kafka Controller Node ay Hindi Makakita ng Ibang Kafka Node

Sa pangkalahatan, kapag nawala ang koneksyon sa isang Kafka node, hindi na maipapadala ng controller ang anumang impormasyon sa pagbabago ng pinuno dito. Sa pinakamasamang kaso, hahantong ito sa isang panandaliang lohikal na paghihiwalay, tulad ng sa senaryo 6. Mas madalas kaysa sa hindi, ang broker ay hindi magiging kandidato para sa pamumuno kung ang huli ay nabigo.

Sitwasyon 8: Hindi nakikita ng Kafka controller ang Zookeeper

Ang Zookeeper ay hindi makakatanggap ng ping mula sa nahulog na controller at pipili ng bagong Kafka node bilang controller. Maaaring patuloy na ipakita ng orihinal na controller ang sarili nito, ngunit hindi ito nakakatanggap ng mga abiso mula sa Zookeeper, kaya wala itong anumang mga gawaing gagawin. Kapag naibalik na ang network, malalaman niya na hindi na siya controller, ngunit naging regular na Kafka node.

Mga konklusyon mula sa mga senaryo

Nakikita namin na ang pagkawala ng koneksyon ng tagasubaybay ay hindi nagreresulta sa pagkawala ng mensahe, ngunit pansamantalang binabawasan ang redundancy hanggang sa maibalik ang network. Ito, siyempre, ay maaaring humantong sa pagkawala ng data kung ang isa o higit pang mga node ay nawala.

Kung ang pinuno ay humiwalay sa Zookeeper dahil sa pagkawala ng koneksyon, maaari itong magresulta sa pagkawala ng mga mensahe mula sa acks=1. Ang kakulangan ng komunikasyon sa Zookeeper ay nagdudulot ng maikling lohikal na paghihiwalay sa dalawang pinuno. Ang problemang ito ay nalutas sa pamamagitan ng parameter acks=lahat.

Parametro min.insync.replicas sa dalawa o higit pang mga replika ay nagbibigay ng karagdagang katiyakan na ang mga ganitong panandaliang sitwasyon ay hindi magreresulta sa mga nawawalang mensahe tulad ng sa Scenario 6.

Buod ng Mga Nawalang Mensahe

Ilista natin ang lahat ng paraan kung paano ka mawawalan ng data sa Kafka:

Ang anumang pagkabigo ng pinuno kung ang mga mensahe ay nakumpirma na ginagamit acks=1
Anumang hindi malinis na paglipat ng pamumuno, iyon ay, sa isang tagasunod sa labas ng ISR, kahit na may acks=lahat
Ihiwalay ang pinuno mula sa Zookeeper kung nakumpirma ang paggamit ng mga mensahe acks=1
Ganap na paghihiwalay ng pinuno na lumiit na sa grupo ng ISR sa kanyang sarili. Ang lahat ng mga mensahe ay mawawala, kahit na acks=lahat. Ito ay totoo lamang kung min.insync.replicas=1.
Sabay-sabay na pagkabigo ng lahat ng partition node. Dahil ang mga mensahe ay kinikilala mula sa memorya, ang ilan ay maaaring hindi pa naisulat sa disk. Pagkatapos i-reboot ang mga server, maaaring nawawala ang ilang mensahe.

Ang maruming paglipat ng pamumuno ay maiiwasan sa pamamagitan ng pagbabawal sa kanila o pagtiyak ng hindi bababa sa dalawang redundancies. Ang pinaka-matibay na pagsasaayos ay isang kumbinasyon acks=lahat и min.insync.replicas mahigit 1.

Direktang paghahambing ng pagiging maaasahan ng RabbitMQ at Kafka

Upang matiyak ang pagiging maaasahan at mataas na kakayahang magamit, ang parehong mga platform ay nagpapatupad ng pangunahin at pangalawang sistema ng pagtitiklop. Gayunpaman, ang RabbitMQ ay may sakong Achilles. Kapag muling kumonekta pagkatapos ng isang pagkabigo, itinatapon ng mga node ang kanilang data at ang pag-synchronize ay naharang. Ang double whammy na ito ay nagtatanong sa mahabang buhay ng malalaking pila sa RabbitMQ. Kakailanganin mong tanggapin ang alinman sa pinababang redundancy o mahabang oras ng pagharang. Ang pagbabawas ng redundancy ay nagpapataas ng panganib ng napakalaking pagkawala ng data. Ngunit kung ang mga pila ay maliit, kung gayon para sa kapakanan ng kalabisan, ang mga maikling panahon ng kawalan ng kakayahang magamit (ilang segundo) ay maaaring harapin gamit ang paulit-ulit na mga pagtatangka sa koneksyon.

Walang ganitong problema si Kafka. Itinatapon lamang nito ang data mula sa punto ng divergence sa pagitan ng pinuno at ng tagasunod. Ang lahat ng nakabahaging data ay nai-save. Bilang karagdagan, hindi hinaharangan ng pagtitiklop ang system. Ang pinuno ay patuloy na tumatanggap ng mga post habang ang bagong tagasunod ay nakakakuha, kaya para sa mga devops, ang pagsali o muling pagsali sa cluster ay nagiging isang maliit na gawain. Siyempre, mayroon pa ring mga isyu tulad ng bandwidth ng network sa panahon ng pagtitiklop. Kung magdadagdag ka ng maraming tagasunod nang sabay-sabay, maaari kang makatagpo ng limitasyon sa bandwidth.

Ang RabbitMQ ay mas mataas kaysa sa Kafka sa pagiging maaasahan kapag ang maraming mga server sa isang kumpol ay nabigo sa parehong oras. Tulad ng nasabi na namin, ang RabbitMQ ay nagpapadala lamang ng kumpirmasyon sa publisher pagkatapos na isulat ang mensahe sa disk ng master at lahat ng mga salamin. Ngunit nagdaragdag ito ng karagdagang latency para sa dalawang dahilan:

fsync bawat ilang daang millisecond
Ang pagkabigo ng salamin ay maaari lamang mapansin pagkatapos ng buhay ng mga packet na sumusuri sa pagkakaroon ng bawat node (net tick) ay nag-expire na. Kung bumagal o bumagsak ang salamin, nagdaragdag ito ng pagkaantala.

Ang taya ni Kafka ay kung ang isang mensahe ay naka-imbak sa maraming node, maaari nitong kilalanin ang mga mensahe sa sandaling maabot ng mga ito ang memorya. Dahil dito, may panganib na mawala ang mga mensahe ng anumang uri (kahit na acks=lahat, min.insync.replicas=2) sa kaso ng sabay-sabay na pagkabigo.

Sa pangkalahatan, ang Kafka ay nagpapakita ng mas mahusay na pagganap ng software at idinisenyo mula sa simula para sa mga kumpol. Ang bilang ng mga tagasunod ay maaaring tumaas sa 11 kung kinakailangan para sa pagiging maaasahan. Salik ng pagtitiklop 5 at pinakamababang bilang ng mga replika sa pag-synchronize min.insync.replicas=3 gagawing napakabihirang kaganapan ang pagkawala ng mensahe. Kung kayang suportahan ng iyong imprastraktura ang replication ratio at antas ng redundancy na ito, maaari mong piliin ang opsyong ito.

Ang RabbitMQ clustering ay mabuti para sa maliliit na pila. Ngunit kahit na ang maliliit na pila ay maaaring lumaki nang mabilis kapag may matinding trapiko. Kapag lumaki na ang mga pila, kakailanganin mong gumawa ng mahihirap na pagpipilian sa pagitan ng availability at pagiging maaasahan. Ang RabbitMQ clustering ay pinakaangkop para sa mga hindi pangkaraniwang sitwasyon kung saan ang mga benepisyo ng flexibility ng RabbitMQ ay mas malaki kaysa sa anumang mga disadvantage ng clustering nito.

Ang isang panlunas sa kahinaan ng RabbitMQ sa malalaking pila ay hatiin ang mga ito sa maraming mas maliliit na pila. Kung hindi mo kailangan ng kumpletong pag-order ng buong queue, ngunit ang mga nauugnay na mensahe lamang (halimbawa, mga mensahe mula sa isang partikular na kliyente), o hindi mag-order ng kahit ano, kung gayon ang pagpipiliang ito ay katanggap-tanggap: tingnan ang aking proyekto Rebalancer upang hatiin ang pila (ang proyekto ay nasa maagang yugto pa).

Sa wakas, huwag kalimutan ang tungkol sa ilang mga bug sa clustering at replication na mga mekanismo ng parehong RabbitMQ at Kafka. Sa paglipas ng panahon, ang mga system ay naging mas mature at stable, ngunit walang mensahe ang 100% na ligtas mula sa pagkawala! Bilang karagdagan, nangyayari ang malalaking aksidente sa mga data center!

Kung may napalampas ako, nagkamali, o hindi ka sumasang-ayon sa alinman sa mga punto, huwag mag-atubiling magsulat ng komento o makipag-ugnayan sa akin.

Madalas akong tinatanong: "Ano ang pipiliin, Kafka o RabbitMQ?", "Aling platform ang mas mahusay?". Ang totoo ay depende talaga ito sa iyong sitwasyon, kasalukuyang karanasan, atbp. Nag-aalangan akong magbigay ng aking opinyon dahil magiging sobrang pagpapasimple kung magrekomenda ng isang platform para sa lahat ng mga kaso ng paggamit at mga posibleng limitasyon. Isinulat ko itong serye ng mga artikulo para makabuo ka ng sarili mong opinyon.

Gusto kong sabihin na ang parehong mga sistema ay mga pinuno sa lugar na ito. Maaaring medyo bias ako dahil mula sa aking karanasan sa mga proyekto ay may posibilidad akong pahalagahan ang mga bagay tulad ng garantisadong pag-order ng mensahe at pagiging maaasahan.

Nakikita ko ang iba pang mga teknolohiya na kulang sa pagiging maaasahan at garantisadong pag-order, pagkatapos ay tumingin ako sa RabbitMQ at Kafka at napagtanto ko ang hindi kapani-paniwalang halaga ng parehong mga sistemang ito.

Pinagmulan: www.habr.com

RabbitMQ vs Kafka: Fault Tolerance at Mataas na Availability