Malaking paksa ang fault tolerance at mataas na availability, kaya maglalaan kami ng magkakahiwalay na artikulo sa RabbitMQ at Kafka. Ang artikulong ito ay tungkol sa RabbitMQ, at ang susunod ay tungkol sa Kafka, kung ihahambing sa RabbitMQ. Ito ay isang mahabang artikulo, kaya maging komportable ang iyong sarili.
Tingnan natin ang fault tolerance, consistency, at high availability (HA) na mga diskarte at ang mga tradeoff na ginagawa ng bawat diskarte. Maaaring tumakbo ang RabbitMQ sa isang kumpol ng mga node - at pagkatapos ay inuri bilang isang distributed system. Pagdating sa mga distributed system, madalas nating pinag-uusapan ang consistency at availability.
Inilalarawan ng mga konseptong ito kung paano kumikilos ang isang sistema kapag nabigo ito. Pagkabigo ng koneksyon sa network, pagkabigo ng server, pagkabigo ng hard drive, pansamantalang hindi available ang server dahil sa koleksyon ng basura, pagkawala ng packet, o pagbagal ng koneksyon sa network. Ang lahat ng ito ay maaaring humantong sa pagkawala ng data o mga salungatan. Lumalabas na halos imposibleng maglagay ng system na parehong ganap na pare-pareho (walang pagkawala ng data, walang pagkakaiba-iba ng data) at magagamit (tatanggap ng mga pagbabasa at pagsusulat) para sa lahat ng mga senaryo ng pagkabigo.
Makikita natin na ang consistency at availability ay nasa magkabilang dulo ng spectrum, at kailangan mong pumili kung aling paraan ang mag-optimize. Ang mabuting balita ay sa RabbitMQ posible ang pagpipiliang ito. Mayroon kang mga ganitong uri ng "nerdy" na mga lever upang ilipat ang balanse patungo sa higit na pare-pareho o higit na accessibility.
Bibigyan namin ng espesyal na pansin kung aling mga pagsasaayos ang humahantong sa pagkawala ng data dahil sa mga nakumpirmang tala. Mayroong chain of responsibility sa pagitan ng mga publisher, broker at consumer. Kapag naipadala na ang mensahe sa broker, trabaho niya na huwag mawala ang mensahe. Kapag kinikilala ng broker ang pagtanggap ng publisher ng mensahe, hindi namin inaasahan na mawawala ito. Ngunit makikita natin na maaaring mangyari talaga ito depende sa configuration ng iyong broker at publisher.
Single Node Resilience Primitives
Matatag na Pagpila/Pagruruta
Mayroong dalawang uri ng mga pila sa RabbitMQ: matibay at hindi matibay. Ang lahat ng mga pila ay nai-save sa Mnesia database. Ang matibay na mga pila ay muling ina-advertise sa pagsisimula ng node at sa gayon ay nabubuhay sa mga pag-restart, pag-crash ng system, o pag-crash ng server (hangga't nananatili ang data). Nangangahulugan ito na hangga't idineklara mo na ang pagruruta (palitan) at ang pila ay nababanat, ang imprastraktura ng pagpila/pagruruta ay babalik online.
Ang mga pabagu-bagong pila at pagruruta ay aalisin kapag ang node ay na-restart.
Mga paulit-ulit na mensahe
Dahil lang sa matibay ang isang queue ay hindi nangangahulugan na ang lahat ng mga mensahe nito ay makakaligtas sa pag-restart ng node. Mga mensahe lang na itinakda ng publisher bilang nababanat (persistent). Ang mga paulit-ulit na mensahe ay lumilikha ng karagdagang pag-load sa broker, ngunit kung ang pagkawala ng mensahe ay hindi katanggap-tanggap, wala nang ibang opsyon.
kanin. 1. Sustainability matrix
Clustering na may queue mirroring
Para makaligtas sa pagkawala ng isang broker, kailangan natin ng redundancy. Maaari naming pagsamahin ang maraming RabbitMQ node sa isang cluster, at pagkatapos ay magdagdag ng karagdagang redundancy sa pamamagitan ng pagkopya ng mga pila sa pagitan ng maraming node. Sa ganitong paraan, kung nabigo ang isang node, hindi kami mawawalan ng data at mananatiling available.
Pag-mirror ng pila:
- isang pangunahing pila (master), na tumatanggap ng lahat ng write at read command
- isa o higit pang salamin na tumatanggap ng lahat ng mensahe at metadata mula sa pangunahing pila. Ang mga salamin na ito ay wala doon para sa scaling, ngunit para lamang sa redundancy.
kanin. 2. Queue mirroring
Ang pag-mirror ay itinakda ng naaangkop na patakaran. Dito maaari mong piliin ang koepisyent ng pagtitiklop at maging ang mga node kung saan dapat matatagpuan ang pila. Mga halimbawa:
ha-mode: allha-mode: exactly, ha-params: 2(isang master at isang salamin)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
Pagkumpirma ng publisher
Upang makamit ang pare-parehong pag-record, kinakailangan ang Mga Pagkumpirma ng Publisher. Kung wala ang mga ito, may panganib na mawala ang mga mensahe. Ang kumpirmasyon ay ipinadala sa publisher pagkatapos maisulat ang mensahe sa disk. Ang RabbitMQ ay nagsusulat ng mga mensahe sa disk hindi sa pagtanggap, ngunit sa pana-panahong batayan, sa rehiyon ng ilang daang millisecond. Kapag na-mirror ang isang queue, ipapadala lamang ang isang pagkilala pagkatapos maisulat din ng lahat ng mga salamin ang kanilang kopya ng mensahe sa disk. Nangangahulugan ito na ang paggamit ng mga kumpirmasyon ay nagdaragdag ng latency, ngunit kung ang seguridad ng data ay mahalaga, kung gayon kinakailangan ang mga ito.
Failover pila
Kapag ang isang broker ay huminto o nag-crash, lahat ng mga pinuno ng pila (mga master) sa node na iyon ay nag-crash kasama nito. Pinipili ng cluster ang pinakamatandang salamin ng bawat master at itinataguyod ito bilang bagong master.
kanin. 3. Maramihang naka-mirror na pila at ang kanilang mga patakaran
Bumaba ang Broker 3. Tandaan na ang Queue C mirror sa Broker 2 ay pino-promote sa master. Tandaan din na may ginawang bagong salamin para sa Queue C sa Broker 1. Palaging sinusubukan ng RabbitMQ na panatilihin ang replication factor na tinukoy sa iyong mga patakaran.
kanin. 4. Nabigo ang Broker 3, na naging dahilan upang mabigo ang queue C
Ang susunod na Broker 1 ay bumagsak! Isang broker na lang ang natitira namin. Ang Queue B mirror ay na-promote sa master.
Fig. 5
Ibinalik namin ang Broker 1. Hindi alintana kung gaano kahusay ang data na nakaligtas sa pagkawala at pagbawi ng broker, lahat ng naka-mirror na mensahe sa pila ay itatapon sa pag-restart. Mahalagang tandaan ito dahil may mga kahihinatnan. Titingnan natin ang mga implikasyon na ito sa ilang sandali. Kaya ang Broker 1 ay miyembro na ngayon ng cluster, at sinusubukan ng cluster na sumunod sa mga patakaran at samakatuwid ay gumagawa ng mga salamin sa Broker 1.
Sa kasong ito, ang pagkawala ng Broker 1 ay kumpleto, pati na ang data, kaya ang hindi naka-mirror na Queue B ay ganap na nawala.
kanin. 6. Bumalik sa serbisyo ang Broker 1
Nagbalik online ang Broker 3, kaya ibinalik ng pila A at B ang mga salamin na ginawa dito upang matugunan ang kanilang mga patakaran sa HA. Ngunit ngayon ang lahat ng mga pangunahing pila ay nasa isang node! Ito ay hindi perpekto, ang isang pantay na pamamahagi sa pagitan ng mga node ay mas mahusay. Sa kasamaang palad, walang maraming mga pagpipilian dito para sa muling pagbabalanse ng mga master. Babalik tayo sa isyung ito mamaya dahil kailangan muna nating tingnan ang queue synchronization.
kanin. 7. Bumalik sa serbisyo ang Broker 3. Lahat ng pangunahing pila sa isang node!
Kaya ngayon dapat kang magkaroon ng ideya kung paano nagbibigay ang mga salamin ng kalabisan at pagpapahintulot sa kasalanan. Tinitiyak nito ang pagkakaroon sa kaganapan ng isang solong pagkabigo ng node at pinoprotektahan laban sa pagkawala ng data. Ngunit hindi pa tayo tapos, dahil sa katotohanan ay mas kumplikado ito.
Pag-synchronize
Kapag gumagawa ng bagong salamin, ang lahat ng bagong mensahe ay palaging gagayahin sa salamin na ito at sa iba pa. Tulad ng para sa umiiral na data sa master queue, maaari naming kopyahin ito sa isang bagong salamin, na nagiging isang kumpletong kopya ng master. Maaari din nating piliin na huwag kopyahin ang mga kasalukuyang mensahe at hayaan ang pangunahing pila at ang bagong salamin na magtagpo sa oras, na may mga bagong mensahe na dumarating sa buntot at mga kasalukuyang mensahe na umaalis sa ulo ng pangunahing pila.
Ang pag-synchronize na ito ay awtomatikong ginagawa o manu-mano at pinamamahalaan gamit ang isang patakaran sa pila. Tingnan natin ang isang halimbawa.
Mayroon kaming dalawang naka-mirror na pila. Ang Queue A ay awtomatikong naka-synchronize, at ang Queue B ay manu-manong naka-synchronize. Ang parehong pila ay naglalaman ng sampung mensahe.
kanin. 8. Dalawang pila na may magkakaibang mga mode ng pag-synchronize
Ngayon ay nawawalan tayo ng Broker 3.
kanin. 9. Nahulog ang Broker 3
Ang Broker 3 ay bumalik sa serbisyo. Lumilikha ang cluster ng salamin para sa bawat queue sa bagong node at awtomatikong sini-synchronize ang bagong Queue A sa master. Gayunpaman, nananatiling walang laman ang salamin ng bagong Queue B. Sa ganitong paraan mayroon kaming ganap na redundancy sa Queue A at isang salamin lamang para sa mga kasalukuyang Queue B na mensahe.
kanin. 10. Ang bagong salamin ng Queue A ay tumatanggap ng lahat ng kasalukuyang mensahe, ngunit ang bagong salamin ng Queue B ay hindi.
Sampung higit pang mensahe ang dumating sa magkabilang pila. Ang Broker 2 ay nag-crash at ang Queue A ay gumulong pabalik sa pinakalumang salamin, na nasa Broker 1. Walang pagkawala ng data kapag nabigo ito. Sa Queue B, mayroong dalawampung mensahe sa master at sampu lang sa salamin dahil hindi kailanman ginagaya ng queue na ito ang orihinal na sampung mensahe.
kanin. 11. Ang Queue A ay babalik sa Broker 1 nang hindi nawawala ang mga mensahe
Sampung pang mensahe ang dumating sa magkabilang pila. Ngayon nag-crash ang Broker 1. Ang Queue A ay madaling lumipat sa salamin nang hindi nawawala ang mga mensahe. Gayunpaman, nagkakaproblema ang Queue B. Sa puntong ito maaari naming i-optimize ang alinman sa availability o consistency.
Kung gusto naming i-optimize ang pagiging naa-access, pagkatapos ay ang patakaran ha-promote-on-failure dapat na naka-install sa palagi. Ito ang default na halaga, kaya hindi mo matukoy ang patakaran sa lahat. Sa kasong ito, mahalagang pinapayagan namin ang mga pagkabigo sa mga hindi naka-synchronize na salamin. Magdudulot ito ng pagkawala ng mga mensahe, ngunit mananatiling nababasa at nasusulat ang pila.
kanin. 12. Ang Queue A ay ibinabalik sa Broker 3 nang hindi nawawala ang mga mensahe. Ang Queue B ay bumabalik sa Broker 3 na may sampung mensaheng nawala
Maaari din naming i-install ha-promote-on-failure sa kahulugan when-synced. Sa kasong ito, sa halip na bumalik sa salamin, maghihintay ang pila hanggang sa bumalik sa online mode ang Broker 1 kasama ang data nito. Matapos itong bumalik, ang pangunahing pila ay bumalik sa Broker 1 nang walang anumang pagkawala ng data. Ang kakayahang magamit ay isinakripisyo para sa seguridad ng data. Ngunit ito ay isang mapanganib na mode na maaaring humantong sa kumpletong pagkawala ng data, na titingnan natin sa ilang sandali.
kanin. 13. Nananatiling hindi magagamit ang Queue B pagkatapos mawala ang Broker 1
Maaari mong itanong, "Mas mabuti bang huwag gumamit ng awtomatikong pag-synchronize?" Ang sagot ay ang pag-synchronize ay isang blocking operation. Sa panahon ng pag-synchronize, ang pangunahing queue ay hindi maaaring magsagawa ng anumang read o write operations!
Tingnan natin ang isang halimbawa. Ngayon napakahabang pila namin. Paano sila lalago sa ganoong laki? Para sa ilang mga kadahilanan:
- Hindi aktibong ginagamit ang mga pila
- Ito ay mabilis na mga pila, at ngayon ay mabagal ang mga mamimili
- Napakabilis ng pila, nagkaroon ng aberya at humahabol ang mga mamimili
kanin. 14. Dalawang malalaking pila na may magkakaibang mga mode ng pag-synchronize
Ngayon bumagsak ang Broker 3.
kanin. 15. Bumagsak ang Broker 3, nag-iiwan ng isang master at salamin sa bawat pila
Nagbabalik online ang Broker 3 at nalikha ang mga bagong salamin. Ang Pangunahing Queue A ay nagsisimulang kopyahin ang mga kasalukuyang mensahe sa bagong salamin, at sa panahong ito ay hindi available ang Queue. Tumatagal ng dalawang oras upang kopyahin ang data, na nagreresulta sa dalawang oras na downtime para sa Queue na ito!
Gayunpaman, nananatiling available ang Queue B sa buong panahon. Nagsakripisyo siya ng kaunting redundancy para sa accessibility.
kanin. 16. Ang pila ay nananatiling hindi magagamit sa panahon ng pag-synchronize
Pagkatapos ng dalawang oras, magiging available din ang Queue A at maaaring magsimulang tumanggap ng mga reads at writes muli.
Update
Ang pag-block na ito sa panahon ng pag-synchronize ay nagpapahirap sa pag-update ng mga cluster na may napakalaking pila. Sa ilang mga punto, ang master node ay kailangang i-restart, na nangangahulugang alinman sa paglipat sa isang salamin o hindi pagpapagana ng pila habang ang server ay ina-upgrade. Kung pipiliin naming lumipat, mawawalan kami ng mga mensahe kung hindi naka-synchronize ang mga salamin. Bilang default, sa panahon ng pagkawala ng broker, ang isang failover sa isang hindi naka-synchronize na salamin ay hindi ginaganap. Nangangahulugan ito na sa sandaling bumalik ang broker, hindi kami nawawalan ng anumang mensahe, ang tanging pinsala ay isang simpleng pila. Ang mga patakaran ng pag-uugali kapag ang isang broker ay nadiskonekta ay itinakda ng patakaran ha-promote-on-shutdown. Maaari kang magtakda ng isa sa dalawang halaga:
always= pinagana ang paglipat sa mga hindi naka-synchronize na salaminwhen-synced= paglipat sa isang naka-synchronize na salamin lamang, kung hindi, ang pila ay magiging hindi nababasa at hindi nasusulat. Ang pila ay babalik sa serbisyo sa sandaling bumalik ang broker
Sa isang paraan o iba pa, na may malalaking pila kailangan mong pumili sa pagitan ng pagkawala ng data at hindi magagamit.
Kapag Nagpapabuti ang Availability ng Data Security
May isa pang komplikasyon na dapat isaalang-alang bago gumawa ng desisyon. Bagama't mas mahusay ang awtomatikong pag-synchronize para sa redundancy, paano ito nakakaapekto sa seguridad ng data? Siyempre, sa mas magandang redundancy, mas malamang na mawala ang RabbitMQ ng mga kasalukuyang mensahe, ngunit paano naman ang mga bagong mensahe mula sa mga publisher?
Dito kailangan mong isaalang-alang ang mga sumusunod:
- Maaari bang magbalik lang ng error ang publisher 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 maaari lamang itapon ng publisher ang mensahe, sa katunayan, ang pagpapabuti ng pagiging naa-access ay nagpapabuti din sa seguridad ng data.
Kaya, dapat maghanap ng balanse, at ang solusyon ay depende sa partikular na sitwasyon.
Mga problema sa ha-promote-on-failure=when-synced
Idea ha-promote-on-failure= kapag naka-sync ay pinipigilan namin ang paglipat sa isang hindi naka-synchronize na salamin at sa gayon ay maiwasan ang pagkawala ng data. Ang pila ay nananatiling hindi nababasa o nasusulat. Sa halip, sinusubukan naming i-recover ang nag-crash na broker na buo ang data nito para maipagpatuloy nito ang paggana bilang master nang walang pagkawala ng data.
Ngunit (at ito ay isang malaking ngunit) kung ang broker ay nawala ang kanyang data, pagkatapos ay mayroon kaming isang malaking problema: ang pila ay nawala! Nawala ang lahat ng data! Kahit na mayroon kang mga salamin na halos nakakahabol sa pangunahing pila, ang mga salamin na iyon ay itinatapon din.
Upang muling magdagdag ng node na may parehong pangalan, sinasabi namin sa cluster na kalimutan ang nawalang node (na may command rabbitmqctl forget_cluster_node) at magsimula ng bagong broker na may parehong hostname. Habang naaalala ng cluster ang nawalang node, naaalala nito ang lumang pila at hindi naka-synchronize na mga salamin. Kapag sinabihan ang isang cluster na kalimutan ang isang naulilang node, nakalimutan din ang pila na iyon. Ngayon ay kailangan nating muling ideklara ito. Nawala namin ang lahat ng data, bagama't mayroon kaming mga salamin na may bahagyang hanay ng data. Mas mainam na lumipat sa isang hindi naka-synchronize na salamin!
Samakatuwid, ang manu-manong pag-synchronize (at hindi pag-synchronize) kasama ng ha-promote-on-failure=when-synced, sa aking opinyon, medyo mapanganib. Sinasabi ng mga doc na umiiral ang opsyong ito para sa seguridad ng data, ngunit isa itong kutsilyong may dalawang talim.
Master rebalancing
Tulad ng ipinangako, bumalik kami sa problema ng akumulasyon ng lahat ng mga masters sa isa o ilang mga node. Maaari pa itong mangyari bilang resulta ng isang rolling cluster update. Sa isang three-node cluster, lahat ng master queues ay maiipon sa isa o dalawang node.
Maaaring maging problema ang rebalancing masters sa dalawang dahilan:
- Walang magandang tool para magsagawa ng rebalancing
- Pag-synchronize ng pila
Mayroong ikatlong partido para sa muling pagbabalanse , na hindi opisyal na sinusuportahan. Tungkol sa mga third party na plugin sa manu-manong RabbitMQ : βAng plugin ay nagbibigay ng ilang karagdagang configuration at mga tool sa pag-uulat, ngunit hindi sinusuportahan o na-verify ng RabbitMQ team. Gamitin sa iyong sariling peligro."
May isa pang trick upang ilipat ang pangunahing pila sa pamamagitan ng mga patakaran ng HA. Binanggit ng manual para dito. Ito ay gumagana tulad nito:
- Inaalis ang lahat ng salamin gamit ang isang pansamantalang patakaran na may mas mataas na priyoridad kaysa sa kasalukuyang patakaran ng HA.
- Binabago ang pansamantalang patakaran ng HA upang gamitin ang node mode, na tumutukoy sa node kung saan dapat ilipat ang master queue.
- Sini-synchronize ang pila para sa push migration.
- Pagkatapos makumpleto ang paglipat, tatanggalin ang pansamantalang patakaran. Ang paunang patakaran ng HA ay magkakabisa at ang kinakailangang bilang ng mga salamin ay ginawa.
Ang downside ay ang diskarte na ito ay maaaring hindi gumana kung mayroon kang malalaking queue o mahigpit na mga kinakailangan sa redundancy.
Ngayon tingnan natin kung paano gumagana ang mga kumpol ng RabbitMQ sa mga partisyon ng network.
Pagkawala ng koneksyon
Ang mga node ng isang distributed system ay konektado sa pamamagitan ng mga network link, at ang mga network link ay maaari at madidiskonekta. Ang dalas ng mga pagkawala ay depende sa lokal na imprastraktura o sa pagiging maaasahan ng napiling cloud. Sa anumang kaso, ang mga distributed system ay dapat na makayanan ang mga ito. Muli, mayroon kaming pagpipilian sa pagitan ng kakayahang magamit at pagkakapare-pareho, at muli ang magandang balita ay ang RabbitMQ ay nagbibigay ng parehong mga pagpipilian (hindi lamang sa parehong oras).
Sa RabbitMQ mayroon kaming dalawang pangunahing pagpipilian:
- Payagan ang lohikal na dibisyon (split-brain). Tinitiyak nito ang pagkakaroon, ngunit maaaring magdulot ng pagkawala ng data.
- Huwag paganahin ang lohikal na paghihiwalay. Maaaring magresulta sa panandaliang pagkawala ng availability depende sa kung paano kumonekta ang mga kliyente sa cluster. Maaari ring humantong sa kumpletong kawalan ng available sa isang cluster na may dalawang node.
Ngunit ano ang lohikal na paghihiwalay? Ito ay kapag ang isang cluster ay nahahati sa dalawa dahil sa pagkawala ng mga koneksyon sa network. Sa bawat panig, ang mga salamin ay na-promote sa isang master, nang sa gayon ay may ilang mga master sa bawat pila.
kanin. 17. Pangunahing pila at dalawang salamin, bawat isa sa hiwalay na node. Pagkatapos ay nangyari ang isang pagkabigo sa network at ang isang salamin ay natanggal. Nakita ng nakahiwalay na node na ang dalawa pa ay nahulog at itinataguyod ang mga salamin nito sa master. Mayroon na kaming dalawang pangunahing pila, parehong nasusulat at nababasa.
Kung magpapadala ang mga publisher ng data sa parehong mga master, magkakaroon tayo ng dalawang magkaibang kopya ng queue.
Ang iba't ibang mga mode ng RabbitMQ ay nagbibigay ng alinman sa availability o pare-pareho.
Ignore mode (default)
Tinitiyak ng mode na ito ang pagiging naa-access. Pagkatapos ng pagkawala ng koneksyon, isang lohikal na paghihiwalay ang nangyayari. Pagkatapos maibalik ang pagkakakonekta, dapat magpasya ang administrator kung aling partition ang bibigyan ng priyoridad. Ang natalong bahagi ay ire-restart at ang lahat ng naipon na data sa bahaging iyon ay mawawala.
kanin. 18. Tatlong publisher ang nauugnay sa tatlong broker. Sa panloob, dinadala ng cluster ang lahat ng kahilingan sa pangunahing pila sa Broker 2.
Ngayon ay natatalo na tayo ng Broker 3. Nakita niya na ang ibang mga broker ay nahulog at ipino-promote ang kanyang salamin sa master. Ito ay kung paano nangyayari ang isang lohikal na paghihiwalay.
kanin. 19. Lohikal na dibisyon (split-brain). Ang mga rekord ay napupunta sa dalawang pangunahing pila, at ang dalawang kopya ay naghihiwalay.
Ang pagkakakonekta ay naibalik, ngunit nananatili ang lohikal na paghihiwalay. Dapat manu-manong piliin ng administrator ang natalong panig. Sa kaso sa ibaba, nire-reboot ng administrator ang Broker 3. Nawala ang lahat ng mensahe na hindi niya naipadala.
kanin. 20. Hindi pinagana ng administrator ang Broker 3.
kanin. 21. Sinimulan ng administrator ang Broker 3 at sumali ito sa cluster, nawawala ang lahat ng mga mensaheng naiwan doon.
Sa panahon ng pagkawala ng koneksyon at pagkatapos ng pagpapanumbalik nito, ang cluster at ang pila na ito ay magagamit para sa pagbabasa at pagsusulat.
Autoheal mode
Gumagana nang katulad sa Ignore mode, maliban na ang cluster mismo ay awtomatikong pinipili ang nawawalang bahagi pagkatapos hatiin at ibalik ang pagkakakonekta. Ang natalong bahagi ay babalik sa cluster na walang laman, at ang queue ay mawawala ang lahat ng mga mensahe na ipinadala lamang sa bahaging iyon.
I-pause ang Minority Mode
Kung ayaw naming payagan ang logical partitioning, ang tanging pagpipilian namin ay itapon ang mga reads at writes sa mas maliit na bahagi pagkatapos ng cluster partition. Kapag nakita ng broker na ito ay nasa mas maliit na bahagi, sinuspinde nito ang trabaho, iyon ay, isinasara nito ang lahat ng umiiral na koneksyon at tinatanggihan ang anumang mga bago. Isang beses bawat segundo, sinusuri nito ang pagpapanumbalik ng koneksyon. Kapag naibalik ang pagkakakonekta, magpapatuloy ito sa operasyon at sasali sa cluster.
kanin. 22. Tatlong publisher ang nauugnay sa tatlong broker. Sa panloob, dinadala ng cluster ang lahat ng kahilingan sa pangunahing pila sa Broker 2.
Ang Broker 1 at 2 pagkatapos ay humiwalay mula sa Broker 3. Sa halip na i-promote ang kanilang salamin sa master, ang Broker 3 ay nagsuspinde at nagiging hindi available.
kanin. 23. Ang Broker 3 ay nag-pause, nagdidiskonekta sa lahat ng mga kliyente, at tinatanggihan ang mga kahilingan sa koneksyon.
Kapag naibalik ang pagkakakonekta, babalik ito sa cluster.
Tingnan natin ang isa pang halimbawa kung saan ang pangunahing pila ay nasa Broker 3.
kanin. 24. Pangunahing pila sa Broker 3.
Pagkatapos ang parehong pagkawala ng koneksyon ay nangyayari. Ang Broker 3 ay huminto dahil ito ay nasa mas maliit na bahagi. Sa kabilang panig, nakikita ng mga node na ang Broker 3 ay nahulog, kaya ang mas lumang salamin mula sa Brokers 1 at 2 ay na-promote sa master.
kanin. 25. Paglipat sa Broker 2 kung ang Broker 3 ay hindi magagamit.
Kapag naibalik ang pagkakakonekta, sasali ang Broker 3 sa cluster.
kanin. 26. Ang kumpol ay bumalik sa normal na operasyon.
Ang mahalagang bagay na maunawaan dito ay nakakakuha tayo ng pagkakapare-pareho, ngunit maaari rin tayong makakuha ng availability, kung Matagumpay naming ililipat ang mga kliyente sa karamihan ng seksyon. Para sa karamihan ng mga sitwasyon, personal kong pipiliin ang mode na Pause Minority, ngunit talagang depende ito sa indibidwal na kaso.
Upang matiyak ang pagkakaroon, mahalagang tiyakin na matagumpay na kumonekta ang mga kliyente sa host. Tingnan natin ang aming mga pagpipilian.
Tinitiyak ang Pagkakakonekta ng Customer
Mayroon kaming ilang mga opsyon para sa kung paano idirekta ang mga kliyente sa pangunahing bahagi ng cluster o sa mga gumaganang node (pagkatapos mabigo ang isang node) pagkatapos ng pagkawala ng koneksyon. Una, tandaan natin na ang isang partikular na queue ay naka-host sa isang partikular na node, ngunit ang pagruruta at mga patakaran ay ginagaya sa lahat ng mga node. Ang mga kliyente ay maaaring kumonekta sa anumang node, at ang panloob na pagruruta ay magdidirekta sa kanila kung saan sila dapat pumunta. Ngunit kapag nasuspinde ang isang node, tinatanggihan nito ang mga koneksyon, kaya dapat kumonekta ang mga kliyente sa isa pang node. Kung bumagsak ang node, kaunti lang ang magagawa niya.
Ang aming mga pagpipilian:
- Naa-access ang cluster gamit ang isang load balancer na umiikot lang sa mga node at muling subukan ng mga kliyente ang pagkonekta hanggang sa matagumpay. Kung ang isang node ay bumaba o nasuspinde, ang mga pagtatangka na kumonekta sa node na iyon ay mabibigo, ngunit ang mga kasunod na pagtatangka ay mapupunta sa iba pang mga server (sa isang round-robin na paraan). Ito ay angkop para sa isang panandaliang pagkawala ng koneksyon o isang down na server na mabilis na maibabalik.
- I-access ang cluster sa pamamagitan ng load balancer at alisin ang mga nasuspinde/nabigong node mula sa listahan sa sandaling matukoy ang mga ito. Kung gagawin namin ito nang mabilis, at kung magagawang muling subukan ng mga kliyente ang koneksyon, makakamit namin ang patuloy na kakayahang magamit.
- Bigyan ang bawat kliyente ng listahan ng lahat ng mga node, at random na pipili ang kliyente ng isa sa mga ito kapag kumokonekta. Kung nakatanggap ito ng error kapag sinusubukang kumonekta, lilipat ito sa susunod na node sa listahan hanggang sa kumonekta ito.
- Alisin ang trapiko mula sa isang nabigo/nasuspinde na node gamit ang DNS. Ginagawa ito gamit ang isang maliit na TTL.
Natuklasan
Ang RabbitMQ clustering ay may mga pakinabang at disadvantages nito. Ang pinaka-seryosong disadvantages ay ang:
- kapag sumali sa isang kumpol, itinatapon ng mga node ang kanilang data;
- Ang pagharang sa pag-synchronize ay nagiging sanhi ng pagiging hindi available ng pila.
Ang lahat ng mahihirap na desisyon ay nagmumula sa dalawang tampok na arkitektura na ito. Kung makakapag-save ng data ang RabbitMQ kapag muling pinagsama ang cluster, magiging mas mabilis ang pag-synchronize. Kung ito ay may kakayahang hindi humarang sa pag-synchronize, mas mainam nitong suportahan ang malalaking pila. Ang pag-aayos sa dalawang isyung ito ay lubos na magpapahusay sa pagganap ng RabbitMQ bilang isang fault-tolerant at lubos na magagamit na teknolohiya sa pagmemensahe. Mag-aalangan akong magrekomenda ng RabbitMQ na may clustering sa mga sumusunod na sitwasyon:
- Hindi mapagkakatiwalaang network.
- Hindi mapagkakatiwalaang imbakan.
- Napakahabang pila.
Pagdating sa mga setting ng mataas na availability, isaalang-alang ang sumusunod:
ha-promote-on-failure=alwaysha-sync-mode=manualcluster_partition_handling=ignore(Oautoheal)- paulit-ulit na mga mensahe
- tiyaking kumonekta ang mga kliyente sa aktibong node kapag nabigo ang ilang node
Para sa pagkakapare-pareho (seguridad ng data), isaalang-alang ang mga sumusunod na setting:
- Kinukumpirma ng Publisher at Mga Manu-manong Pagkilala sa panig ng consumer
ha-promote-on-failure=when-synced, kung masusubok muli ng mga publisher sa ibang pagkakataon at kung mayroon kang napaka-maaasahang storage! Kung hindi ay ilagay=always.ha-sync-mode=automatic(ngunit para sa malalaking hindi aktibong pila, maaaring kailanganin ang manual mode; isaalang-alang din kung ang kawalan ng kakayahang magamit ay magiging sanhi ng pagkawala ng mga mensahe)- I-pause ang Minority mode
- paulit-ulit na mga mensahe
Hindi pa namin nasasaklaw ang lahat ng isyu ng fault tolerance at mataas na kakayahang magamit; halimbawa, kung paano ligtas na magsagawa ng mga administratibong pamamaraan (tulad ng mga rolling update). Kailangan din nating pag-usapan ang tungkol sa federation at ang Shovel plugin.
Kung may iba pa akong napalampas, mangyaring ipaalam sa akin.
Tingnan din ang aking , kung saan nagsasagawa ako ng kalituhan sa isang RabbitMQ cluster gamit ang Docker at Blockade upang subukan ang ilan sa mga sitwasyon ng pagkawala ng mensahe na inilarawan sa artikulong ito.
Mga nakaraang artikulo sa serye:
No. 1 -
No. 2 -
No. 3 -
Pinagmulan: www.habr.com