Kasabaran sesar sareng kasadiaan anu luhur mangrupikeun topik anu ageung, janten kami bakal nyéépkeun tulisan anu misah pikeun RabbitMQ sareng Kafka. Tulisan ieu ngeunaan RabbitMQ, sareng anu salajengna ngeunaan Kafka, dibandingkeun sareng RabbitMQ. Ieu artikel panjang, jadi nyieun diri nyaman.

Hayu urang nempo kasabaran kasalahan, konsistensi, jeung kasadiaan tinggi (HA) strategi jeung tradeoffs yén unggal strategi ngajadikeun. RabbitMQ tiasa dijalankeun dina gugusan titik - teras digolongkeun kana sistem anu disebarkeun. Lamun datang ka sistem disebarkeun, urang mindeng ngobrol ngeunaan konsistensi jeung kasadiaan.

Konsep ieu ngajelaskeun kumaha sistem kalakuanana nalika gagal. Kagagalan sambungan jaringan, kagagalan server, kagagalan hard drive, server henteu sayogi samentawis kusabab pengumpulan sampah, leungitna pakét, atanapi sambungan jaringan ngalambatkeun. Sadaya ieu tiasa ngakibatkeun leungitna data atanapi konflik. Tétéla éta ampir teu mungkin pikeun nempatkeun hiji sistem anu duanana sagemblengna konsisten (euweuh leungitna data, euweuh divergence data) jeung sadia (bakal nampa maca jeung nulis) pikeun sakabéh skenario gagal.

Urang bakal ningali yén konsistensi sareng kasadiaan aya dina tungtung spéktrum, sareng anjeun kedah milih cara anu mana pikeun ngaoptimalkeun. Warta anu saé nyaéta kalayan RabbitMQ pilihan ieu mungkin. Anjeun gaduh levers "nerdy" sapertos ieu pikeun mindahkeun kasaimbangan ka arah konsistensi anu langkung ageung atanapi aksés anu langkung ageung.

Urang bakal nengetan husus ka konfigurasi nu ngakibatkeun leungitna data alatan rékaman dikonfirmasi. Aya ranté tanggung jawab antara penerbit, calo jeung konsumén. Sakali pesen dikirimkeun ka calo, éta tugasna teu leungit pesen. Nalika calo ngaku resi penerbit pesen, kami henteu ngarepkeun éta leungit. Tapi urang bakal ningali yén ieu tiasa kajantenan gumantung kana konfigurasi calo sareng penerbit anjeun.

Hiji titik Resilience primitif

antrian tahan banting / Routing

Aya dua jinis antrian dina RabbitMQ: awét sareng henteu awét. Sadaya antrian disimpen dina database Mnesia. Antrian awét diémbarkeun deui nalika ngamimitian node sahingga salamet dibalikan deui, sistem ngadat, atanapi server ngadat (salami datana tetep). Ieu ngandung harti yén salami anjeun nyatakeun routing (bursa) sareng antrian janten tahan banting, infrastruktur antrian / rute bakal uih deui online.

antrian volatile na routing dihapus nalika titik ieu restarted.

Pesen pengkuh

Ngan kusabab antrian awét henteu hartosna yén sadaya pesenna bakal salamet nalika ngamimitian deui titik. Ngan seratan diatur ku penerbit salaku lestari (pengkuh). Pesen pengkuh nyiptakeun beban tambahan dina calo, tapi upami leungitna pesen henteu katampi, maka teu aya pilihan sanés.

Sangu. 1. matriks kelestarian

Clustering kalawan antrian mirroring

Pikeun salamet kaleungitan calo, urang peryogi redundancy. Urang bisa ngagabungkeun sababaraha titik RabbitMQ kana klaster, lajeng nambahkeun redundansi tambahan ku ulang antrian antara sababaraha titik. Ku cara ieu, upami salah sahiji titik gagal, urang moal leungit data sareng tetep sayogi.

Antrian mirroring:

• hiji antrian utama (master), nu narima sagala nulis jeung maca paréntah
• hiji atawa leuwih kaca spion nu narima sagala pesen na metadata ti antrian utama. Eunteung ieu teu aya pikeun skala, tapi murni pikeun redundancy.

Sangu. 2. Antrian mirroring

Mirroring diatur ku kawijakan luyu. Di jerona anjeun tiasa milih koefisien réplikasi sareng bahkan titik dimana antrian kedah aya. conto:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (hiji master sareng hiji eunteung)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Konfirmasi penerbit

Pikeun ngahontal rékaman konsisten, Penerbit Confirms diperlukeun. Tanpa aranjeunna, aya résiko pesen leungit. Konfirmasi dikirim ka penerbit saatos pesen ditulis kana disk. RabbitMQ nyerat pesen ka disk henteu saatos nampi, tapi sacara périodik, dina daérah sababaraha ratus milidetik. Nalika antrian dicerminkeun, pangakuan dikirim ngan saatos sadaya kaca spion ogé parantos nyerat salinan pesenna ka disk. Ieu ngandung harti yén ngagunakeun konfirmasi nambahkeun latency, tapi lamun kaamanan data penting, aranjeunna diperlukeun.

antrian Failover

Nalika calo kaluar atanapi nabrak, sadaya pamimpin antrian (master) dina titik éta nabrak sareng éta. Kluster teras milih eunteung pangkolotna unggal master sareng promosina salaku master énggal.

Sangu. 3. Sababaraha antrian mirrored sarta kawijakan maranéhna

calo 3 turun. Catet yén eunteung Antrian C dina Broker 2 dipromosikeun ka master. Ogé dicatet yén eunteung anyar geus dijieun pikeun antrian C on calo 1. RabbitMQ salawasna usaha pikeun ngajaga faktor réplikasi dieusian dina kawijakan Anjeun.

Sangu. 4. calo 3 gagal, ngabalukarkeun antrian C gagal

Calo salajengna 1 ragrag! Urang ngan boga hiji calo ditinggalkeun. Eunteung Antrian B diwanohkeun ka master.

Gbr. Xnumx

Kami geus balik calo 1. Paduli kumaha ogé data survives leungitna sarta recovery ti calo nu, sadaya pesen antrian mirrored dipiceun kana balikan deui. Ieu penting pikeun dicatet sabab bakal aya konsekuensi. Urang bakal ningali implikasi ieu pas. Janten Broker 1 ayeuna janten anggota kluster deui, sareng kluster nyobian sasuai sareng kawijakan sahingga nyiptakeun kaca spion dina Broker 1.

Dina hal ieu, leungitna calo 1 geus réngsé, kitu ogé data, jadi antrian unmirrored B sagemblengna leungit.

Sangu. 6. calo 1 mulih deui ka layanan

calo 3 deui online, jadi antrian A jeung B meunang deui kaca spion dijieun dina eta pikeun nyugemakeun kawijakan HA maranéhna. Tapi ayeuna sadaya antrian utama aya dina hiji titik! Ieu henteu idéal, distribusi anu rata antara titik langkung saé. Hanjakalna, teu aya seueur pilihan di dieu pikeun ngimbangan deui master. Urang bakal uih deui kana masalah ieu engké sabab urang kedah ningali sinkronisasi antrian heula.

Sangu. 7. calo 3 mulih deui ka layanan. Sadaya antrian utama dina hiji titik!

Janten ayeuna anjeun kedah gaduh ide kumaha kaca spion nyayogikeun redundansi sareng kasabaran kasalahan. Ieu ensures kasadiaan dina acara gagal titik tunggal jeung ngajaga ngalawan leungitna data. Tapi urang henteu acan réngsé, sabab kanyataanana éta langkung pajeulit.

Sinkron

Nalika nyieun eunteung anyar, sadaya pesen anyar bakal salawasna replicated ka eunteung ieu sareng nu sanesna. Sedengkeun pikeun data anu aya dina antrian master, urang tiasa ngayakeun réplikasi kana eunteung anyar, anu janten salinan lengkep master. Urang ogé bisa milih teu ngayakeun réplikasi pesen aya sarta ngantep antrian utama jeung eunteung anyar konvergen dina jangka waktu, kalawan pesen anyar anjog di buntut na pesen aya ninggalkeun sirah tina antrian utama.

Sinkronisasi ieu dipigawé sacara otomatis atawa sacara manual tur dikokolakeun maké kawijakan antrian. Hayu urang nempo hiji conto.

Simkuring gaduh dua antrian mirrored. Antrian A disingkronkeun sacara otomatis, sareng Antrian B disingkronkeun sacara manual. Duanana antrian ngandung sapuluh pesen.

Sangu. 8. Dua antrian jeung modus sinkronisasi béda

Ayeuna urang kaleungitan Broker 3.

Sangu. 9. calo 3 murag

calo 3 mulih deui ka layanan. Kluster nyiptakeun eunteung pikeun tiap antrian dina titik anyar sareng otomatis nyingkronkeun Antrian A anyar sareng master. Tapi, eunteung tina Antrian B anyar tetep kosong. Ku cara kieu urang gaduh redundansi pinuh dina Antrian A sareng ngan hiji eunteung pikeun pesen Antrian B anu tos aya.

Sangu. 10. Eunteung anyar antrian A narima sagala pesen aya, tapi eunteung anyar antrian B henteu.

Sapuluh pesen deui sumping dina duanana antrian. calo 2 lajeng ngadat jeung antrian A gulung deui ka eunteung pangkolotna, nu aya dina calo 1. Aya henteu leungitna data lamun gagal. Dina Antrian B, aya dua puluh pesen dina master sarta ngan sapuluh dina eunteung sabab antrian ieu pernah replicated sapuluh pesen aslina.

Sangu. 11. Antrian A gulungan deui calo 1 tanpa kaleungitan pesen

Sapuluh pesen deui sumping dina dua antrian. Ayeuna calo 1 ngadat. Antrian A gampang pindah ka eunteung tanpa kaleungitan pesen. Nanging, Antrian B ngagaduhan masalah. Dina titik ieu urang tiasa ngaoptimalkeun boh kasadiaan atanapi konsistensi.

Lamun urang hayang ngaoptimalkeun diakses, teras kawijakan ha-ngamajukeun-on-gagal kudu dipasang di salawasna. Ieu mangrupikeun nilai standar, janten anjeun ngan saukur teu tiasa netepkeun kawijakan éta. Dina hal ieu, kami dasarna ngamungkinkeun gagal dina kaca spion anu teu disinkronkeun. Ieu bakal ngabalukarkeun pesen leungit, tapi antrian bakal tetep bisa dibaca tur bisa ditulis.

Sangu. 12. Antrian A digulung deui calo 3 tanpa kaleungitan pesen. Antrian B gulung deui ka calo 3 kalayan sapuluh pesen leungit

Urang ogé bisa masang ha-promote-on-failure kana harti when-synced. Dina hal ieu, tinimbang gulung deui ka eunteung, antrian bakal ngantosan dugi calo 1 kalawan data na balik deui ka mode online. Saatos éta mulih, antrian utama deui dina calo 1 tanpa kaleungitan data. Kasadiaan dikorbankeun pikeun kaamanan data. Tapi ieu téh mode picilakaeun nu malah bisa ngakibatkeun leungitna data lengkep, nu urang bakal kasampak di lila.

Sangu. 13. Antrian B tetep henteu sayogi saatos kaleungitan calo 1

Anjeun tiasa naros, "Naha langkung saé henteu nganggo sinkronisasi otomatis?" Jawabanna nyaéta singkronisasi nyaéta operasi blocking. Salami sinkronisasi, antrian utama henteu tiasa ngalakukeun operasi maca atanapi nyerat!

Hayu urang nempo hiji conto. Ayeuna urang gaduh antrian anu panjang pisan. Kumaha maranéhna bisa tumuwuh nepi ka ukuran saperti? Ku sababaraha alesan:

• Antrian teu aktip dipake
• Ieu antrian-speed tinggi, sarta ayeuna pamakéna slow
• Ieu antrian-speed tinggi, geus aya glitch jeung konsumén nu catching up

Sangu. 14. Dua antrian badag kalayan modus sinkronisasi béda

Ayeuna calo 3 ragrag.

Sangu. 15. calo 3 ragrag, ninggalkeun hiji master na eunteung dina unggal antrian

calo 3 datang deui online tur kaca spion anyar dijieun. Antrian Utama A mimiti ngayakeun réplikasi pesen anu tos aya kana eunteung anyar, sareng salami ieu Antrian henteu sayogi. Butuh dua jam pikeun ngayakeun réplikasi data, hasilna dua jam downtime pikeun Antrian ieu!

Sanajan kitu, Antrian B tetep sadia sapanjang sakabéh periode. Manehna berkurban sababaraha redundancy pikeun diakses.

Sangu. 16. Antrian tetep teu sadia salila sinkronisasi

Saatos dua jam, Antrian A ogé sayogi sareng tiasa ngamimitian nampi maca sareng nyerat deui.

Ngamutahirkeun

Paripolah meungpeuk ieu salami sinkronisasi ngajantenkeun sesah pikeun ngapdet klaster kalayan antrian anu ageung pisan. Dina sababaraha waktos, master node kedah dibalikan deui, anu hartosna gentos kana eunteung atanapi nganonaktipkeun antrian nalika server ditingkatkeun. Lamun urang milih transisi, urang bakal leungit pesen lamun kaca spion teu nyingkronkeun. Sacara standar, salila outage calo, failover kana eunteung unsynchronized teu dipigawé. Ieu ngandung harti yén pas calo mulih, urang teu leungit pesen wae, hijina karuksakan éta antrian basajan. Aturan paripolah nalika calo dipegatkeun diatur ku kawijakan ha-promote-on-shutdown. Anjeun tiasa nyetél salah sahiji tina dua nilai:

• always= transisi ka kaca spion unsynchronized diaktipkeun
• when-synced= transisi ka eunteung nyingkronkeun wungkul, disebutkeun antrian jadi unreadable na unwriteable. Antrian balik deui ka layanan pas calo balik

Hiji cara atanapi anu sanés, kalayan antrian ageung anjeun kedah milih antara leungitna data sareng henteu sayogi.

Nalika Kasadiaan Ningkatkeun Kaamanan Data

Aya hiji deui komplikasi anu kedah dipertimbangkeun sateuacan nyandak kaputusan. Nalika sinkronisasi otomatis langkung saé pikeun redundansi, kumaha pangaruhna kana kaamanan data? Tangtosna, kalayan redundansi anu langkung saé, RabbitMQ kirang kamungkinan kaleungitan pesen anu tos aya, tapi kumaha upami pesen énggal ti penerbit?

Di dieu Anjeun kudu mertimbangkeun di handap:

• Naha penerbit ngan saukur ngabalikeun kasalahan sareng ngagaduhan jasa hulu atanapi pangguna cobian deui engké?
• Naha penerbit tiasa nyimpen pesen sacara lokal atanapi dina pangkalan data pikeun cobian deui engké?

Upami penerbit ngan ukur tiasa miceun pesen, maka kanyataanna, ningkatkeun aksésibilitas ogé ningkatkeun kaamanan data.

Ku kituna, kasaimbangan kudu ditéang, sarta solusi gumantung kana situasi husus.

Masalah sareng ha-promote-on-failure=when-synced

gagasan ha-ngamajukeun-on-gagal= nalika-nyingkronkeun nyaeta urang nyegah pindah ka eunteung unsynchronized sahingga nyegah leungitna data. Antrian tetep teu bisa dibaca atawa ditulis. Sabalikna, urang nyobian cageur calo nabrak sareng datana gembleng supados tiasa neruskeun fungsina salaku master tanpa kaleungitan data.

Tapi (jeung ieu téh badag tapi) lamun calo nu geus leungit data-Na, mangka urang boga masalah badag: antrian leungit! Sadaya data leungit! Sanaos anjeun gaduh kaca spion anu seueurna ngiringan antrian utama, kaca spion ogé dipiceun.

Pikeun nambihan deui titik kalayan nami anu sami, kami nyarioskeun kluster pikeun hilap titik anu leungit (kalayan paréntah rabbitmqctl forget_cluster_node) tur mimitian calo anyar kalawan hostname sarua. Bari klaster inget titik leungit, eta inget antrian heubeul jeung kaca spion unsynchronized. Nalika klaster dititah poho hiji titik yatim piatu, antrian éta ogé poho. Ayeuna urang kedah deklarasi deui. Urang leungit kabeh data, sanajan urang tadi kaca spion ku set parsial data. Eta bakal leuwih hadé pikeun pindah ka eunteung non-nyingkronkeun!

Ku alatan éta, singkronisasi manual (jeung gagal pikeun nyingkronkeun) dina kombinasi jeung ha-promote-on-failure=when-synced, dina pamanggih kuring, rada picilakaeun. Dokumén nyatakeun yén pilihan ieu aya pikeun kaamanan data, tapi éta péso dua sisi.

Master rebalancing

Sakumaha anu dijanjikeun, urang uih deui ka masalah akumulasi sadaya master dina hiji atanapi sababaraha titik. Ieu malah bisa lumangsung salaku hasil tina update klaster rolling. Dina klaster tilu titik, sadaya antrian master bakal ngumpulkeun dina hiji atanapi dua titik.

Rebalancing master tiasa janten masalah kusabab dua alesan:

• Henteu aya alat anu saé pikeun ngalaksanakeun rebalancing
• Sinkronisasi antrian

Aya pihak katilu pikeun rebalancing plugin, nu teu resmi dirojong. Ngeunaan plugins pihak katilu dina manual RabbitMQ ceuk: "Plugin nyadiakeun sababaraha konfigurasi tambahan sarta parabot ngalaporkeun, tapi teu dirojong atawa diverifikasi ku tim RabbitMQ. Paké dina resiko sorangan ".

Aya trik sejen pikeun mindahkeun antrian utama ngaliwatan kawijakan HA. Manual nyebutkeun naskah kanggo ieu. Gawéna sapertos kieu:

• Ngaleungitkeun sadaya kaca spion nganggo kawijakan samentawis anu ngagaduhan prioritas anu langkung luhur tibatan kawijakan HA anu aya.
• Ngarobah kawijakan samentara HA ngagunakeun mode titik, nangtukeun titik nu antrian master kudu ditransfer.
• Nyingkronkeun antrian pikeun migrasi push.
• Saatos migrasi réngsé, mupus kawijakan samentawis. Kawijakan HA awal mawa pangaruh jeung jumlah diperlukeun kaca spion dijieun.

The downside nyaeta pendekatan ieu bisa jadi teu jalan mun anjeun boga antrian badag atawa sarat redundancy ketat.

Ayeuna hayu urang tingali kumaha klaster RabbitMQ tiasa dianggo sareng partisi jaringan.

Leungitna konektipitas

Titik tina sistem anu disebarkeun disambungkeun ku tautan jaringan, sareng tautan jaringan tiasa sareng bakal dipegatkeun. Frékuénsi pareum gumantung kana infrastruktur lokal atanapi reliabilitas awan anu dipilih. Dina naon waé, sistem anu disebarkeun kedah tiasa ngatasi aranjeunna. Sakali deui urang boga pilihan antara kasadiaan jeung konsistensi, jeung deui warta alus nyaeta RabbitMQ nyadiakeun duanana pilihan (ngan teu sakaligus).

Kalayan RabbitMQ kami gaduh dua pilihan utama:

• Ngawenangkeun division logis (split-otak). Ieu ensures kasadiaan, tapi bisa ngabalukarkeun leungitna data.
• Nonaktipkeun separation logis. Bisa ngakibatkeun leungitna kasadiaan jangka pondok gumantung kana kumaha klien nyambung ka klaster. Ogé bisa ngakibatkeun unavailability lengkep dina klaster dua titik.

Tapi naon separation logis? Ieu nalika klaster dibagi jadi dua alatan leungitna sambungan jaringan. Dina saban gigir, kaca spion diangkat jadi master, ku kituna aya sababaraha master per turn.

Sangu. 17. antrian utama jeung dua kaca spion, unggal dina titik misah. Lajeng kagagalan jaringan lumangsung sarta hiji eunteung jadi detached. Titik anu dipisahkeun ningali yén dua anu sanésna murag sareng ngamajukeun kaca spionna ka master. Urang ayeuna boga dua antrian utama, duanana bisa ditulis tur bisa dibaca.

Lamun penerbit ngirim data ka duanana Masters, urang mungkas nepi ka dua salinan divergent tina antrian.

Modeu béda RabbitMQ nyayogikeun kasadiaan atanapi konsistensi.

Teu malire mode (standar)

Modeu ieu mastikeun aksés. Saatos leungitna konektipitas, separation logis lumangsung. Saatos konektipitas dibalikeun, pangurus kedah mutuskeun partisi mana anu bakal diutamakeun. Sisi anu kaleungitan bakal dibalikan deui sareng sadaya data akumulasi di sisi éta bakal leungit.

Sangu. 18. Tilu penerbit pakait sareng tilu calo. Sacara internal, klaster ngarutekeun sadaya pamundut ka antrian utama dina Broker 2.

Ayeuna urang kaleungitan calo 3. Anjeunna ningali yén calo anu sanés murag sareng promosikeun eunteung ka master. Ieu kumaha separation logis lumangsung.

Sangu. 19. Divisi logis (beulah-otak). Rékaman asup kana dua antrian utama, sareng dua salinanna diverge.

Konéktipitas dibalikeun, tapi separation logis tetep. Administrator kedah sacara manual milih sisi anu kaleungitan. Dina kasus di handap ieu, administrator reboots calo 3. Sadaya pesen anu anjeunna henteu junun ngirimkeun leungit.

Sangu. 20. Administrator nganonaktipkeun calo 3.

Sangu. 21. Administrator dimimitian calo 3 sarta ngagabung kluster, leungit kabeh pesen nu ditinggalkeun aya.

Salila leungitna konektipitas sarta sanggeus restorasi na, klaster jeung antrian ieu sadia pikeun maca jeung nulis.

modeu Autoheal

Gawéna sarupa mode teu malire, iwal klaster sorangan otomatis milih sisi leungit sanggeus bengkahna tur malikkeun konektipitas. Sisi kaleungitan mulih deui ka kluster kosong, sareng antrian kaleungitan sadaya pesen anu dikirim ngan ka sisi éta.

Reureuh Modeu Minoritas

Upami urang henteu hoyong ngabagi partisi logis, maka hiji-hijina pilihan urang nyaéta miceun bacaan sareng nyerat dina sisi anu langkung alit saatos partisi klaster. Nalika calo ningali yén éta aya di sisi anu langkung alit, éta ngagantungkeun padamelan, nyaéta, nutup sadaya sambungan anu aya sareng nolak anu énggal. Sakali per detik eta mariksa restorasi konektipitas. Sakali konektipitas dibalikeun, éta neruskeun operasi sareng ngagabung ka kluster.

Sangu. 22. Tilu penerbit pakait sareng tilu calo. Sacara internal, klaster ngarutekeun sadaya pamundut ka antrian utama dina Broker 2.

calo 1 jeung 2 lajeng dibeulah ti calo 3. Gantina promosi eunteung maranéhna pikeun master, calo 3 suspends sarta jadi sadia.

Sangu. 23. calo 3 reureuhan , disconnects sadayana klien, sarta rejects requests sambungan.

Sakali konektipitas dibalikeun, éta balik deui ka kluster.

Hayu urang tingali conto anu sanés dimana antrian utama aya dina Broker 3.

Sangu. 24. Antrian utama dina calo 3.

Lajeng leungitna sarua konektipitas lumangsung. calo 3 reureuhan sabab aya dina sisi leutik. Di sisi anu sanés, titik-titik ningali yén Broker 3 parantos murag, janten eunteung anu langkung lami ti Broker 1 sareng 2 diwanohkeun ka master.

Sangu. 25. Transisi ka calo 2 lamun calo 3 teu sadia.

Nalika konektipitas dibalikeun, calo 3 bakal ngiringan kluster.

Sangu. 26. klaster geus balik ka operasi normal.

Anu penting pikeun ngartos di dieu nyaéta yén urang kéngingkeun konsistensi, tapi urang ogé tiasa nampi kasadiaan, upami Urang bakal hasil nransper klien ka lolobana bagian. Kanggo sabagéan ageung kaayaan, kuring pribadi bakal milih modeu Pause Minoritas, tapi éta gumantung kana kasus individu.

Pikeun mastikeun kasadiaan, hal anu penting pikeun mastikeun yén klien hasil nyambung ka host teh. Hayu urang tingali pilihan urang.

Mastikeun Konéktipitas Palanggan

Simkuring gaduh sababaraha pilihan pikeun kumaha carana ngarahkeun klien ka bagian utama kluster atawa titik gawe (sanggeus hiji titik gagal) sanggeus leungitna konektipitas. Mimiti, hayu urang émut yén antrian khusus di-host dina titik khusus, tapi rute sareng kawijakan ditiru dina sadaya titik. Klién tiasa nyambung ka titik mana waé, sareng routing internal bakal ngarahkeun aranjeunna ka tempat anu kedah dituju. Tapi nalika hiji titik ditunda, éta nolak sambungan, jadi klien kudu nyambung ka titik sejen. Lamun titik ragrag kaluar, aya saeutik anjeunna tiasa ngalakukeun pisan.

Pilihan kami:

• Kluster diaksés nganggo load balancer anu ngan saukur siklus ngaliwatan titik sareng klien coba deui nyambungkeun dugi ka suksés. Upami hiji titik turun atanapi ditunda, teras usaha pikeun nyambung ka titik éta bakal gagal, tapi usaha saterasna bakal ka server sanés (dina mode round-robin). Ieu cocog pikeun leungitna konektipitas jangka pondok atawa server downed nu bakal gancang dibawa deui ka luhur.
• Aksés kluster ngaliwatan pangimbang beban sareng cabut titik anu ditunda / gagal tina daptar pas dideteksi. Upami urang ngalakukeun ieu gancang, sareng upami klien tiasa nyobian deui sambungan, maka urang bakal ngahontal kasadiaan konstan.
• Pasihan unggal klien daptar sadaya titik, sareng klien sacara acak milih salah sahijina nalika nyambungkeun. Upami éta nampi kasalahan nalika nyobian nyambung, éta ngalih ka titik salajengna dina daptar dugi ka nyambung.
• Hapus patalimarga tina titik anu gagal / ditunda nganggo DNS. Hal ieu dilakukeun ngagunakeun TTL leutik.

papanggihan

RabbitMQ clustering boga kaunggulan jeung kalemahan. Karugian anu paling parah nyaéta:

• nalika ngagabung kana klaster, titik miceun datana;
• blocking sinkronisasi ngabalukarkeun antrian jadi sadia.

Sadaya kaputusan hese asalna tina dua fitur arsitéktur ieu. Upami RabbitMQ tiasa nyimpen data nalika kluster dihijikeun deui, teras sinkronisasi bakal langkung gancang. Lamun éta sanggup non-blocking sinkronisasi, eta bakal hadé ngarojong antrian badag. Ngalereskeun dua masalah ieu bakal ningkatkeun kinerja RabbitMQ salaku téknologi olahtalatah anu toléran-lepat sareng sayogi pisan. Kuring bakal hesitant nyarankeun RabbitMQ sareng clustering dina kaayaan di handap ieu:

• jaringan teu bisa dipercaya.
• gudang teu dipercaya.
• Antrian panjang pisan.

Lamun datang ka setelan kasadiaan tinggi, mertimbangkeun di handap:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (atawa autoheal)
• pesen pengkuh
• mastikeun klien nyambung ka titik aktif nalika sababaraha titik gagal

Pikeun konsistensi (kaamanan data), pertimbangkeun setélan ieu:

• Penerbit Confirms na Manual Acknowledgments di sisi konsumen
• ha-promote-on-failure=when-synced, upami penerbit tiasa nyobian deui engké sareng upami anjeun gaduh panyimpenan anu dipercaya pisan! Upami teu kitu nempatkeun =always.
• ha-sync-mode=automatic (tapi pikeun antrian ageung anu teu aktip, mode manual tiasa diperyogikeun; ogé pertimbangkeun naha henteu kasadiaan bakal nyababkeun pesen leungit)
• Reureuh mode Minoritas
• pesen pengkuh

Kami henteu acan nutupan sadaya masalah ngeunaan kasabaran kasalahan sareng kasadiaan anu luhur; contona, kumaha carana aman ngalakukeun prosedur administrasi (sapertos rolling apdet). Urang ogé kedah ngobrol ngeunaan federasi sareng plugin Shovel.

Mun kuring geus sono nanaon sejenna, mangga hayu atuh nyaho.

Tempo ogé abdi pasang, Dimana kuring ngalakukeun bencana dina klaster RabbitMQ nganggo Docker sareng Blokade pikeun nguji sababaraha skenario leungitna pesen anu dijelaskeun dina tulisan ieu.

Artikel saméméhna dina séri:
No. 1 - habr.com/ru/company/itsumma/blog/416629
No. 2 - habr.com/ru/company/itsumma/blog/418389
No. 3 - habr.com/ru/company/itsumma/blog/437446

sumber: www.habr.com