Toleransi kesalahan dan ketersediaan tinggi adalah topik besar, jadi kami akan menumpukan artikel berasingan kepada RabbitMQ dan Kafka. Artikel ini adalah mengenai RabbitMQ, dan yang seterusnya adalah mengenai Kafka, berbanding dengan RabbitMQ. Ini adalah artikel yang panjang, jadi selesakan diri anda.

Mari kita lihat strategi toleransi kesalahan, konsistensi dan ketersediaan tinggi (HA) serta pertukaran yang dibuat oleh setiap strategi. RabbitMQ boleh berjalan pada kelompok nod - dan kemudian diklasifikasikan sebagai sistem teragih. Apabila ia datang kepada sistem yang diedarkan, kami sering bercakap tentang konsistensi dan ketersediaan.

Konsep ini menerangkan bagaimana sistem bertindak apabila ia gagal. Kegagalan sambungan rangkaian, kegagalan pelayan, kegagalan cakera keras, ketiadaan sementara pelayan disebabkan oleh pengumpulan sampah, kehilangan paket atau kelembapan sambungan rangkaian. Semua ini boleh menyebabkan kehilangan data atau konflik. Ternyata hampir mustahil untuk menyediakan sistem yang konsisten sepenuhnya (tiada kehilangan data, tiada perbezaan data) dan tersedia (akan menerima baca dan tulis) untuk semua senario kegagalan.

Kami akan melihat bahawa konsistensi dan ketersediaan berada di hujung spektrum yang bertentangan, dan anda perlu memilih cara untuk mengoptimumkan. Berita baiknya ialah dengan RabbitMQ pilihan ini adalah mungkin. Anda mempunyai tuil "nerdy" semacam ini untuk mengalihkan keseimbangan ke arah konsistensi yang lebih baik atau kebolehaksesan yang lebih baik.

Kami akan memberi perhatian khusus kepada konfigurasi yang membawa kepada kehilangan data akibat rekod yang disahkan. Terdapat rantaian tanggungjawab antara penerbit, broker dan pengguna. Sebaik sahaja mesej dihantar kepada broker, ia adalah tugasnya untuk tidak kehilangan mesej. Apabila broker mengakui penerimaan penerbit mesej, kami tidak menjangka ia akan hilang. Tetapi kita akan melihat bahawa ini sebenarnya boleh berlaku bergantung pada konfigurasi broker dan penerbit anda.

Primitif Ketahanan Nod Tunggal

Beratur/Penghalaan Berdaya tahan

Terdapat dua jenis baris gilir dalam RabbitMQ: tahan lama dan tidak tahan lama. Semua baris gilir disimpan dalam pangkalan data Mnesia. Baris gilir yang tahan lama diiklankan semula pada permulaan nod dan dengan itu bertahan dari permulaan semula, ranap sistem atau ranap pelayan (selagi data itu berterusan). Ini bermakna selagi anda mengisytiharkan laluan (pertukaran) dan baris gilir sebagai berdaya tahan, infrastruktur baris gilir/laluan akan kembali dalam talian.

Barisan beratur dan penghalaan yang tidak menentu dikeluarkan apabila nod dimulakan semula.

Mesej berterusan

Hanya kerana baris gilir adalah tahan lama tidak bermakna bahawa semua mesejnya akan bertahan dalam permulaan semula nod. Hanya mesej yang ditetapkan oleh penerbit sebagai berdaya tahan (berterusan). Mesej berterusan membuat beban tambahan pada broker, tetapi jika kehilangan mesej tidak dapat diterima, maka tiada pilihan lain.

nasi. 1. Matriks kelestarian

Pengelompokan dengan pencerminan baris gilir

Untuk bertahan daripada kehilangan broker, kita memerlukan redundansi. Kita boleh menggabungkan berbilang nod RabbitMQ ke dalam kelompok, dan kemudian menambah lebihan tambahan dengan mereplikasi baris gilir antara berbilang nod. Dengan cara ini, jika satu nod gagal, kami tidak kehilangan data dan kekal tersedia.

Pencerminan baris gilir:

• satu baris gilir utama (master), yang menerima semua arahan tulis dan baca
• satu atau lebih cermin yang menerima semua mesej dan metadata daripada baris gilir utama. Cermin ini tidak ada untuk penskalaan, tetapi semata-mata untuk redundansi.

nasi. 2. Pencerminan baris gilir

Pencerminan ditetapkan oleh dasar yang sesuai. Di dalamnya anda boleh memilih pekali replikasi dan juga nod di mana baris gilir harus ditempatkan. Contoh:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (satu tuan dan satu cermin)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Pengesahan penerbit

Untuk mencapai rakaman yang konsisten, Pengesahan Penerbit diperlukan. Tanpa mereka, terdapat risiko mesej hilang. Pengesahan dihantar kepada penerbit selepas mesej ditulis ke cakera. RabbitMQ menulis mesej ke cakera bukan selepas diterima, tetapi secara berkala, dalam kawasan beberapa ratus milisaat. Apabila baris gilir dicerminkan, pengakuan dihantar hanya selepas semua cermin juga menulis salinan mesej mereka ke cakera. Ini bermakna bahawa menggunakan pengesahan menambah kependaman, tetapi jika keselamatan data adalah penting, maka ia adalah perlu.

Beratur Failover

Apabila broker berhenti atau ranap, semua pemimpin baris gilir (tuan) pada nod itu ranap bersama dengannya. Kelompok itu kemudian memilih cermin tertua bagi setiap induk dan mempromosikannya sebagai induk baharu.

nasi. 3. Berbilang baris gilir bercermin dan dasar mereka

Broker 3 turun. Ambil perhatian bahawa cermin Queue C pada Broker 2 sedang dinaikkan pangkat kepada induk. Juga ambil perhatian bahawa cermin baharu telah dibuat untuk Baris Gilir C pada Broker 1. RabbitMQ sentiasa cuba mengekalkan faktor replikasi yang dinyatakan dalam dasar anda.

nasi. 4. Broker 3 gagal, menyebabkan barisan C gagal

Broker 1 seterusnya jatuh! Kami hanya mempunyai satu broker yang tinggal. Cermin Queue B dinaikkan pangkat kepada master.

Rajah. Xnumx

Kami telah mengembalikan Broker 1. Tidak kira sejauh mana data bertahan daripada kehilangan dan pemulihan broker, semua mesej baris gilir yang dicerminkan akan dibuang apabila dimulakan semula. Ini penting untuk diperhatikan kerana akan ada akibatnya. Kami akan melihat implikasi ini sebentar lagi. Jadi Broker 1 kini menjadi ahli kluster sekali lagi, dan kluster cuba mematuhi dasar dan oleh itu mencipta cermin pada Broker 1.

Dalam kes ini, kehilangan Broker 1 telah lengkap, begitu juga dengan data, jadi Barisan B yang tidak dicerminkan telah hilang sepenuhnya.

nasi. 6. Broker 1 kembali berkhidmat

Broker 3 kembali dalam talian, jadi baris gilir A dan B mendapatkan kembali cermin yang dibuat padanya untuk memenuhi dasar HA mereka. Tetapi kini semua baris gilir utama berada pada satu nod! Ini tidak sesuai, taburan sekata antara nod adalah lebih baik. Malangnya, tidak banyak pilihan di sini untuk mengimbangi semula induk. Kami akan kembali kepada isu ini kemudian kerana kami perlu melihat penyegerakan baris gilir terlebih dahulu.

nasi. 7. Broker 3 kembali berkhidmat. Semua baris gilir utama pada satu nod!

Jadi sekarang anda sepatutnya mempunyai idea tentang bagaimana cermin memberikan redundansi dan toleransi kesalahan. Ini memastikan ketersediaan sekiranya berlaku kegagalan nod tunggal dan melindungi daripada kehilangan data. Tetapi kita belum selesai, kerana sebenarnya ia lebih rumit.

Segerakkan

Apabila membuat cermin baharu, semua mesej baharu akan sentiasa direplikasi kepada cermin ini dan mana-mana yang lain. Bagi data sedia ada dalam baris gilir induk, kita boleh menirunya ke cermin baharu, yang menjadi salinan lengkap induk. Kita juga boleh memilih untuk tidak meniru mesej sedia ada dan membiarkan baris gilir utama dan cermin baharu berkumpul dalam masa, dengan mesej baharu tiba di bahagian ekor dan mesej sedia ada meninggalkan ketua baris gilir utama.

Penyegerakan ini dilakukan secara automatik atau manual dan diuruskan menggunakan dasar baris gilir. Mari kita lihat satu contoh.

Kami mempunyai dua baris gilir bercermin. Barisan A disegerakkan secara automatik, dan Baris B disegerakkan secara manual. Kedua-dua baris gilir mengandungi sepuluh mesej.

nasi. 8. Dua baris gilir dengan mod penyegerakan yang berbeza

Sekarang kita kehilangan Broker 3.

nasi. 9. Broker 3 jatuh

Broker 3 kembali ke perkhidmatan. Kelompok mencipta cermin untuk setiap baris gilir pada nod baharu dan secara automatik menyegerakkan Baris Gilir A baharu dengan induk. Walau bagaimanapun, cermin Baris B baharu kekal kosong. Dengan cara ini kita mempunyai lebihan penuh pada Baris A dan hanya satu cermin untuk mesej Baris B sedia ada.

nasi. 10. Cermin baharu Baris A menerima semua mesej sedia ada, tetapi cermin Baris Gilir B baharu tidak.

Sepuluh lagi mesej tiba dalam kedua-dua baris gilir. Broker 2 kemudian ranap dan Baris A berguling kembali ke cermin tertua, iaitu pada Broker 1. Tiada kehilangan data apabila ia gagal. Dalam Baris B, terdapat dua puluh mesej dalam induk dan hanya sepuluh dalam cermin kerana baris gilir ini tidak pernah mereplikasi sepuluh mesej asal.

nasi. 11. Baris A berguling kembali ke Broker 1 tanpa kehilangan mesej

Sepuluh lagi mesej tiba dalam kedua-dua baris gilir. Sekarang Broker 1 ranap. Baris A dengan mudah beralih ke cermin tanpa kehilangan mesej. Walau bagaimanapun, Barisan B menghadapi masalah. Pada ketika ini kita boleh mengoptimumkan sama ada ketersediaan atau konsistensi.

Jika kita ingin mengoptimumkan kebolehaksesan, maka dasar itu ha-promote-on-failure harus dipasang di sentiasa. Ini ialah nilai lalai, jadi anda tidak boleh menentukan dasar sama sekali. Dalam kes ini, kami pada dasarnya membenarkan kegagalan dalam cermin tidak segerak. Ini akan menyebabkan mesej hilang, tetapi baris gilir akan kekal boleh dibaca dan boleh ditulis.

nasi. 12. Baris gilir A digulung semula ke Broker 3 tanpa kehilangan mesej. Baris Gilir B kembali ke Broker 3 dengan sepuluh mesej hilang

Kami juga boleh memasang ha-promote-on-failure menjadi makna when-synced. Dalam kes ini, daripada beralih semula ke cermin, baris gilir akan menunggu sehingga Broker 1 dengan datanya kembali ke mod dalam talian. Selepas ia kembali, baris gilir utama kembali pada Broker 1 tanpa kehilangan data. Ketersediaan dikorbankan untuk keselamatan data. Tetapi ini adalah mod berisiko yang bahkan boleh menyebabkan kehilangan data lengkap, yang akan kita lihat sebentar lagi.

nasi. 13. Barisan B kekal tidak tersedia selepas kehilangan Broker 1

Anda mungkin bertanya, "Adakah lebih baik untuk tidak menggunakan penyegerakan automatik?" Jawapannya ialah penyegerakan adalah operasi menyekat. Semasa penyegerakan, baris gilir utama tidak boleh melakukan sebarang operasi baca atau tulis!

Mari kita lihat satu contoh. Sekarang kami mempunyai barisan yang sangat panjang. Bagaimanakah mereka boleh membesar dengan saiz sedemikian? Atas beberapa sebab:

• Baris gilir tidak digunakan secara aktif
• Ini adalah baris gilir berkelajuan tinggi, dan pada masa ini pengguna perlahan
• Ini adalah barisan beratur laju, terdapat gangguan dan pengguna mengejarnya

nasi. 14. Dua baris gilir besar dengan mod penyegerakan yang berbeza

Sekarang Broker 3 jatuh.

nasi. 15. Broker 3 jatuh, meninggalkan satu induk dan cermin dalam setiap baris

Broker 3 kembali dalam talian dan cermin baharu dicipta. Baris Gilir Utama A mula mereplikasi mesej sedia ada ke cermin baharu, dan pada masa ini Baris Gilir tidak tersedia. Ia mengambil masa dua jam untuk mereplikasi data, mengakibatkan dua jam masa henti untuk Baris Gilir ini!

Walau bagaimanapun, Barisan B kekal tersedia sepanjang tempoh tersebut. Dia mengorbankan beberapa lebihan untuk kebolehaksesan.

nasi. 16. Baris gilir kekal tidak tersedia semasa penyegerakan

Selepas dua jam, Barisan A juga tersedia dan boleh mula menerima bacaan dan tulis semula.

Updates

Tingkah laku menyekat ini semasa penyegerakan menyukarkan untuk mengemas kini kelompok dengan baris gilir yang sangat besar. Pada satu ketika, nod induk perlu dimulakan semula, yang bermaksud sama ada bertukar kepada cermin atau melumpuhkan baris gilir semasa pelayan sedang dinaik taraf. Jika kita memilih untuk beralih, kita akan kehilangan mesej jika cermin tidak disegerakkan. Secara lalai, semasa gangguan broker, failover kepada cermin tidak segerak tidak dilakukan. Ini bermakna sebaik sahaja broker kembali, kami tidak kehilangan sebarang mesej, satu-satunya kerosakan adalah barisan mudah. Peraturan tingkah laku apabila broker diputuskan sambungan ditetapkan oleh polisi ha-promote-on-shutdown. Anda boleh menetapkan satu daripada dua nilai:

• always= peralihan kepada cermin tidak segerak didayakan
• when-synced= peralihan kepada cermin yang disegerakkan sahaja, jika tidak baris gilir menjadi tidak boleh dibaca dan tidak boleh ditulis. Barisan beratur kembali ke perkhidmatan sebaik sahaja broker kembali

Satu cara atau yang lain, dengan baris gilir yang besar anda perlu memilih antara kehilangan data dan ketiadaan.

Apabila Ketersediaan Meningkatkan Keselamatan Data

Terdapat satu lagi komplikasi yang perlu dipertimbangkan sebelum membuat keputusan. Walaupun penyegerakan automatik lebih baik untuk redundansi, bagaimanakah ia memberi kesan kepada keselamatan data? Sudah tentu, dengan lebihan yang lebih baik, RabbitMQ kurang berkemungkinan kehilangan mesej sedia ada, tetapi bagaimana pula dengan mesej baharu daripada penerbit?

Di sini anda perlu mempertimbangkan perkara berikut:

• Bolehkah penerbit hanya mengembalikan ralat dan meminta perkhidmatan huluan atau pengguna mencuba lagi kemudian?
• Bolehkah penerbit menyimpan mesej secara setempat atau dalam pangkalan data untuk mencuba lagi nanti?

Jika penerbit hanya boleh membuang mesej, maka sebenarnya, meningkatkan kebolehcapaian juga meningkatkan keselamatan data.

Oleh itu, keseimbangan mesti dicari, dan penyelesaiannya bergantung pada situasi tertentu.

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

Idea ha-promote-on-failure= apabila disegerakkan ialah kita menghalang beralih kepada cermin tidak segerak dan dengan itu mengelakkan kehilangan data. Baris gilir kekal tidak boleh dibaca atau ditulis. Sebaliknya, kami cuba memulihkan broker yang ranap dengan datanya utuh supaya ia boleh meneruskan fungsi sebagai induk tanpa kehilangan data.

Tetapi (dan ini adalah besar tetapi) jika broker telah kehilangan datanya, maka kita mempunyai masalah besar: baris gilir hilang! Semua data hilang! Walaupun anda mempunyai cermin yang kebanyakannya mengejar baris gilir utama, cermin tersebut juga dibuang.

Untuk menambah semula nod dengan nama yang sama, kami memberitahu kluster untuk melupakan nod yang hilang (dengan perintah rabbitmqctl forget_cluster_node) dan mulakan broker baharu dengan nama hos yang sama. Walaupun kluster mengingati nod yang hilang, ia mengingati baris gilir lama dan cermin yang tidak disegerakkan. Apabila kluster diberitahu untuk melupakan nod yatim, baris gilir itu juga dilupakan. Sekarang kita perlu mengisytiharkannya semula. Kami kehilangan semua data, walaupun kami mempunyai cermin dengan set data separa. Adalah lebih baik untuk menukar kepada cermin tidak segerak!

Oleh itu, penyegerakan manual (dan kegagalan untuk menyegerak) dalam kombinasi dengan ha-promote-on-failure=when-synced, pada pendapat saya, agak berisiko. Dokumen mengatakan pilihan ini wujud untuk keselamatan data, tetapi ia adalah pisau bermata dua.

Mengimbangi semula induk

Seperti yang dijanjikan, kami kembali kepada masalah pengumpulan semua induk pada satu atau beberapa nod. Ini juga boleh berlaku akibat kemas kini kelompok bergulir. Dalam kelompok tiga nod, semua baris gilir induk akan terkumpul pada satu atau dua nod.

Pengimbangan semula tuan boleh menjadi masalah kerana dua sebab:

• Tiada alat yang baik untuk melakukan pengimbangan semula
• Penyegerakan baris gilir

Terdapat pihak ketiga untuk pengimbangan semula plugin, yang tidak disokong secara rasmi. Berkenaan pemalam pihak ketiga dalam manual RabbitMQ berkata: “Pemalam menyediakan beberapa alat konfigurasi dan pelaporan tambahan, tetapi tidak disokong atau disahkan oleh pasukan RabbitMQ. Gunakan atas risiko anda sendiri."

Terdapat satu lagi helah untuk mengalihkan baris gilir utama melalui dasar HA. Manual menyebut skrip untuk ini. Ia berfungsi seperti ini:

• Mengalih keluar semua cermin menggunakan dasar sementara yang mempunyai keutamaan yang lebih tinggi daripada dasar HA sedia ada.
• Menukar dasar sementara HA untuk menggunakan mod nod, menentukan nod yang mana baris gilir induk harus dipindahkan.
• Menyegerakkan baris gilir untuk pemindahan tolak.
• Selepas penghijrahan selesai, memadamkan dasar sementara. Dasar HA awal berkuat kuasa dan bilangan cermin yang diperlukan dibuat.

Kelemahannya ialah pendekatan ini mungkin tidak berfungsi jika anda mempunyai baris gilir yang besar atau keperluan redundansi yang ketat.

Sekarang mari kita lihat cara kluster RabbitMQ berfungsi dengan partition rangkaian.

Kehilangan sambungan

Nod sistem teragih disambungkan oleh pautan rangkaian, dan pautan rangkaian boleh dan akan diputuskan. Kekerapan gangguan bergantung pada infrastruktur tempatan atau kebolehpercayaan awan yang dipilih. Walau apa pun, sistem yang diedarkan mesti dapat mengatasinya. Sekali lagi kami mempunyai pilihan antara ketersediaan dan konsistensi, dan sekali lagi berita baiknya ialah RabbitMQ menyediakan kedua-dua pilihan (hanya tidak pada masa yang sama).

Dengan RabbitMQ kami mempunyai dua pilihan utama:

• Benarkan pembahagian logik (split-brain). Ini memastikan ketersediaan, tetapi boleh menyebabkan kehilangan data.
• Lumpuhkan pemisahan logik. Boleh mengakibatkan kehilangan ketersediaan jangka pendek bergantung pada cara pelanggan menyambung ke kluster. Juga boleh menyebabkan ketiadaan lengkap dalam kelompok dua nod.

Tetapi apakah pemisahan logik? Ini adalah apabila gugusan terbelah dua kerana kehilangan sambungan rangkaian. Pada setiap sisi, cermin dinaikkan pangkat kepada master, sehingga akhirnya terdapat beberapa master setiap giliran.

nasi. 17. Barisan utama dan dua cermin, setiap satu pada nod yang berasingan. Kemudian kegagalan rangkaian berlaku dan satu cermin menjadi tertanggal. Nod yang dipisahkan melihat bahawa dua yang lain telah jatuh dan mempromosikan cerminnya kepada induk. Kami kini mempunyai dua baris gilir utama, boleh ditulis dan boleh dibaca.

Jika penerbit menghantar data kepada kedua-dua induk, kami akan mendapat dua salinan baris gilir yang berbeza.

Mod RabbitMQ yang berbeza menyediakan sama ada ketersediaan atau konsistensi.

Abaikan mod (lalai)

Mod ini memastikan kebolehaksesan. Selepas kehilangan sambungan, pemisahan logik berlaku. Selepas ketersambungan dipulihkan, pentadbir mesti memutuskan partition mana yang akan diberi keutamaan. Bahagian yang kalah akan dimulakan semula dan semua data terkumpul di bahagian itu akan hilang.

nasi. 18. Tiga penerbit dikaitkan dengan tiga broker. Secara dalaman, kluster mengarahkan semua permintaan ke baris gilir utama pada Broker 2.

Sekarang kita kehilangan Broker 3. Dia melihat bahawa broker lain telah jatuh dan mempromosikan cerminnya kepada tuan. Ini adalah bagaimana pemisahan logik berlaku.

nasi. 19. Pembahagian logik (split-brain). Rekod masuk ke dalam dua baris gilir utama, dan dua salinan itu berbeza.

Ketersambungan dipulihkan, tetapi pemisahan logik kekal. Pentadbir mesti memilih pihak yang kalah secara manual. Dalam kes di bawah, pentadbir but semula Broker 3. Semua mesej yang dia tidak berjaya hantar hilang.

nasi. 20. Pentadbir melumpuhkan Broker 3.

nasi. 21. Pentadbir memulakan Broker 3 dan ia menyertai kluster, kehilangan semua mesej yang ditinggalkan di sana.

Semasa kehilangan ketersambungan dan selepas pemulihannya, kluster dan baris gilir ini tersedia untuk membaca dan menulis.

Mod auto sembuh

Berfungsi sama seperti mod Abaikan, kecuali kluster itu sendiri secara automatik memilih bahagian yang hilang selepas membelah dan memulihkan sambungan. Bahagian yang kalah kembali ke gugusan kosong, dan baris gilir kehilangan semua mesej yang dihantar hanya ke bahagian itu.

Jeda Mod Minoriti

Jika kami tidak mahu membenarkan pembahagian logik, maka satu-satunya pilihan kami ialah membuang bacaan dan tulis pada bahagian yang lebih kecil selepas partition cluster. Apabila broker melihat bahawa ia berada di bahagian yang lebih kecil, ia menangguhkan kerja, iaitu, ia menutup semua sambungan sedia ada dan menolak sebarang sambungan baharu. Sekali sesaat ia menyemak pemulihan sambungan. Setelah ketersambungan dipulihkan, ia menyambung semula operasi dan menyertai kluster.

nasi. 22. Tiga penerbit dikaitkan dengan tiga broker. Secara dalaman, kluster mengarahkan semua permintaan ke baris gilir utama pada Broker 2.

Broker 1 dan 2 kemudian berpisah daripada Broker 3. Daripada mempromosikan cermin mereka kepada master, Broker 3 menggantung dan menjadi tidak tersedia.

nasi. 23. Broker 3 berhenti seketika, memutuskan semua pelanggan dan menolak permintaan sambungan.

Setelah ketersambungan dipulihkan, ia kembali ke kluster.

Mari lihat contoh lain di mana baris gilir utama adalah pada Broker 3.

nasi. 24. Barisan utama pada Broker 3.

Kemudian kehilangan sambungan yang sama berlaku. Broker 3 berhenti seketika kerana ia berada di bahagian yang lebih kecil. Di sisi lain, nod melihat bahawa Broker 3 telah jatuh, jadi cermin lama dari Broker 1 dan 2 dinaikkan pangkat kepada master.

nasi. 25. Peralihan kepada Broker 2 jika Broker 3 tidak tersedia.

Apabila kesambungan dipulihkan, Broker 3 akan menyertai kluster.

nasi. 26. Kluster telah kembali beroperasi seperti biasa.

Perkara penting untuk difahami di sini ialah kita mendapat konsistensi, tetapi kita juga boleh mendapatkan ketersediaan, jika Kami akan berjaya memindahkan pelanggan ke kebanyakan bahagian. Untuk kebanyakan situasi, saya secara peribadi akan memilih mod Jeda Minoriti, tetapi ia benar-benar bergantung pada kes individu.

Untuk memastikan ketersediaan, adalah penting untuk memastikan bahawa pelanggan berjaya menyambung ke hos. Mari lihat pilihan kami.

Memastikan Kesalinghubungan Pelanggan

Kami mempunyai beberapa pilihan untuk cara mengarahkan pelanggan ke bahagian utama kluster atau ke nod yang berfungsi (selepas satu nod gagal) selepas kehilangan sambungan. Mula-mula, mari kita ingat bahawa baris gilir tertentu dihoskan pada nod tertentu, tetapi penghalaan dan dasar direplikasi merentas semua nod. Pelanggan boleh menyambung ke mana-mana nod, dan penghalaan dalaman akan mengarahkan mereka ke mana mereka perlu pergi. Tetapi apabila nod digantung, ia menolak sambungan, jadi pelanggan mesti menyambung ke nod lain. Jika nod itu jatuh, tidak banyak yang boleh dia lakukan sama sekali.

Pilihan kami:

• Kelompok itu diakses menggunakan pengimbang beban yang hanya berputar melalui nod dan pelanggan cuba menyambung semula sehingga berjaya. Jika nod turun atau digantung, maka percubaan untuk menyambung ke nod itu akan gagal, tetapi percubaan berikutnya akan pergi ke pelayan lain (dalam cara round-robin). Ini sesuai untuk kehilangan sambungan jangka pendek atau pelayan yang terputus yang akan dibawa semula dengan cepat.
• Akses kluster melalui pengimbang beban dan alih keluar nod yang digantung/gagal daripada senarai sebaik sahaja ia dikesan. Jika kami melakukan ini dengan cepat, dan jika pelanggan dapat mencuba semula sambungan, maka kami akan mencapai ketersediaan yang berterusan.
• Beri setiap pelanggan senarai semua nod, dan pelanggan secara rawak memilih salah satu daripada mereka apabila menyambung. Jika ia menerima ralat semasa cuba menyambung, ia bergerak ke nod seterusnya dalam senarai sehingga ia bersambung.
• Alih keluar trafik daripada nod yang gagal/digantung menggunakan DNS. Ini dilakukan menggunakan TTL kecil.

Penemuan

Pengelompokan RabbitMQ mempunyai kelebihan dan kekurangannya. Kelemahan yang paling serius ialah:

• apabila menyertai kluster, nod membuang data mereka;
• menyekat penyegerakan menyebabkan baris gilir menjadi tidak tersedia.

Semua keputusan sukar berpunca daripada dua ciri seni bina ini. Jika RabbitMQ boleh menyimpan data apabila kluster disambung semula, maka penyegerakan akan menjadi lebih pantas. Jika ia mampu menyegerakkan tanpa menyekat, ia lebih baik menyokong baris gilir yang besar. Membetulkan kedua-dua isu ini akan meningkatkan prestasi RabbitMQ sebagai teknologi pemesejan yang tahan terhadap kesalahan dan sangat tersedia. Saya teragak-agak untuk mengesyorkan RabbitMQ dengan pengelompokan dalam situasi berikut:

• Rangkaian yang tidak boleh dipercayai.
• Storan yang tidak boleh dipercayai.
• Beratur panjang sangat.

Apabila ia berkaitan dengan tetapan ketersediaan tinggi, pertimbangkan perkara berikut:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (Atau autoheal)
• mesej berterusan
• memastikan pelanggan menyambung ke nod aktif apabila beberapa nod gagal

Untuk ketekalan (keselamatan data), pertimbangkan tetapan berikut:

• Penerbit Mengesahkan dan Pengakuan Manual di sisi pengguna
• ha-promote-on-failure=when-synced, jika penerbit boleh mencuba lagi kemudian dan jika anda mempunyai storan yang sangat boleh dipercayai! Jika tidak letak =always.
• ha-sync-mode=automatic (tetapi untuk baris gilir besar yang tidak aktif, mod manual mungkin diperlukan; pertimbangkan juga sama ada ketiadaan akan menyebabkan mesej hilang)
• Jeda mod Minoriti
• mesej berterusan

Kami belum membincangkan semua isu toleransi kesalahan dan ketersediaan yang tinggi; contohnya, cara melaksanakan prosedur pentadbiran dengan selamat (seperti kemas kini bergulir). Kita juga perlu bercakap tentang persekutuan dan pemalam Shovel.

Jika saya terlepas apa-apa lagi, sila beritahu saya.

Lihat juga saya jawatan, di mana saya melakukan kemusnahan pada kelompok RabbitMQ menggunakan Docker dan Blockade untuk menguji beberapa senario kehilangan mesej yang diterangkan dalam artikel ini.

Artikel sebelumnya dalam siri ini:
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