Toleransi kesalahan lan kasedhiyan dhuwur minangka topik gedhe, mula kita bakal menehi artikel sing kapisah kanggo RabbitMQ lan Kafka. Artikel iki babagan RabbitMQ, lan sabanjure babagan Kafka, dibandhingake karo RabbitMQ. Iki minangka artikel sing dawa, mula nggawe sampeyan kepenak.
Ayo goleki strategi toleransi kesalahan, konsistensi, lan kasedhiyan dhuwur (HA) lan tradeoff sing ditindakake saben strategi. RabbitMQ bisa mlaku ing kluster kelenjar - banjur diklasifikasikake minangka sistem sing disebarake. Nalika nerangake sistem mbagekke, kita asring pirembagan bab konsistensi lan kasedhiyan.
Konsep iki njlèntrèhaké carane sistem tumindak nalika gagal. Gagal sambungan jaringan, gagal server, hard drive gagal, server ora kasedhiya sauntara amarga pangumpulan sampah, paket ilang, utawa kalem sambungan jaringan. Kabeh iki bisa nyebabake mundhut data utawa konflik. Pranyata metu sing iku sakbenere mokal kanggo sijine munggah sistem sing loro rampung konsisten (ora mundhut data, ora divergence data) lan kasedhiya (bakal nampa maca lan nulis) kanggo kabeh skenario Gagal.
Kita bakal weruh manawa konsistensi lan kasedhiyan ana ing ujung spektrum, lan sampeyan kudu milih cara kanggo ngoptimalake. Kabar apik yaiku karo RabbitMQ pilihan iki bisa ditindakake. Sampeyan duwe pengungkit "nerdy" iki kanggo nggeser keseimbangan menyang konsistensi sing luwih gedhe utawa aksesibilitas sing luwih gedhe.
Kita bakal menehi perhatian khusus kanggo konfigurasi sing nyebabake mundhut data amarga rekaman sing dikonfirmasi. Ana rantai tanggung jawab antarane penerbit, makelar lan konsumen. Sawise pesen dikirim menyang makelar, tugase ora ilang pesen kasebut. Nalika makelar ngakoni panrimo pesen penerbit, kita ora ngarep-arep bakal ilang. Nanging kita bakal weruh manawa iki bisa kedadeyan gumantung saka konfigurasi broker lan penerbit sampeyan.
Primitif Ketahanan Node Tunggal
Antrean / Routing Tangguh
Ana rong jinis antrian ing RabbitMQ: awet lan ora awet. Kabeh antrian disimpen ing database Mnesia. Antrian awet diiklanake maneh nalika wiwitan simpul lan kanthi mangkono bisa urip maneh, kacilakan sistem, utawa kacilakan server (anggere data kasebut tetep). Iki tegese yen sampeyan nyatakake routing (ijol-ijolan) lan antrian dadi tahan, infrastruktur antrian / rute bakal bali online.
Antrian lan rute sing molah malih dibusak nalika simpul diwiwiti maneh.
Pesen sing terus-terusan
Mung amarga antrian awet ora ateges kabeh pesen bakal urip maneh nalika node diwiwiti maneh. Mung pesen sing disetel dening publisher minangka lestari (terus-terusan). Pesen sing terus-terusan nggawe beban tambahan ing broker, nanging yen mundhut pesen ora bisa ditampa, mula ora ana pilihan liyane.
Gabah. 1. Matriks kelestarian
Clustering karo mirroring antrian
Kanggo nylametake mundhut broker, kita butuh redundansi. Kita bisa gabungke sawetara kelenjar RabbitMQ menyang kluster, lan banjur nambah redundansi tambahan dening replikasi antrian antarane macem-macem kelenjar. Kanthi cara iki, yen siji simpul gagal, kita ora bakal kelangan data lan tetep kasedhiya.
Antrian mirroring:
- siji antrian utama (master), kang nampa kabeh nulis lan maca printah
- siji utawa luwih mirrors sing nampa kabeh pesen lan metadata saka antrian utama. Cermin iki ora ana kanggo skala, nanging mung kanggo redundansi.
Gabah. 2. Antri mirroring
Mirroring disetel dening kabijakan sing cocog. Ing kono sampeyan bisa milih koefisien replikasi lan malah simpul sing kudu ana antrian. Tuladha:
ha-mode: allha-mode: exactly, ha-params: 2(siji master lan siji pangilon)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
Konfirmasi penerbit
Kanggo entuk rekaman sing konsisten, Penerbit Konfirmasi dibutuhake. Tanpa wong-wong mau, ana risiko pesen ilang. Konfirmasi dikirim menyang penerbit sawise pesen kasebut ditulis ing disk. RabbitMQ nulis pesen menyang disk ora nalika ditampa, nanging kanthi periodik, ing wilayah sawetara atus milidetik. Nalika antrian dicerminake, pangakuan dikirim mung sawise kabeh pangilon uga nulis salinan pesen kasebut menyang disk. Iki tegese nggunakake konfirmasi nambah latensi, nanging yen keamanan data penting, mula perlu.
Antrian Failover
Nalika makelar mandheg utawa nabrak, kabeh pimpinan antrian (master) ing simpul kasebut bakal nabrak. Kluster banjur milih pangilon paling tuwa saka saben master lan promosi minangka master anyar.
Gabah. 3. Multiple mirrored queues lan kawicaksanan sing
Broker 3 mudhun. Elinga yen pangilon Queue C ing Broker 2 dipromosikan dadi master. Uga elinga yen pangilon anyar wis digawe kanggo Queue C ing Broker 1. RabbitMQ tansah nyoba njaga faktor replikasi sing ditemtokake ing kawicaksanan sampeyan.
Gabah. 4. Broker 3 gagal, nyebabake antrian C gagal
Broker sabanjure 1 tiba! Kita mung duwe broker siji. Pangilon Queue B dipromosikan dadi master.
Gambar. Xnumx
Kita wis bali Broker 1. Preduli saka carane uga data slamet mundhut lan Recovery saka makelar, kabeh pesen antrian mirrored dibuwak nalika miwiti maneh. Iki penting kanggo dicathet amarga bakal ana akibat. Kita bakal nliti implikasi kasebut sakcepete. Dadi Broker 1 saiki dadi anggota kluster maneh, lan kluster nyoba tundhuk karo kabijakan kasebut lan mulane nggawe pangilon ing Broker 1.
Ing kasus iki, mundhut Broker 1 wis rampung, kaya data, saéngga antrian B sing ora dimirrokaké wis ilang.
Gabah. 6. Broker 1 bali menyang layanan
Broker 3 bali online, supaya antrian A lan B bali mirrors digawe ing kanggo gawe marem kawicaksanan HA. Nanging saiki kabeh antrian utama ana ing siji simpul! Iki ora becik, distribusi sing rata ing antarane simpul luwih apik. Sayange, ora ana akeh pilihan ing kene kanggo ngimbangi master. Kita bakal bali menyang masalah iki mengko amarga kita kudu ndeleng sinkronisasi antrian dhisik.
Gabah. 7. Broker 3 bali menyang layanan. Kabeh antrian utama ing siji simpul!
Dadi saiki sampeyan kudu duwe ide babagan cara pangilon nyedhiyakake redundansi lan toleransi kesalahan. Iki njamin kasedhiyan yen ana gagal simpul siji lan nglindhungi saka mundhut data. Nanging kita durung rampung, amarga kasunyatane luwih rumit.
Sinkronisasi
Nalika nggawe pangilon anyar, kabeh pesen anyar bakal tansah ditiru menyang pangilon iki lan liyane. Kanggo data sing ana ing antrian master, kita bisa niru menyang pangilon anyar, sing dadi salinan lengkap master. Kita uga bisa milih ora kanggo niru pesen sing wis ana lan supaya antrian utama lan pangilon anyar converge ing wektu, karo pesen anyar teka ing buntut lan pesen ana ninggalake sirah antrian utama.
Sinkronisasi iki ditindakake kanthi otomatis utawa manual lan dikelola kanthi nggunakake kabijakan antrian. Ayo katon ing conto.
Kita duwe loro antrian mirrored. Antrian A disinkronake kanthi otomatis, lan Antrian B disinkronake kanthi manual. Loro-lorone antrian ngemot sepuluh pesen.
Gabah. 8. Loro antrian karo mode sinkronisasi beda
Saiki kita kelangan Broker 3.
Gabah. 9. Broker 3 tiba
Broker 3 bali menyang layanan. Kluster nggawe pangilon kanggo saben antrian ing simpul anyar lan kanthi otomatis nyinkronake Antrian A anyar karo master. Nanging, pangilon saka Antrian B anyar tetep kosong. Kanthi cara iki, kita duwe redundansi lengkap ing Antrian A lan mung siji pangilon kanggo pesen Antrian B sing wis ana.
Gabah. 10. Pangilon anyar Antrian A nampa kabeh pesen sing wis ana, nanging pangilon anyar Antrian B ora.
Sepuluh pesen liyane teka ing loro antrian. Broker 2 banjur tubrukan lan Queue A muter maneh menyang pangilon paling tuwa, sing ana ing Broker 1. Ora ana mundhut data nalika gagal. Ing Antrian B, ana rong puluh pesen ing master lan mung sepuluh ing pangilon amarga antrian iki ora nate ngreplikasi sepuluh pesen asli.
Gabah. 11. Antrian A muter bali menyang Broker 1 tanpa ilang pesen
Sepuluh pesen liyane teka ing loro antrian. Saiki Broker 1 nabrak. Antrian A gampang ngalih menyang pangilon tanpa kelangan pesen. Nanging, Antrian B ngalami masalah. Ing titik iki kita bisa ngoptimalake kasedhiyan utawa konsistensi.
Yen kita pengin ngoptimalake aksesibilitas, banjur kabijakan ha-promote-on-gagal kudu diinstal ing tansah. Iki minangka nilai standar, dadi sampeyan ora bisa nemtokake kebijakan kasebut. Ing kasus iki, kita ateges ngidini gagal ing pangilon sing ora disinkronake. Iki bakal nyebabake pesen ilang, nanging antrian bakal tetep bisa diwaca lan bisa ditulis.
Gabah. 12. Antrian A mbalek maneh kanggo Broker 3 tanpa ilang pesen. Antrian B bali menyang Broker 3 kanthi sepuluh pesen ilang
Kita uga bisa nginstal ha-promote-on-failure menyang makna when-synced. Ing kasus iki, tinimbang muter maneh menyang pangilon, antrian bakal ngenteni nganti Broker 1 kanthi data bali menyang mode online. Sawise bali, antrian utama bali ing Broker 1 tanpa mundhut data. Kasedhiyan dikorbanake kanggo keamanan data. Nanging iki mode beboyo sing malah bisa mimpin kanggo mundhut data lengkap, kang kita bakal katon sakcepete.
Gabah. 13. Antrian B tetep ora kasedhiya sawise kelangan Broker 1
Sampeyan bisa uga takon, "Apa luwih becik ora nggunakake sinkronisasi otomatis?" Jawaban kasebut yaiku sinkronisasi minangka operasi pamblokiran. Sajrone sinkronisasi, antrian utama ora bisa nindakake operasi maca utawa nulis!
Ayo katon ing conto. Saiki kita duwe antrian dawa banget. Kepiye carane bisa tuwuh nganti ukuran kasebut? Kanggo sawetara alasan:
- Antrian ora aktif digunakake
- Iki minangka antrian kanthi kacepetan dhuwur, lan saiki konsumen alon
- Iku antrian kacepetan dhuwur, wis ana glitch lan konsumen sing nyekel munggah
Gabah. 14. Loro antrian gedhe kanthi mode sinkronisasi sing beda
Saiki Broker 3 tiba.
Gabah. 15. Broker 3 tiba, ninggalake siji master lan pangilon ing saben antrian
Broker 3 bali online lan pangilon anyar digawe. Antrian Utama A wiwit niru pesen sing wis ana menyang pangilon anyar, lan sajrone wektu iki, Antrian ora kasedhiya. Butuh rong jam kanggo niru data, nyebabake rong jam downtime kanggo Antrian iki!
Nanging, Antrian B tetep kasedhiya ing kabeh periode. Dheweke kurban sawetara redundansi kanggo aksesibilitas.
Gabah. 16. Antrian tetep ora kasedhiya sajrone sinkronisasi
Sawise rong jam, Antrian A uga kasedhiya lan bisa miwiti nampa maca lan nulis maneh.
Update
Prilaku pamblokiran iki sajrone sinkronisasi ndadekake angel nganyari klompok kanthi antrian sing gedhe banget. Ing sawetara titik, simpul master kudu diwiwiti maneh, tegese ngalih menyang pangilon utawa mateni antrian nalika server lagi nganyari. Yen kita milih kanggo transisi, kita bakal kelangan pesen yen mirrors ora diselarasake. Kanthi gawan, sajrone outage broker, failover menyang pangilon sing ora disinkronake ora ditindakake. Iki tegese sanalika broker bali, kita ora kelangan pesen, karusakan mung antrian prasaja. Aturan prilaku nalika maklar pedhot diatur dening kawicaksanan ha-promote-on-shutdown. Sampeyan bisa nyetel salah siji saka rong nilai:
always= transisi menyang mirrors unsynchronized diaktifakewhen-synced= transisi menyang pangilon sing disinkronake mung, yen antrian dadi ora bisa diwaca lan ora bisa ditulis. Antrian bali menyang layanan sanalika broker bali
Siji cara utawa liyane, kanthi antrian gedhe sampeyan kudu milih antarane mundhut data lan ora kasedhiya.
Nalika Kasedhiyan Ngapikake Keamanan Data
Ana siji komplikasi liyane sing kudu ditimbang sadurunge nggawe keputusan. Nalika sinkronisasi otomatis luwih apik kanggo redundansi, kepiye pengaruh keamanan data? Mesthine, kanthi redundansi sing luwih apik, RabbitMQ kurang cenderung bakal kelangan pesen sing wis ana, nanging kepiye pesen anyar saka penerbit?
Kene sampeyan kudu nimbang ing ngisor iki:
- Apa penerbit mung bisa ngasilake kesalahan lan njaluk layanan hulu utawa pangguna nyoba maneh mengko?
- Apa penerbit bisa nyimpen pesen kasebut sacara lokal utawa ing basis data kanggo nyoba maneh mengko?
Yen penerbit mung bisa mbatalake pesen kasebut, nyatane, ningkatake aksesibilitas uga nambah keamanan data.
Mangkono, imbangan kudu digoleki, lan solusi kasebut gumantung ing kahanan tartamtu.
Masalah karo ha-promote-on-failure=when-synced
Idea ha-promote-on-gagal= nalika-nyelarasake yaiku supaya ora ngalih menyang pangilon sing ora disinkronake lan supaya data ora ilang. Antrian tetep ora bisa diwaca utawa ditulis. Nanging, kita nyoba mbalekake makelar sing nabrak kanthi data utuh supaya bisa nerusake fungsi minangka master tanpa mundhut data.
Nanging (lan iki gedhe nanging) yen broker wis ilang data, banjur kita duwe masalah gedhe: antrian ilang! Kabeh data ilang! Sanajan sampeyan duwe pangilon sing biasane nyedhak karo antrian utama, pangilon kasebut uga dibuwang.
Kanggo nambah maneh simpul kanthi jeneng sing padha, kita ngandhani kluster supaya lali simpul sing ilang (kanthi perintah rabbitmqctl lali_cluster_node) lan miwiti makelar anyar kanthi jeneng host sing padha. Nalika kluster elinga simpul ilang, elinga antrian lawas lan mirrors unsynchronized. Nalika kluster didhawuhi lali simpul yatim piatu, antrian kasebut uga dilalekake. Saiki kita kudu ngumumake maneh. Kita ilang kabeh data, sanajan kita duwe pangilon karo sebagean data. Iku bakal luwih apik kanggo ngalih menyang pangilon non-sinkronisasi!
Mulane, sinkronisasi manual (lan gagal kanggo nyinkronake) ing kombinasi karo ha-promote-on-failure=when-synced, ing mratelakake panemume, cukup beboyo. Dokumen kasebut ujar manawa pilihan iki ana kanggo keamanan data, nanging piso kanthi pinggir pindho.
Master rebalancing
Kaya sing dijanjekake, kita bali menyang masalah akumulasi kabeh master ing siji utawa sawetara kelenjar. Iki bisa uga kedadeyan minangka asil nganyari cluster rolling. Ing kluster telung simpul, kabeh antrian master bakal nglumpukake siji utawa rong simpul.
Master rebalancing bisa dadi masalah amarga rong alasan:
- Ora ana alat sing apik kanggo nindakake rebalancing
- Sinkronisasi antrian
Ana pihak katelu kanggo rebalancing , sing ora didhukung resmi. Babagan plugin pihak katelu ing manual RabbitMQ : "Plugin nyedhiyakake sawetara alat konfigurasi lan laporan tambahan, nanging ora didhukung utawa diverifikasi dening tim RabbitMQ. Gunakake kanthi resiko dhewe."
Ana trick liyane kanggo mindhah antrian utama liwat kawicaksanan HA. Manual kasebut kanggo iki. Kerjane kaya iki:
- Mbusak kabeh mirrors nggunakake kabijakan sauntara sing wis prioritas luwih saka kawicaksanan HA ana.
- Ngganti kabijakan sementara HA kanggo nggunakake mode simpul, nemtokake simpul sing kudu ditransfer antrian master.
- Nyelarasake antrian kanggo migrasi push.
- Sawise migrasi rampung, mbusak kabijakan sementara. Kabijakan HA wiwitan ditrapake lan jumlah pangilon sing dibutuhake digawe.
Kelemahane yaiku pendekatan iki bisa uga ora bisa digunakake yen sampeyan duwe antrian gedhe utawa syarat redundansi sing ketat.
Saiki ayo ndeleng kepiye kluster RabbitMQ bisa digunakake karo partisi jaringan.
Kelangan panyambungan
Node saka sistem sing disebarake disambungake dening pranala jaringan, lan pranala jaringan bisa lan bakal dicopot. Frekuensi mati gumantung saka infrastruktur lokal utawa linuwih awan sing dipilih. Ing kasus apa wae, sistem sing disebarake kudu bisa ngatasi. Sepisan maneh kita duwe pilihan antarane kasedhiyan lan konsistensi, lan maneh kabar apik yaiku RabbitMQ nyedhiyakake loro pilihan (mung ora bebarengan).
Kanthi RabbitMQ, kita duwe rong pilihan utama:
- Ngidini divisi logis (otak pamisah). Iki njamin kasedhiyan, nanging bisa nyebabake mundhut data.
- Pateni pemisahan logis. Bisa nyebabake mundhut kasedhiyan jangka pendek gumantung carane klien nyambung menyang kluster. Bisa uga nyebabake ora kasedhiya ing kluster rong simpul.
Nanging apa pemisahan logis? Iki nalika kluster dibagi dadi loro amarga kelangan sambungan jaringan. Ing saben sisih, pangilon dipromosekake dadi master, saengga ana sawetara master saben giliran.
Gabah. 17. Antrian utama lan loro mirrors, saben ing simpul kapisah. Banjur ana kegagalan jaringan lan siji pangilon dadi suwek. Simpul sing dipisahake weruh yen loro liyane wis tiba lan mromosikake pangilon menyang master. Saiki kita duwe rong antrian utama, sing bisa ditulis lan bisa diwaca.
Yen penerbit ngirim data menyang master loro, kita bakal entuk rong salinan antrian sing beda.
Mode beda RabbitMQ nyedhiyakake kasedhiyan utawa konsistensi.
Abaikan mode (standar)
Mode iki njamin aksesibilitas. Sawise kelangan panyambungan, pemisahan logis dumadi. Sawise konektivitas dipulihake, administrator kudu mutusake partisi sing bakal diprioritasake. Sisih sing kalah bakal diwiwiti maneh lan kabeh data akumulasi ing sisih kasebut bakal ilang.
Gabah. 18. Telung penerbit digandhengake karo telung makelar. Secara internal, kluster ngarahake kabeh panjaluk menyang antrian utama ing Broker 2.
Saiki kita kalah Broker 3. Dheweke weruh yen makelar liyane wis tiba lan promosiake pangilon marang master. Iki minangka pemisahan logis.
Gabah. 19. Divisi logis (otak pamisah). Cathetan dadi rong antrian utama, lan rong salinan kasebut beda-beda.
Konektivitas dibalèkaké, nanging pamisahan logis tetep. Administrator kudu kanthi manual milih sisih sing kalah. Ing kasus ing ngisor iki, administrator reboots Broker 3. Kabeh pesen sing ora ngatur kanggo ngirim ilang.
Gabah. 20. Administrator mateni Broker 3.
Gabah. 21. Administrator miwiti Broker 3 lan gabung kluster, ilang kabeh pesen sing padha kiwa ana.
Sajrone kelangan panyambungan lan sawise pemugaran, kluster lan antrian iki kasedhiya kanggo maca lan nulis.
Mode otomatis
Kerjane padha karo mode Nglirwakake, kajaba kluster kasebut kanthi otomatis milih sisih sing ilang sawise pamisah lan mulihake konektivitas. Sisih kalah bali menyang kluster kosong, lan antrian ilang kabeh pesen sing dikirim mung kanggo sisih.
Ngaso Mode Minoritas
Yen kita ora pengin ngidini pemisahan logis, banjur pilihan mung kanggo mbuwang maca lan nulis ing sisih cilik sawise partisi cluster. Nalika maklar weruh yen ana ing sisih cilik, nundha karya, yaiku, nutup kabeh sambungan sing ana lan nolak sing anyar. Sawise saben detik mriksa pemugaran konektivitas. Sawise panyambungan dibalèkaké, iku nerusake operasi lan gabung kluster.
Gabah. 22. Telung penerbit digandhengake karo telung makelar. Secara internal, kluster ngarahake kabeh panjaluk menyang antrian utama ing Broker 2.
Broker 1 lan 2 banjur pisah saka Broker 3. Tinimbang mromosikake pangilon dadi master, Broker 3 nundha lan dadi ora kasedhiya.
Gabah. 23. Broker 3 ngaso, medhot kabeh klien, lan nolak panjalukan sambungan.
Sawise panyambungan dibalèkaké, bali menyang kluster.
Ayo goleki conto liyane ing ngendi antrian utama ana ing Broker 3.
Gabah. 24. Antrian utama ing Broker 3.
Banjur mundhut sambungan sing padha. Broker 3 ngaso amarga ana ing sisih cilik. Ing sisih liya, simpul weruh yen Broker 3 wis ambruk, mula pangilon lawas saka Broker 1 lan 2 dipromosikan dadi master.
Gabah. 25. Transisi menyang Broker 2 yen Broker 3 ora kasedhiya.
Nalika panyambungan dibalèkaké, Broker 3 bakal gabung kluster.
Gabah. 26. Kluster wis bali menyang operasi normal.
Sing penting dimangerteni ing kene yaiku kita entuk konsistensi, nanging kita uga bisa entuk kasedhiyan, yen Kita bakal sukses nransfer klien menyang paling bagean. Kanggo umume kahanan, aku bakal milih mode Pause Minoritas, nanging gumantung ing kasus individu.
Kanggo mesthekake kasedhiyan, iku penting kanggo mesthekake yen klien kasil nyambung menyang inang. Ayo katon ing pilihan kita.
Njamin Konektivitas Pelanggan
Kita duwe sawetara opsi kanggo ngarahake klien menyang bagean utama kluster utawa menyang kelenjar sing bisa digunakake (sawise siji simpul gagal) sawise kelangan konektivitas. Pisanan, ayo elinga yen antrian tartamtu di-host ing simpul tartamtu, nanging rute lan kabijakan ditiru ing kabeh simpul. Klien bisa nyambung menyang simpul apa wae, lan rute internal bakal ngarahake menyang ngendi wae. Nanging nalika simpul ditanggepi, nolak sambungan, mula klien kudu nyambung menyang simpul liyane. Yen simpul tiba, ora ana sing bisa ditindakake.
Pilihan kita:
- Kluster diakses nggunakake load balancer sing mung muter liwat simpul lan klien nyoba nyambungake maneh nganti sukses. Yen simpul mudhun utawa dilereni soko tugas, nyoba kanggo nyambung menyang simpul bakal gagal, nanging upaya sakteruse bakal pindhah menyang server liyane (kanthi cara round-robin). Iki cocok kanggo mundhut short-term panyambungan utawa server downed sing bakal cepet digawa bali munggah.
- Ngakses kluster liwat load balancer lan mbusak simpul sing digantung / gagal saka dhaptar sanalika dideteksi. Yen kita nindakake iki kanthi cepet, lan yen klien bisa nyoba maneh sambungan kasebut, mula kita bakal entuk kasedhiyan sing tetep.
- Menehi saben klien dhaftar kabeh kelenjar, lan klien acak milih salah siji saka nalika nyambungake. Yen nampa kesalahan nalika nyoba nyambungake, pindhah menyang simpul sabanjure ing dhaptar nganti nyambung.
- Mbusak lalu lintas saka simpul gagal / dilereni soko tugas nggunakake DNS. Iki rampung nggunakake TTL cilik.
temonan
RabbitMQ clustering duwe kaluwihan lan cacat. Kerugian sing paling serius yaiku:
- nalika gabung karo kluster, simpul mbuwang data;
- pamblokiran sinkronisasi nyebabake antrian dadi ora kasedhiya.
Kabeh keputusan sing angel ditindakake saka rong fitur arsitektur kasebut. Yen RabbitMQ bisa nyimpen data nalika kluster digabung maneh, sinkronisasi bakal luwih cepet. Yen bisa sinkronisasi non-blocking, luwih apik ndhukung antrian gedhe. Ndandani loro masalah iki bakal ningkatake kinerja RabbitMQ minangka teknologi olahpesen sing tahan kesalahan lan kasedhiya banget. Aku bakal ragu-ragu kanggo nyaranake RabbitMQ kanthi clustering ing kahanan ing ngisor iki:
- Jaringan sing ora bisa dipercaya.
- Panyimpenan sing ora bisa dipercaya.
- Antri dawa banget.
Nalika nerangake setelan kasedhiyan dhuwur, nimbang ing ngisor iki:
ha-promote-on-failure=alwaysha-sync-mode=manualcluster_partition_handling=ignore(utawaautoheal)- pesen terus-terusan
- mesthekake klien nyambung menyang simpul aktif nalika sawetara simpul gagal
Kanggo konsistensi (keamanan data), nimbang setelan ing ngisor iki:
- Penerbit Konfirmasi lan Pengakuan Manual ing sisih konsumen
ha-promote-on-failure=when-synced, yen penerbit bisa nyoba maneh mengko lan yen sampeyan duwe panyimpenan sing dipercaya banget! Yen ora sijine=always.ha-sync-mode=automatic(nanging kanggo antrian gedhe sing ora aktif, mode manual bisa uga dibutuhake; uga nimbang manawa ora kasedhiya bakal nyebabake pesen ilang)- Ngaso mode Minoritas
- pesen terus-terusan
Kita durung nutupi kabeh masalah toleransi kesalahan lan kasedhiyan dhuwur; contone, carane aman nindakake prosedur administratif (kayata nganyari rolling). Kita uga kudu ngomong babagan federasi lan plugin Shovel.
Yen aku wis ora kejawab liyane, mugi kula ngerti.
Deleng uga sandi , Ing ngendi aku nindakake kacilakan ing kluster RabbitMQ nggunakake Docker lan Blockade kanggo nyoba sawetara skenario mundhut pesen sing diterangake ing artikel iki.
Artikel sadurunge ing seri:
No. 1 -
No. 2 -
No. 3 -
Source: www.habr.com