Ang pagtugot sa sayup ug taas nga pagkaanaa mga dagkong hilisgutan, mao nga among igahin ang lahi nga mga artikulo sa RabbitMQ ug Kafka. Kini nga artikulo mahitungod sa RabbitMQ, ug ang sunod mahitungod sa Kafka, kon itandi sa RabbitMQ. Kini usa ka taas nga artikulo, busa himoa ang imong kaugalingon nga komportable.

Atong tan-awon ang fault tolerance, consistency, ug high availability (HA) nga mga estratehiya ug ang mga tradeoffs nga gihimo sa matag estratehiya. Ang RabbitMQ mahimong modagan sa usa ka pungpong sa mga node - ug dayon giklasipikar isip usa ka distributed system. Kung bahin sa mga gipang-apod-apod nga mga sistema, kanunay namong hisgutan ang pagkamakanunayon ug pagkaanaa.

Kini nga mga konsepto naghulagway kung giunsa ang paglihok sa usa ka sistema kung kini mapakyas. Ang pagkapakyas sa koneksyon sa network, pagkapakyas sa server, pagkapakyas sa hard drive, temporaryo nga dili magamit sa server tungod sa pagkolekta sa basura, pagkawala sa pakete, o paghinay sa koneksyon sa network. Kining tanan mahimong mosangpot sa pagkawala sa datos o panagbangi. Mopatim-aw nga halos imposible nga magbutang ug sistema nga parehas nga hingpit nga makanunayon (walay pagkawala sa datos, walay pagkalainlain sa datos) ug magamit (modawat sa pagbasa ug pagsulat) alang sa tanan nga mga senaryo sa kapakyasan.

Atong makita nga ang pagkamakanunayon ug pagkaanaa naa sa magkaatbang nga mga tumoy sa spectrum, ug kinahanglan nimo nga pilion kung unsang paagiha ang ma-optimize. Ang maayong balita mao nga sa RabbitMQ kini nga kapilian posible. Ikaw adunay kini nga mga matang sa "nerdy" nga mga levers aron ibalhin ang balanse ngadto sa mas dako nga pagkamakanunayon o mas dako nga accessibility.

Maghatag kami ug espesyal nga atensyon kung unsang mga pag-configure ang hinungdan sa pagkawala sa datos tungod sa nakumpirma nga mga rekord. Adunay usa ka kadena sa responsibilidad tali sa mga magmamantala, mga broker ug mga konsumedor. Sa higayon nga ang mensahe mapasa ngadto sa broker, iyang trabaho nga dili mawala ang mensahe. Kung giila sa broker ang resibo sa magmamantala sa mensahe, wala kami magdahom nga mawala kini. Apan atong makita nga kini mahitabo gayud depende sa imong broker ug publisher configuration.

Single Node Resilience Primitives

Lig-on nga Pagpila/Pagruta

Adunay duha ka klase sa mga pila sa RabbitMQ: durable ug non-durable. Ang tanan nga mga pila gitipigan sa Mnesia database. Ang lig-on nga mga pila gi-anunsyo pag-usab sa pagsugod sa node ug sa ingon makalahutay sa pag-restart, pagkahagsa sa sistema, o pagkahagsa sa server (basta ang datos magpadayon). Buot ipasabot nga basta ideklarar nimo nga lig-on ang routing (exchange) ug queue, mobalik online ang queuing/routing infrastructure.

Ang mga mabulukon nga mga pila ug pag-ruta matangtang kung ang node gi-restart.

Nagpadayon nga mga mensahe

Tungod lang kay lig-on ang pila wala magpasabot nga ang tanan nga mga mensahe niini mabuhi pag-usab sa node. Mga mensahe lamang nga gitakda sa magmamantala isip malungtaron (padayon nga). Ang padayon nga mga mensahe naghimo og dugang nga load sa broker, apan kung ang pagkawala sa mensahe dili madawat, nan wala nay laing kapilian.

bugas. 1. Sustainability matrix

Clustering uban sa queue mirroring

Aron mabuhi ang pagkawala sa usa ka broker, kinahanglan namon ang redundancy. Mahimo natong i-combine ang daghang mga RabbitMQ node ngadto sa usa ka cluster, ug dayon idugang ang dugang nga redundancy pinaagi sa pagkopya sa mga pila tali sa daghang mga node. Niining paagiha, kung ang usa ka node mapakyas, dili kami mawad-an sa datos ug magpabilin nga magamit.

Pag-mirror sa pila:

• usa ka nag-unang pila (master), nga nakadawat sa tanan nga pagsulat ug pagbasa sa mga mando
• usa o daghan pa nga mga salamin nga makadawat sa tanan nga mga mensahe ug metadata gikan sa panguna nga pila. Kini nga mga salamin wala didto alang sa scaling, apan alang lamang sa redundancy.

bugas. 2. Pag-mirror sa pila

Ang pagsalamin gitakda sa angay nga palisiya. Diha niini mahimo nimong pilion ang coefficient sa pagkopya ug bisan ang mga node diin kinahanglan mahimutang ang pila. Mga pananglitan:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (usa ka agalon ug usa ka salamin)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Kompirmasyon sa magmamantala

Aron makab-ot ang makanunayon nga pagrekord, gikinahanglan ang Pagkumpirma sa Publisher. Kung wala sila, adunay peligro nga mawala ang mga mensahe. Ang usa ka kumpirmasyon ipadala ngadto sa magmamantala human ang mensahe gisulat sa disk. Ang RabbitMQ nagsulat sa mga mensahe sa disk dili sa pagkadawat, apan sa matag karon ug unya, sa rehiyon sa pipila ka gatus ka millisecond. Kung ang usa ka pila gisalamin, ang usa ka pag-ila ipadala lamang human ang tanan nga mga salamin gisulat usab ang ilang kopya sa mensahe sa disk. Kini nagpasabut nga ang paggamit sa mga kumpirmasyon nagdugang latency, apan kung ang seguridad sa datos hinungdanon, nan kini kinahanglan.

Failover nga pila

Kung ang usa ka broker mohunong o mag-crash, ang tanan nga mga lider sa pila (mga agalon) sa kana nga node nahagsa uban niini. Gipili dayon sa cluster ang labing karaan nga salamin sa matag agalon ug gipasiugda kini isip bag-ong agalon.

bugas. 3. Daghang mga salamin nga pila ug ang ilang mga palisiya

Ang Broker 3 nahulog. Timan-i nga ang Queue C nga salamin sa Broker 2 gi-promote sa master. Timan-i usab nga usa ka bag-ong salamin ang gihimo para sa Queue C sa Broker 1. Ang RabbitMQ kanunay nga mosulay sa pagpadayon sa replication factor nga gitakda sa imong mga polisiya.

bugas. 4. Ang Broker 3 napakyas, hinungdan nga napakyas ang pila C

Ang sunod nga Broker 1 nahulog! Usa na lang ka broker ang nahabilin. Ang salamin sa Queue B gi-promote nga master.

Mat. 5

Gibalik namo ang Broker 1. Bisag unsa ka maayo ang datos nga nakalahutay sa pagkawala ug pagbawi sa broker, ang tanan nga mga mirrored queue messages ilabay sa pagsugod pag-usab. Importante kini nga hinumdoman tungod kay adunay mga sangputanan. Atong tan-awon kini nga mga implikasyon sa dili madugay. Mao nga ang Broker 1 karon miyembro na usab sa cluster, ug ang cluster naningkamot sa pagsunod sa mga palisiya ug busa nagmugna og mga salamin sa Broker 1.

Sa kini nga kaso, ang pagkawala sa Broker 1 kompleto, sama sa datos, mao nga ang wala'y salamin nga Queue B hingpit nga nawala.

bugas. 6. Ang Broker 1 mibalik sa serbisyo

Ang Broker 3 mibalik sa online, mao nga ang mga pila A ug B ibalik ang mga salamin nga gihimo niini aron matagbaw ang ilang mga polisiya sa HA. Apan karon ang tanan nga mga nag-unang pila naa sa usa ka node! Dili kini sulundon, mas maayo ang parehas nga pag-apod-apod tali sa mga node. Ikasubo, wala’y daghang kapilian dinhi alang sa pagbalanse sa mga agalon. Atong balikan kini nga isyu sa ulahi tungod kay kinahanglan naton tan-awon una ang pag-synchronize sa pila.

bugas. 7. Ang Broker 3 mibalik sa serbisyo. Tanan nga nag-unang pila sa usa ka node!

Mao nga karon kinahanglan ka adunay usa ka ideya kung giunsa ang mga salamin naghatag kalabisan ug pagtugot sa sayup. Gisiguro niini ang pagkaanaa kung adunay usa ka kapakyasan sa node ug mapanalipdan batok sa pagkawala sa datos. Apan wala pa kami nahuman, tungod kay sa tinuud kini labi ka komplikado.

Pag-synchronize

Kung maghimo usa ka bag-ong salamin, ang tanan nga mga bag-ong mensahe kanunay nga gisundog niini nga salamin ug bisan unsang uban pa. Mahitungod sa kasamtangan nga datos sa master queue, mahimo natong kopyahon kini sa usa ka bag-ong salamin, nga mahimong kompleto nga kopya sa agalon. Mahimo usab natong pilion nga dili kopyahon ang kasamtangan nga mga mensahe ug tugotan ang nag-unang pila ug ang bag-ong salamin nga magtagbo sa oras, nga adunay mga bag-ong mensahe nga moabut sa ikog ug mga kasamtangan nga mensahe nga nagbilin sa ulo sa panguna nga pila.

Kini nga pag-synchronize kay awtomatiko o manwal ug gidumala gamit ang polisiya sa pila. Atong tan-awon ang usa ka pananglitan.

Naa mi duha ka samin nga pila. Ang Queue A awtomatik nga gi-synchronize, ug ang Queue B gi-synchronize sa mano-mano. Ang duha ka pila adunay napulo ka mga mensahe.

bugas. 8. Duha ka pila nga adunay lainlaing mga paagi sa pag-synchronize

Karon nawala ang Broker 3.

bugas. 9. Nahulog ang Broker 3

Ang Broker 3 mibalik sa serbisyo. Ang cluster nagmugna og salamin alang sa matag pila sa bag-ong node ug awtomatik nga nag-synchronize sa bag-ong Queue A sa master. Bisan pa, ang salamin sa bag-ong Queue B nagpabilin nga walay sulod. Niining paagiha kita adunay bug-os nga redundancy sa Queue A ug usa lamang ka salamin alang sa kasamtangan nga Queue B nga mga mensahe.

bugas. 10. Ang bag-ong salamin sa Queue A makadawat sa tanan nga kasamtangan nga mga mensahe, apan ang bag-ong salamin sa Queue B wala.

Napulo pa nga mga mensahe ang moabut sa duha ka pila. Ang Broker 2 unya nahagsa ug ang Queue A mibalik sa labing karaan nga salamin, nga anaa sa Broker 1. Walay pagkawala sa datos kung kini mapakyas. Sa Queue B, adunay baynte ka mga mensahe sa master ug napulo ra sa salamin tungod kay kini nga pila wala gyud gisundog ang orihinal nga napulo ka mga mensahe.

bugas. 11. Ang Queue A mibalik sa Broker 1 nga dili mawala ang mga mensahe

Napulo pa nga mga mensahe ang moabut sa duha ka pila. Karon nahagsa ang Broker 1. Ang Queue A dali nga mobalhin sa salamin nga dili mawala ang mga mensahe. Bisan pa, adunay mga problema ang Queue B. Niini nga punto mahimo naton nga ma-optimize ang pagkaanaa o pagkamakanunayon.

Kung gusto namon nga ma-optimize ang pagka-access, nan ang palisiya ha-promote-on-kapakyasan kinahanglan nga ma-install sa kanunay. Kini ang default nga kantidad, aron dili nimo matino ang palisiya. Sa kini nga kaso, gitugutan namon ang mga kapakyasan sa mga dili dungan nga salamin. Kini ang hinungdan nga mawala ang mga mensahe, apan ang pila magpabilin nga mabasa ug masulat.

bugas. 12. Ang Queue A gibalik sa Broker 3 nga dili mawala ang mga mensahe. Ang Queue B mibalik sa Broker 3 nga nawala ang napulo ka mensahe

Mahimo usab namo i-install ha-promote-on-failure ngadto sa kahulogan when-synced. Sa kini nga kaso, imbis nga mobalik sa salamin, ang pila maghulat hangtod ang Broker 1 uban ang datos niini mobalik sa online mode. Pagkahuman niini, ang panguna nga pila nabalik sa Broker 1 nga wala’y pagkawala sa datos. Ang pagkaanaa gisakripisyo alang sa seguridad sa datos. Apan kini usa ka peligroso nga paagi nga mahimo pa gani nga mosangpot sa pagkompleto sa pagkawala sa datos, nga atong tan-awon sa dili madugay.

bugas. 13. Ang Queue B nagpabiling dili magamit human mawala ang Broker 1

Mahimong mangutana ka, "Mas maayo ba nga dili mogamit ug awtomatikong pag-synchronize?" Ang tubag mao nga ang pag-synchronize kay usa ka blocking operation. Atol sa pag-synchronize, ang nag-unang pila dili makahimo sa bisan unsang pagbasa o pagsulat nga mga operasyon!

Atong tan-awon ang usa ka pananglitan. Karon taas na kaayo mig pila. Sa unsa nga paagi sila motubo ngadto sa ingon nga gidak-on? Sa pipila ka rason:

• Ang mga pila dili aktibo nga gigamit
• Kini mga high-speed nga pila, ug karon hinay ang mga konsumedor
• Kini kusog nga mga pila, adunay aberya ug ang mga konsumedor nag-apas

bugas. 14. Duha ka dagkong pila nga adunay lainlaing mga paagi sa pag-synchronize

Karon nahulog ang Broker 3.

bugas. 15. Ang Broker 3 nahulog, nagbilin usa ka agalon ug salamin sa matag pila

Ang Broker 3 mibalik sa online ug bag-ong mga salamin gihimo. Main Queue A nagsugod sa pagkopya sa kasamtangan nga mga mensahe ngadto sa bag-ong salamin, ug niining panahona ang Queue dili magamit. Nagkinahanglan og duha ka oras aron makopya ang datos, nga moresulta sa duha ka oras nga downtime alang niini nga Queue!

Bisan pa, ang Queue B nagpabilin nga magamit sa tibuuk nga panahon. Gisakripisyo niya ang pipila ka redundancy para sa accessibility.

bugas. 16. Ang pila nagpabilin nga dili magamit sa panahon sa pag-synchronize

Human sa duha ka oras, ang Queue A magamit usab ug makasugod na usab sa pagdawat og mga pagbasa ug pagsulat.

Mga Update

Kini nga pag-block nga pamatasan sa panahon sa pag-synchronize nagpalisud sa pag-update sa mga cluster nga adunay daghang mga pila. Sa usa ka punto, ang master node kinahanglan nga i-restart, nga nagpasabut nga pagbalhin sa usa ka salamin o pag-disable sa pila samtang gi-upgrade ang server. Kon pilion nato ang pagbalhin, mawala ang atong mga mensahe kon ang mga salamin dili madungan. Sa kasagaran, sa panahon sa usa ka broker outage, ang usa ka failover sa usa ka unsynchronized nga salamin wala gihimo. Kini nagpasabot nga sa diha nga ang broker mobalik, kita dili mawad-an sa bisan unsa nga mga mensahe, ang bugtong kadaot mao ang usa ka yano nga pila. Ang mga lagda sa pamatasan kung ang usa ka broker nadiskonekta gitakda sa palisiya ha-promote-on-shutdown. Mahimo nimong itakda ang usa sa duha nga mga kantidad:

• always= transisyon ngadto sa unsynchronized nga mga salamin gipalihok
• when-synced= transisyon sa usa ka synchronized nga salamin lamang, kung dili ang pila mahimong dili mabasa ug dili masulat. Ang pila mobalik sa serbisyo sa diha nga ang broker mobalik

Usa ka paagi o lain, nga adunay daghang mga pila kinahanglan nimo nga pilion tali sa pagkawala sa datos ug pagkadili magamit.

Kung ang Pagkaanaa Nagpauswag sa Seguridad sa Data

Adunay usa pa ka komplikasyon nga ikonsiderar sa dili pa maghimo usa ka desisyon. Samtang ang awtomatik nga pag-synchronize mas maayo alang sa redundancy, sa unsang paagi kini makaapekto sa seguridad sa datos? Siyempre, uban ang mas maayo nga redundancy, ang RabbitMQ dili kaayo mawad-an sa kasamtangan nga mga mensahe, apan komosta ang mga bag-ong mensahe gikan sa mga magmamantala?

Dinhi kinahanglan nimong tagdon ang mosunod:

• Mahimo bang ibalik lang sa magmamantala ang usa ka sayup ug ipasulay pag-usab ang upstream nga serbisyo o tiggamit sa ulahi?
• Mahimo bang i-save sa magmamantala ang mensahe sa lokal o sa usa ka database aron sulayan pag-usab sa ulahi?

Kung ang magmamantala mahimo ra nga isalikway ang mensahe, nan sa tinuud, ang pagpaayo sa pagka-access makapauswag usab sa seguridad sa datos.

Busa, kinahanglang mangitag balanse, ug ang solusyon nagdepende sa espesipikong kahimtang.

Mga problema sa ha-promote-on-failure=when-synced

Ideya ha-promote-on-kapakyasan= kung gi-sync mao nga atong mapugngan ang pagbalhin ngadto sa usa ka unsynchronized nga salamin ug sa ingon malikayan ang pagkawala sa datos. Ang pila nagpabilin nga dili mabasa o masulat. Hinuon, gisulayan namon nga mabawi ang nahagsa nga broker nga wala’y hunong ang datos niini aron makapadayon kini nga molihok ingon usa ka agalon nga wala’y pagkawala sa datos.

Apan (ug kini usa ka dako apan) kung ang broker nawad-an sa iyang data, nan kita adunay usa ka dako nga problema: ang pila nawala! Nawala ang tanan nga datos! Bisan kung ikaw adunay mga salamin nga kasagaran makaapas sa panguna nga pila, kana nga mga salamin gilabay usab.

Aron madugangan pag-usab ang usa ka node nga adunay parehas nga ngalan, gisultihan namon ang cluster nga kalimtan ang nawala nga node (uban ang command rabbitmqctl forget_cluster_node) ug magsugod ug bag-ong broker nga adunay parehas nga hostname. Samtang ang cluster nahinumdom sa nawala nga node, kini nahinumdom sa daan nga pila ug unsynchronized salamin. Kung ang usa ka cluster gisultihan nga kalimtan ang usa ka ilo nga node, kana nga pila makalimtan usab. Karon kinahanglan naton nga ipahayag kini pag-usab. Nawala namon ang tanan nga datos, bisan kung kami adunay mga salamin nga adunay usa ka partial nga set sa datos. Mas maayo nga mobalhin sa usa ka non-synchronize nga salamin!

Busa, ang manwal nga pag-synchronize (ug pagkapakyas sa pag-synchronize) inubanan sa ha-promote-on-failure=when-synced, sa akong opinyon, medyo peligroso. Ang mga docs nag-ingon nga kini nga opsyon anaa alang sa data security, apan kini usa ka double-edged nga kutsilyo.

Master rebalancing

Sama sa gisaad, mibalik kami sa problema sa pagtipon sa tanan nga mga agalon sa usa o daghang mga node. Mahimo pa gani kini nga mahitabo isip resulta sa usa ka rolling cluster update. Sa tulo ka node cluster, ang tanang master queues matigom sa usa o duha ka node.

Ang pagbalanse sa mga agalon mahimong problema sa duha ka hinungdan:

• Wala’y maayong mga himan aron mahimo ang pagbalanse
• Pag-synchronize sa pila

Adunay usa ka ikatulo nga partido alang sa pagbalanse plugin, nga dili opisyal nga gisuportahan. Mahitungod sa ikatulong partido nga mga plugin sa RabbitMQ nga manwal miingon: “Ang plugin naghatag og pipila ka dugang nga configuration ug reporting tools, apan wala gisuportahan o gipamatud-an sa RabbitMQ team. Gamita sa imong kaugalingong risgo."

Adunay lain nga lansis aron mapalihok ang panguna nga pila pinaagi sa mga palisiya sa HA. Ang manwal naghisgot script alang niini. Kini molihok sama niini:

• Gitangtang ang tanan nga mga salamin gamit ang usa ka temporaryo nga palisiya nga adunay mas taas nga prayoridad kaysa sa kasamtangan nga palisiya sa HA.
• Gibag-o ang temporaryo nga polisiya sa HA aron magamit ang node mode, nga nagtino sa node diin kinahanglan ibalhin ang master queue.
• Gi-synchronize ang pila para sa pagduso sa paglalin.
• Pagkahuman sa paglalin, tangtangon ang temporaryo nga palisiya. Ang inisyal nga polisiya sa HA adunay epekto ug ang gikinahanglan nga gidaghanon sa mga salamin gihimo.

Ang downside mao nga kini nga pamaagi mahimong dili molihok kung ikaw adunay daghang mga pila o estrikto nga mga kinahanglanon sa pag-usab.

Karon atong tan-awon kung giunsa ang RabbitMQ clusters nagtrabaho sa mga partisyon sa network.

Pagkawala sa koneksyon

Ang mga node sa usa ka gipang-apod-apod nga sistema konektado sa mga link sa network, ug ang mga link sa network mahimo ug ma-disconnect. Ang frequency sa outages nagdepende sa lokal nga imprastraktura o sa pagkakasaligan sa pinili nga panganod. Sa bisan unsa nga kaso, ang gipang-apod-apod nga mga sistema kinahanglan nga makasagubang niini. Sa makausa pa kami adunay kapilian tali sa pagkaanaa ug pagkamakanunayon, ug usab ang maayong balita mao nga ang RabbitMQ naghatag sa duha nga kapilian (dili lang sa parehas nga oras).

Uban sa RabbitMQ kami adunay duha ka panguna nga kapilian:

• Tugoti ang lohikal nga dibisyon (split-brain). Gisiguro niini ang pagkaanaa, apan mahimong hinungdan sa pagkawala sa datos.
• I-disable ang lohikal nga pagbulag. Mahimong moresulta sa hamubo nga pagkawala sa pagkaanaa depende kung giunsa ang pagkonektar sa mga kliyente sa cluster. Mahimo usab nga mosangpot sa pagkompleto nga dili magamit sa usa ka duha ka node cluster.

Apan unsa ang lohikal nga panagbulag? Kini kung ang usa ka cluster nabahin sa duha tungod sa pagkawala sa mga koneksyon sa network. Sa matag kilid, ang mga salamin gi-promote nga usa ka agalon, aron adunay daghang mga agalon matag turno.

bugas. 17. Panguna nga pila ug duha ka salamin, matag usa sa bulag nga node. Unya ang usa ka kapakyasan sa network mahitabo ug ang usa ka salamin natangtang. Ang nahimulag nga node nakakita nga ang laing duha nahulog ug nagpasiugda sa mga salamin niini ngadto sa agalon. Adunay kami karon nga duha ka punoan nga pila, parehas nga masulat ug mabasa.

Kung ang mga magmamantala magpadala og datos sa duha ka mga agalon, kita adunay duha ka magkalahi nga mga kopya sa pila.

Ang lainlain nga mga mode sa RabbitMQ naghatag bisan unsang pagkaanaa o pagkamakanunayon.

Ignore mode (default)

Kini nga mode nagsiguro sa pagka-access. Human sa pagkawala sa koneksyon, usa ka lohikal nga panagbulag mahitabo. Human mapasig-uli ang koneksyon, ang tagdumala kinahanglang magdesisyon kon asa nga partisyon ang hatagan ug prayoridad. Ang nawala nga bahin i-restart ug ang tanan nga natipon nga datos sa kana nga bahin mawala.

bugas. 18. Tulo ka magmamantala ang nakig-uban sa tulo ka mga broker. Sa sulod, ang cluster nag-ruta sa tanan nga mga hangyo ngadto sa nag-unang pila sa Broker 2.

Karon nawala na ang Broker 3. Nakita niya nga nahulog ang ubang mga broker ug gipasiugda ang iyang salamin sa agalon. Ingon niini kung giunsa mahitabo ang usa ka lohikal nga panagbulag.

bugas. 19. Logical division (split-brain). Ang mga rekord moadto sa duha ka punoan nga pila, ug ang duha ka kopya managlahi.

Ang koneksyon gipahiuli, apan ang lohikal nga panagbulag nagpabilin. Ang tagdumala kinahanglan nga mano-mano nga pilion ang nawala nga bahin. Sa kaso sa ubos, ang tagdumala nag-reboot sa Broker 3. Ang tanan nga mga mensahe nga wala niya madala sa pagpadala nawala.

bugas. 20. Gi-disable sa tagdumala ang Broker 3.

bugas. 21. Ang tigdumala magsugod sa Broker 3 ug kini moapil sa cluster, mawala ang tanang mensahe nga nahibilin didto.

Atol sa pagkawala sa koneksyon ug pagkahuman sa pagpahiuli niini, ang cluster ug kini nga pila magamit alang sa pagbasa ug pagsulat.

Autoheal mode

Ang pagtrabaho parehas sa Ignore mode, gawas nga ang cluster mismo awtomatikong mopili sa nawala nga bahin pagkahuman sa pagbahin ug pagpasig-uli sa koneksyon. Ang nawala nga bahin mobalik sa cluster nga walay sulod, ug ang pila nawad-an sa tanan nga mga mensahe nga gipadala lamang sa kana nga kilid.

Ihunong ang Minority Mode

Kung dili namo gusto nga tugutan ang lohikal nga partitioning, nan ang among kapilian mao ang pagsalikway sa mga pagbasa ug pagsulat sa gamay nga bahin pagkahuman sa partition sa cluster. Kung nakita sa broker nga naa sa gamay nga bahin, gisuspinde ang trabaho, nga mao, gisirad-an ang tanan nga naa na nga koneksyon ug gibalibaran ang bisan unsang mga bag-o. Kausa matag segundo kini nagsusi alang sa pagpasig-uli sa koneksyon. Kung mabalik ang koneksyon, magpadayon kini sa operasyon ug moapil sa cluster.

bugas. 22. Tulo ka magmamantala ang nakig-uban sa tulo ka mga broker. Sa sulod, ang cluster nag-ruta sa tanan nga mga hangyo ngadto sa nag-unang pila sa Broker 2.

Ang mga Broker 1 ug 2 unya gibulag gikan sa Broker 3. Imbis nga i-promote ang ilang salamin aron mahimong master, ang Broker 3 nagsuspinde ug mahimong dili magamit.

bugas. 23. Ang Broker 3 mihunong, gidiskonekta ang tanan nga mga kliyente, ug gisalikway ang mga hangyo sa koneksyon.

Kung mabalik ang koneksyon, mobalik kini sa cluster.

Atong tan-awon ang lain nga pananglitan kung diin ang panguna nga pila naa sa Broker 3.

bugas. 24. Panguna nga pila sa Broker 3.

Unya ang sama nga pagkawala sa koneksyon mahitabo. Ang Broker 3 mihunong tungod kay naa kini sa gamay nga bahin. Sa pikas nga bahin, nakita sa mga node nga nahulog ang Broker 3, mao nga ang daan nga salamin gikan sa Brokers 1 ug 2 gi-promote aron mahimong master.

bugas. 25. Pagbalhin ngadto sa Broker 2 kung ang Broker 3 dili magamit.

Kung gipahiuli ang koneksyon, ang Broker 3 moapil sa cluster.

bugas. 26. Ang cluster mibalik sa normal nga operasyon.

Ang importante nga masabtan dinhi mao nga kita makakuha og pagkamakanunayon, apan kita usab makakuha og anaa, kung Malampuson namon nga ibalhin ang mga kliyente sa kadaghanan sa seksyon. Alang sa kadaghanan nga mga sitwasyon, ako mismo ang mopili sa Pause Minority mode, apan kini nagdepende gayud sa indibidwal nga kaso.

Aron masiguro ang pagkaanaa, hinungdanon nga masiguro nga ang mga kliyente malampuson nga makonektar sa host. Atong tan-awon ang atong mga kapilian.

Pagsiguro sa Koneksyon sa Customer

Adunay kami daghang mga kapilian kung unsaon pagdirekta ang mga kliyente sa panguna nga bahin sa cluster o sa mga nagtrabaho nga mga node (pagkahuman mapakyas ang usa ka node) pagkahuman sa pagkawala sa koneksyon. Una, atong hinumdoman nga ang usa ka piho nga pila gi-host sa usa ka piho nga node, apan ang pag-ruta ug mga palisiya gisundog sa tanan nga mga node. Ang mga kliyente mahimong magkonektar sa bisan unsang node, ug ang internal nga ruta magtultol kanila kung asa sila kinahanglan nga moadto. Apan kung ang usa ka node gisuspinde, kini nagsalikway sa mga koneksyon, mao nga ang mga kliyente kinahanglan nga magkonektar sa laing node. Kung mahulog ang node, gamay ra ang iyang mahimo.

Ang among mga kapilian:

• Ang cluster gi-access gamit ang load balancer nga nag-cycle lang sa mga node ug ang mga kliyente mosulay pag-usab sa pagkonektar hangtud nga malampuson. Kung ang usa ka node nahulog o gisuspinde, nan ang pagsulay sa pagkonektar sa kana nga node mapakyas, apan ang sunod nga pagsulay moadto sa ubang mga server (sa usa ka round-robin nga paagi). Kini angayan alang sa usa ka hamubo nga pagkawala sa koneksyon o usa ka downed server nga dali nga ibalik.
• I-access ang cluster pinaagi sa load balancer ug kuhaa ang mga nasuspinde/napakyas nga mga node gikan sa lista sa diha nga kini mamatikdan. Kung buhaton namon kini sa madali, ug kung ang mga kliyente makahimo pag-usab sa koneksyon, nan makab-ot namon ang kanunay nga pagkaanaa.
• Hatagi ang matag kliyente og lista sa tanang node, ug ang kliyente random nga mopili og usa niini kon magkonektar. Kung makadawat kini usa ka sayup sa pagsulay sa pagkonektar, kini mobalhin sa sunod nga node sa lista hangtod nga magkonektar.
• Kuhaa ang trapiko gikan sa usa ka napakyas/gisuspinde nga node gamit ang DNS. Gihimo kini gamit ang gamay nga TTL.

kaplag

Ang RabbitMQ clustering adunay mga bentaha ug disbentaha. Ang labing seryoso nga mga disbentaha mao ang:

• sa pag-apil sa usa ka cluster, ang mga node molabay sa ilang datos;
• Ang pag-ali sa pag-synchronize hinungdan nga dili magamit ang pila.

Ang tanan nga lisud nga mga desisyon naggikan niining duha ka bahin sa arkitektura. Kung ang RabbitMQ makatipig sa datos kung ang cluster gihiusa pag-usab, nan ang pag-synchronize mas paspas. Kung kini makahimo sa non-blocking synchronization, mas maayo nga suportahan ang dagkong mga pila. Ang pag-ayo niining duha ka mga isyu makapauswag pag-ayo sa performance sa RabbitMQ isip usa ka fault-tolerant ug anaa kaayo nga teknolohiya sa pagmemensahe. Magduhaduha ko sa pagrekomendar sa RabbitMQ nga adunay clustering sa mosunod nga mga sitwasyon:

• Dili kasaligan nga network.
• Dili kasaligan nga pagtipig.
• Taas kaayog pila.

Pag-abut sa mga setting sa taas nga magamit, hunahunaa ang mosunod:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (o autoheal)
• padayon nga mga mensahe
• pagsiguro nga ang mga kliyente makonektar sa aktibo nga node kung ang pipila ka mga node mapakyas

Para sa pagkamakanunayon (data security), ikonsiderar ang mosunod nga mga setting:

• Gikumpirma sa Publisher ug Manual Acknowledgement sa bahin sa konsumidor
• ha-promote-on-failure=when-synced, kon ang mga magmamantala makasulay pag-usab sa ulahi ug kon ikaw adunay kasaligang storage! Kung dili ibutang =always.
• ha-sync-mode=automatic (apan alang sa daghang dili aktibo nga pila nga manual mode mahimo’g kinahanglan; hunahunaa usab kung ang pagkawalay mahimo hinungdan nga mawala ang mga mensahe)
• Ihunong ang Minority mode
• padayon nga mga mensahe

Wala pa namo mahisgoti ang tanang isyu sa fault tolerance ug taas nga pagkaanaa; sama pananglit, kung unsaon paghimo nga luwas ang mga pamaagi sa administratibo (sama sa mga rolling update). Kinahanglan usab natong hisgutan ang bahin sa federation ug ang Shovel plugin.

Kung nasipyat pa ko, palihog pahibaloa ko.

Tan-awa usab ang akong post, diin naghimo ako usa ka kadaot sa usa ka cluster sa RabbitMQ gamit ang Docker ug Blockade aron sulayan ang pipila nga mga senaryo sa pagkawala sa mensahe nga gihulagway sa kini nga artikulo.

Nauna nga mga artikulo sa serye:
Num. 1 - habr.com/ru/company/itsumma/blog/416629
Num. 2 - habr.com/ru/company/itsumma/blog/418389
Num. 3 - habr.com/ru/company/itsumma/blog/437446

Source: www.habr.com