Xatolarga chidamlilik va yuqori mavjudlik katta mavzular, shuning uchun biz RabbitMQ va Kafkaga alohida maqolalar bag'ishlaymiz. Ushbu maqola RabbitMQ haqida, keyingisi RabbitMQ bilan solishtirganda Kafka haqida. Bu uzoq maqola, shuning uchun o'zingizni qulay his qiling.

Keling, xatolarga chidamlilik, izchillik va yuqori mavjudlik (HA) strategiyalarini va har bir strategiya yaratadigan kelishuvlarni ko'rib chiqaylik. RabbitMQ tugunlar klasterida ishlashi mumkin va keyinchalik taqsimlangan tizim sifatida tasniflanadi. Tarqatilgan tizimlar haqida gap ketganda, biz ko'pincha izchillik va mavjudlik haqida gapiramiz.

Ushbu tushunchalar tizim muvaffaqiyatsizlikka uchraganda qanday harakat qilishini tasvirlaydi. Tarmoqqa ulanishda xatolik, server xatosi, qattiq diskda xatolik, axlat yig'ish, paketlarni yo'qotish yoki tarmoq ulanishining sekinlashishi tufayli serverning vaqtincha ishlamasligi. Bularning barchasi ma'lumotlarning yo'qolishiga yoki nizolarga olib kelishi mumkin. Ma'lum bo'lishicha, barcha muvaffaqiyatsizlik stsenariylari uchun ham to'liq mos keladigan (ma'lumotlar yo'qotilmaydi, ma'lumotlarning farqi yo'q) va mavjud (o'qish va yozishni qabul qiladi) tizimni o'rnatish deyarli mumkin emas.

Biz barqarorlik va mavjudlik spektrning qarama-qarshi tomonida ekanligini ko'ramiz va siz optimallashtirishning qaysi usulini tanlashingiz kerak. Yaxshi xabar shundaki, RabbitMQ bilan bu tanlov mumkin. Muvozanatni yanada mustahkamlik yoki ko'proq qulaylik tomon o'zgartirish uchun sizda bunday "nerdy" tutqichlar mavjud.

Tasdiqlangan yozuvlar tufayli qaysi konfiguratsiyalar ma'lumotlar yo'qolishiga olib kelishiga alohida e'tibor qaratamiz. Noshirlar, brokerlar va iste'molchilar o'rtasida mas'uliyat zanjiri mavjud. Xabar brokerga uzatilgandan so'ng, uning vazifasi xabarni yo'qotmaslikdir. Broker nashriyotning xabarni olganini tan olganida, biz uning yo'qolishini kutmaymiz. Lekin biz bu sizning brokeringiz va nashriyotingiz konfiguratsiyasiga qarab sodir bo'lishi mumkinligini ko'ramiz.

Yagona tugunli chidamlilik primitivlari

Chidamli navbat/marshrutlash

RabbitMQ-da navbatlarning ikki turi mavjud: bardoshli va bardoshli bo'lmagan. Barcha navbatlar Mnesia ma'lumotlar bazasida saqlanadi. Bardoshli navbatlar tugunni ishga tushirishda qayta e'lon qilinadi va shu tariqa qayta ishga tushirish, tizim ishdan chiqishi yoki serverning ishdan chiqishidan (ma'lumotlar saqlanib qolganda) omon qoladi. Bu shuni anglatadiki, siz marshrutlash (almashtirish) va navbatni barqaror deb e'lon qilsangiz, navbat/marshrutlash infratuzilmasi yana onlayn rejimiga qaytadi.

Tugun qayta ishga tushirilganda uchuvchan navbatlar va marshrutlash o'chiriladi.

Doimiy xabarlar

Navbatning bardoshli bo'lishi uning barcha xabarlari tugunni qayta ishga tushirganda omon qoladi degani emas. Faqat nashriyotchi tomonidan o'rnatilgan xabarlar barqaror (doimiy). Doimiy xabarlar brokerga qo'shimcha yuk yaratadi, ammo agar xabarni yo'qotish qabul qilinishi mumkin bo'lmasa, boshqa variant yo'q.

Guruch. 1. Barqarorlik matritsasi

Navbatni aks ettirish bilan klasterlash

Brokerni yo'qotishdan omon qolish uchun bizga ortiqcha kerak. Biz bir nechta RabbitMQ tugunlarini klasterga birlashtira olamiz va keyin bir nechta tugunlar orasidagi navbatlarni takrorlash orqali qo'shimcha ortiqcha qo'shishimiz mumkin. Shunday qilib, agar bitta tugun ishlamay qolsa, biz ma'lumotlarni yo'qotmaymiz va mavjud bo'lib qolamiz.

Navbatni aks ettirish:

• barcha yozish va o'qish buyruqlarini qabul qiladigan bitta asosiy navbat (master).
• asosiy navbatdan barcha xabarlar va metama'lumotlarni qabul qiladigan bir yoki bir nechta oyna. Bu nometall masshtablash uchun emas, balki faqat ortiqcha qilish uchun mavjud.

Guruch. 2. Navbatni aks ettirish

Ko'zgu tegishli siyosat bilan o'rnatiladi. Unda siz replikatsiya koeffitsientini va hatto navbat joylashishi kerak bo'lgan tugunlarni tanlashingiz mumkin. Misollar:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (bitta usta va bitta oyna)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Nashriyotni tasdiqlash

Barqaror yozib olish uchun nashriyot tasdiqlovchilari talab qilinadi. Ularsiz xabarlarni yo'qotish xavfi mavjud. Xabar diskka yozilganidan keyin nashriyotga tasdiqnoma yuboriladi. RabbitMQ xabarlarni diskka olgandan keyin emas, balki davriy ravishda, bir necha yuz millisekundlarda yozadi. Navbat aks ettirilganda, barcha oynalar xabarning nusxasini diskka yozgandan keyingina tasdiqnoma yuboriladi. Bu shuni anglatadiki, tasdiqlashlardan foydalanish kechikishni oshiradi, ammo agar ma'lumotlar xavfsizligi muhim bo'lsa, ular kerak.

Ishdan bo'shatish navbati

Broker ishdan chiqqanda yoki ishlamay qolsa, u bilan birga ushbu tugundagi barcha navbat rahbarlari (masterlar) ishdan chiqadi. Keyin klaster har bir ustaning eng qadimgi oynasini tanlaydi va uni yangi usta sifatida targ'ib qiladi.

Guruch. 3. Ko'p aks ettirilgan navbatlar va ularning siyosatlari

Broker 3 pastga tushadi. E'tibor bering, Broker 2-dagi C Queue oynasi master darajasiga ko'tarilmoqda. Broker 1da C navbati uchun yangi oyna yaratilganini ham unutmang. RabbitMQ har doim siyosatingizda ko‘rsatilgan replikatsiya faktorini saqlab qolishga harakat qiladi.

Guruch. 4. Broker 3 ishlamay qoldi, bu esa C navbatining ishlamay qolishiga olib keladi

Keyingi Broker 1 tushadi! Bizda faqat bitta broker qoldi. Navbat B oynasi master darajasiga ko'tariladi.

Shakl. 5

Biz Broker 1-ni qaytardik. Brokerning yo‘qolishi va tiklanishidan keyin ma’lumotlar qanchalik yaxshi saqlanib qolishidan qat’iy nazar, barcha aks ettirilgan navbat xabarlari qayta ishga tushirilganda o‘chirib tashlanadi. Buni e'tiborga olish kerak, chunki oqibatlar bo'ladi. Tez orada bu ta'sirlarni ko'rib chiqamiz. Shunday qilib, Broker 1 endi yana klaster a'zosi bo'lib, klaster siyosatlarga rioya qilishga harakat qiladi va shuning uchun Broker 1 da ko'zgularni yaratadi.

Bunday holda, 1-Brokerning yo'qolishi, ma'lumotlar kabi, to'liq bo'lgan, shuning uchun aks ettirilmagan B navbati butunlay yo'qolgan.

Guruch. 6. Broker 1 xizmatga qaytadi

Broker 3 yana onlayn, shuning uchun A va B navbatlari HA siyosatlarini qondirish uchun unda yaratilgan oynalarni qaytarib oladi. Ammo endi barcha asosiy navbatlar bitta tugunda! Bu ideal emas, tugunlar o'rtasida teng taqsimlash yaxshiroqdir. Afsuski, bu erda ustalarni muvozanatlash uchun juda ko'p imkoniyatlar mavjud emas. Biz bu masalaga keyinroq qaytamiz, chunki avval navbat sinxronizatsiyasini ko'rib chiqishimiz kerak.

Guruch. 7. Broker 3 xizmatga qaytadi. Barcha asosiy navbatlar bitta tugunda!

Shunday qilib, endi siz nometallning ortiqcha va nosozliklarga chidamliligini qanday ta'minlashi haqida tasavvurga ega bo'lishingiz kerak. Bu bitta tugun ishlamay qolganda mavjudlikni ta'minlaydi va ma'lumotlarni yo'qotishdan himoya qiladi. Lekin biz hali tugatmadik, chunki aslida bu ancha murakkab.

Sinxronizatsiya

Yangi oyna yaratishda barcha yangi xabarlar har doim ushbu oynaga va boshqa har qanday oynaga takrorlanadi. Asosiy navbatdagi mavjud ma'lumotlarga kelsak, biz uni yangi oynaga takrorlashimiz mumkin, bu esa masterning to'liq nusxasiga aylanadi. Shuningdek, biz mavjud xabarlarni takrorlamaslikni va asosiy navbat va yangi oynaning o'z vaqtida birlashishiga imkon berishimiz mumkin, yangi xabarlar dumiga etib boradi va mavjud xabarlar asosiy navbatning boshidan chiqadi.

Ushbu sinxronizatsiya avtomatik yoki qo'lda amalga oshiriladi va navbat siyosati yordamida boshqariladi. Keling, bir misolni ko'rib chiqaylik.

Bizda ikkita aks ettirilgan navbat bor. Navbat A avtomatik ravishda sinxronlanadi va B navbat qo'lda sinxronlanadi. Ikkala navbatda ham o'nta xabar mavjud.

Guruch. 8. Turli xil sinxronizatsiya rejimlariga ega bo'lgan ikkita navbat

Endi biz Broker 3 ni yo'qotmoqdamiz.

Guruch. 9. Broker 3 tushib ketdi

Broker 3 xizmatga qaytadi. Klaster yangi tugundagi har bir navbat uchun oyna yaratadi va yangi A navbatini master bilan avtomatik sinxronlashtiradi. Biroq, yangi B navbatining oynasi bo'sh qolmoqda. Shunday qilib, biz A navbatida to'liq zaxiraga va mavjud navbat B xabarlari uchun faqat bitta oynaga ega bo'lamiz.

Guruch. 10. A navbatining yangi oynasi barcha mavjud xabarlarni oladi, ammo B navbatining yangi oynasi qabul qilmaydi.

Ikkala navbatda ham o'nta xabar keladi. Broker 2 ishdan chiqadi va A navbati Broker 1da joylashgan eng eski oynaga qaytadi. U ishlamay qolganda ma’lumotlar yo‘qolmaydi. B navbatida ustada yigirmata xabar va ko'zguda faqat o'nta xabar bor, chunki bu navbat hech qachon asl o'nta xabarni takrorlamagan.

Guruch. 11. Navbat A xabarlarni yo'qotmasdan Broker 1 ga qaytadi

Ikkala navbatda ham o'nta xabar keladi. Endi Broker 1 ishdan chiqdi. Navbat A xabarlarni yo‘qotmasdan osongina oynaga o‘tadi. Biroq, B navbati muammolarga duch kelmoqda. Ushbu nuqtada biz mavjudlikni yoki izchillikni optimallashtirishimiz mumkin.

Agar biz mavjudlikni optimallashtirishni istasak, u holda siyosat Ha-muvaffaqiyatsizlikka-rag'batlantirish ichiga o'rnatilishi kerak har doim. Bu standart qiymat, shuning uchun siz siyosatni umuman belgilay olmaysiz. Bunday holda, biz sinxronlashtirilmagan ko'zgularda nosozliklarga yo'l qo'yamiz. Bu xabarlarning yo'qolishiga olib keladi, lekin navbat o'qilishi va yozilishi mumkin bo'lib qoladi.

Guruch. 12. A navbati xabarlarni yo'qotmasdan Broker 3 ga qaytariladi. Navbat B o'nta xabar yo'qolgan holda Broker 3 ga qaytadi

Biz ham o'rnatishimiz mumkin ha-promote-on-failure ma'noga kiradi when-synced. Bunday holda, navbat oynaga qaytish o'rniga, Broker 1 ma'lumotlari bilan onlayn rejimga qaytguncha kutadi. Qaytgandan so'ng, asosiy navbat hech qanday ma'lumot yo'qotmasdan 1-Brokerga qaytadi. Ma'lumotlar xavfsizligi uchun mavjudlik qurbon qilinadi. Ammo bu xavfli rejim bo'lib, u hatto ma'lumotlarning to'liq yo'qolishiga olib kelishi mumkin, biz buni qisqa vaqt ichida ko'rib chiqamiz.

Guruch. 13. 1-brokerni yo‘qotgandan keyin B navbati mavjud bo‘lmay qoladi

Siz so'rashingiz mumkin: "Avtomatik sinxronizatsiyani hech qachon ishlatmaslik yaxshiroqmi?" Javob shuki, sinxronizatsiya blokirovkalash operatsiyasidir. Sinxronizatsiya paytida asosiy navbat hech qanday o'qish yoki yozish operatsiyalarini bajara olmaydi!

Keling, bir misolni ko'rib chiqaylik. Hozir bizda juda uzun navbatlar bor. Qanday qilib ular shunchalik katta bo'lishi mumkin? Bir necha sabablarga ko'ra:

• Navbatlar faol ishlatilmaydi
• Bu yuqori tezlikdagi navbatlar va hozirda iste'molchilar sekin
• Bu yuqori tezlikdagi navbatlar, xatolik yuz berdi va iste'molchilar yetib kelishmoqda

Guruch. 14. Turli xil sinxronizatsiya rejimlariga ega bo'lgan ikkita katta navbat

Endi Broker 3 tushadi.

Guruch. 15. Broker 3 yiqilib, har bir navbatda bitta usta va oyna qoldirib ketadi

Broker 3 Internetga qaytadi va yangi oynalar yaratiladi. Asosiy navbat A mavjud xabarlarni yangi oynaga takrorlashni boshlaydi va bu vaqt ichida Navbat mavjud emas. Ma'lumotlarni takrorlash uchun ikki soat vaqt ketadi, natijada bu Navbatda ikki soatlik ishlamay qoladi!

Biroq, B navbati butun davr davomida mavjud bo'lib qoladi. U foydalanish imkoniyati uchun ba'zi ortiqcha narsalarni qurbon qildi.

Guruch. 16. Sinxronizatsiya vaqtida navbat mavjud bo'lmay qoladi

Ikki soatdan keyin A navbati ham mavjud bo'lib, o'qish va yozishni qayta qabul qila boshlaydi.

Yangilanishlar

Sinxronizatsiya paytida bunday blokirovka harakati juda katta navbatlar bilan klasterlarni yangilashni qiyinlashtiradi. Bir nuqtada, asosiy tugunni qayta ishga tushirish kerak, ya'ni server yangilanayotganda oynaga o'tish yoki navbatni o'chirishni anglatadi. Agar biz o'tishni tanlasak, oynalar sinxronlashtirilmasa, biz xabarlarni yo'qotamiz. Odatiy bo'lib, brokerning uzilishi vaqtida sinxronlashtirilmagan oynaga o'tish amalga oshirilmaydi. Bu shuni anglatadiki, broker qaytib kelishi bilan biz hech qanday xabarni yo'qotmaymiz, faqat zarar oddiy navbat edi. Broker o'chirilganda o'zini tutish qoidalari siyosat bilan belgilanadi ha-promote-on-shutdown. Siz ikkita qiymatdan birini o'rnatishingiz mumkin:

• always= sinxronlashtirilmagan ko'zgularga o'tish yoqilgan
• when-synced= faqat sinxronlashtirilgan oynaga o'tish, aks holda navbat o'qilmaydi va yozilmaydi. Navbat broker qaytib kelishi bilanoq xizmatga qaytadi

Qanday bo'lmasin, katta navbatlar bilan siz ma'lumotlarning yo'qolishi yoki mavjud emasligi o'rtasida tanlov qilishingiz kerak.

Mavjudlik ma'lumotlar xavfsizligini yaxshilaganda

Qaror qabul qilishdan oldin yana bir murakkablikni hisobga olish kerak. Avtomatik sinxronizatsiya ortiqcha uchun yaxshiroq bo'lsa-da, bu ma'lumotlar xavfsizligiga qanday ta'sir qiladi? Albatta, RabbitMQ yaxshi zaxira bilan mavjud xabarlarni yo'qotish ehtimoli kamroq, ammo noshirlarning yangi xabarlari haqida nima deyish mumkin?

Bu erda siz quyidagilarni hisobga olishingiz kerak:

• Nashriyotchi shunchaki xatolik yuz berib, yuqori oqim xizmati yoki foydalanuvchi keyinroq qayta urinib ko‘rishi mumkinmi?
• Nashriyot keyinroq qayta urinib ko‘rish uchun xabarni mahalliy yoki ma’lumotlar bazasida saqlay oladimi?

Agar nashriyotchi faqat xabarni o'chirib qo'yishi mumkin bo'lsa, aslida foydalanish imkoniyatini yaxshilash ham ma'lumotlar xavfsizligini yaxshilaydi.

Shunday qilib, muvozanatni izlash kerak va yechim muayyan vaziyatga bog'liq.

Ha-promote-on-failure=when-sinxronizatsiya bilan bog'liq muammolar

Fikr Ha-muvaffaqiyatsizlikka-rag'batlantirish= sinxronlanganda biz sinxronlashtirilmagan oynaga o'tishni oldini olamiz va shu bilan ma'lumotlar yo'qotilishiga yo'l qo'ymaymiz. Navbat o'qilmaydi yoki yozilmaydi. Buning o'rniga, biz halokatga uchragan brokerni ma'lumotlari saqlanib qolgan holda qayta tiklashga harakat qilamiz, shunda u ma'lumotlarni yo'qotmasdan master sifatida faoliyatini davom ettira oladi.

Ammo (va bu katta, lekin) agar broker o'z ma'lumotlarini yo'qotgan bo'lsa, bizda katta muammo bor: navbat yo'qolgan! Barcha ma'lumotlar yo'qoldi! Agar sizda asosan asosiy navbatga yetadigan ko'zgular bo'lsa ham, bu nometalllar ham bekor qilinadi.

Xuddi shu nomdagi tugunni qayta qo'shish uchun biz klasterga yo'qolgan tugunni unutishini aytamiz (buyruq bilan). rabbitmqctl leave_cluster_node) va bir xil xost nomi bilan yangi brokerni ishga tushiring. Klaster yo'qolgan tugunni eslab qolsa-da, eski navbatni va sinxronlashtirilmagan ko'zgularni eslab qoladi. Klasterga yetim tugunni unutish aytilsa, bu navbat ham unutiladi. Endi biz buni qayta e'lon qilishimiz kerak. Biz barcha ma'lumotlarni yo'qotdik, garchi bizda qisman ma'lumotlar to'plamiga ega oynalar mavjud edi. Sinxronlashtirilmagan oynaga o'tish yaxshiroq bo'lardi!

Shuning uchun, qo'lda sinxronizatsiya (va sinxronizatsiya qilinmasligi) bilan birgalikda ha-promote-on-failure=when-synced, menimcha, juda xavfli. Hujjatlarga ko'ra, bu imkoniyat ma'lumotlar xavfsizligi uchun mavjud, ammo bu ikki qirrali pichoq.

Usta muvozanatni tiklash

Va'da qilinganidek, biz barcha ustalarni bir yoki bir nechta tugunlarda to'plash muammosiga qaytamiz. Bu hatto klasterni yangilash natijasida sodir bo'lishi mumkin. Uch tugunli klasterda barcha asosiy navbatlar bir yoki ikkita tugunlarda to'planadi.

Magistrlarni muvozanatlash ikki sababga ko'ra muammoli bo'lishi mumkin:

• Qayta muvozanatlash uchun yaxshi vositalar yo'q
• Navbatni sinxronlashtirish

Qayta muvozanatlash uchun uchinchi tomon mavjud plagin, bu rasman qo'llab-quvvatlanmaydi. RabbitMQ qo'llanmasida uchinchi tomon plaginlari haqida dedi: “Plagin baʼzi qoʻshimcha konfiguratsiya va hisobot berish vositalarini taqdim etadi, lekin RabbitMQ jamoasi tomonidan qoʻllab-quvvatlanmaydi yoki tasdiqlanmaydi. O'zingizning xavf-xataringiz bilan foydalaning."

HA siyosatlari orqali asosiy navbatni ko'chirishning yana bir hiylasi bor. Qo'llanmada eslatib o'tilgan skript Buning uchun. Bu shunday ishlaydi:

• Mavjud HA siyosatidan ustunroq boʻlgan vaqtinchalik siyosat yordamida barcha koʻzgularni olib tashlaydi.
• Tugun rejimidan foydalanish uchun vaqtinchalik HA siyosatini oʻzgartiradi, asosiy navbat oʻtkazilishi kerak boʻlgan tugunni belgilaydi.
• Pushli migratsiya uchun navbatni sinxronlashtiradi.
• Migratsiya tugallangandan so'ng, vaqtinchalik siyosat o'chiriladi. Dastlabki HA siyosati kuchga kiradi va kerakli ko'zgular soni yaratiladi.

Salbiy tomoni shundaki, agar sizda katta navbatlar yoki qat'iy ortiqcha talablar mavjud bo'lsa, bu yondashuv ishlamasligi mumkin.

Endi RabbitMQ klasterlari tarmoq bo'limlari bilan qanday ishlashini ko'rib chiqamiz.

Ulanishning yo'qolishi

Tarqalgan tizimning tugunlari tarmoq havolalari orqali ulanadi va tarmoq havolalari uzilishi mumkin va uzilishi mumkin. Uzilishlar chastotasi mahalliy infratuzilmaga yoki tanlangan bulutning ishonchliligiga bog'liq. Qanday bo'lmasin, taqsimlangan tizimlar ular bilan kurashishga qodir bo'lishi kerak. Yana bir bor bizda mavjudlik va izchillik o'rtasida tanlov bor va yana yaxshi xabar shundaki, RabbitMQ ikkala variantni ham taqdim etadi (bir vaqtning o'zida emas).

RabbitMQ bilan bizda ikkita asosiy variant mavjud:

• Mantiqiy bo'linishga ruxsat bering (split-miya). Bu mavjudlikni ta'minlaydi, ammo ma'lumotlar yo'qolishiga olib kelishi mumkin.
• Mantiqiy ajratishni o'chiring. Mijozlarning klasterga qanday ulanishiga qarab, qisqa muddatli foydalanish imkoniyati yo'qolishiga olib kelishi mumkin. Ikki tugunli klasterda to'liq mavjud bo'lmasligiga ham olib kelishi mumkin.

Ammo mantiqiy ajratish nima? Bu tarmoq ulanishlarining yo'qolishi tufayli klaster ikkiga bo'linganida. Har tomondan, nometall usta darajasiga ko'tariladi, shuning uchun oxir-oqibat har bir burilishda bir nechta usta bor.

Guruch. 17. Asosiy navbat va ikkita nometall, har biri alohida tugunda. Keyin tarmoqdagi nosozlik yuz beradi va bitta oyna ajratiladi. Ajratilgan tugun qolgan ikkitasi tushib qolganini ko'radi va o'z ko'zgularini ustaga targ'ib qiladi. Endi bizda ikkita asosiy navbat bor, ular yozilishi mumkin va o'qilishi mumkin.

Agar nashriyotlar ikkala ustaga ham ma'lumot yuborsa, biz navbatning ikki xil nusxasini olamiz.

RabbitMQ ning turli rejimlari mavjudlik yoki izchillikni ta'minlaydi.

E'tibor bermaslik rejimi (standart)

Ushbu rejim foydalanish imkoniyatini ta'minlaydi. Ulanish yo'qolganidan keyin mantiqiy ajralish sodir bo'ladi. Ulanish tiklangandan so'ng, administrator qaysi bo'limga ustunlik berishni hal qilishi kerak. Yo'qotilgan tomon qayta ishga tushiriladi va bu tomonda to'plangan barcha ma'lumotlar yo'qoladi.

Guruch. 18. Uchta nashriyot uchta broker bilan bog'langan. Ichkarida, klaster barcha so'rovlarni Broker 2 da asosiy navbatga yo'naltiradi.

Endi biz Broker 3 ni yo'qotmoqdamiz. U boshqa brokerlar tushib qolganini ko'radi va o'z oynasini ustaga ko'rsatadi. Mantiqiy ajralish shunday sodir bo'ladi.

Guruch. 19. Mantiqiy bo'linish (bo'lingan miya). Yozuvlar ikkita asosiy navbatga tushadi va ikkita nusxa bir-biridan farq qiladi.

Ulanish tiklanadi, lekin mantiqiy ajratish qoladi. Administrator yutqazgan tomonni qo'lda tanlashi kerak. Quyidagi holatda administrator Broker 3-ni qayta ishga tushiradi. U uzata olmagan barcha xabarlar yo'qoladi.

Guruch. 20. Administrator Broker 3 ni o'chiradi.

Guruch. 21. Administrator Broker 3 ni ishga tushiradi va u klasterga qo'shiladi va u erda qolgan barcha xabarlarni yo'qotadi.

Ulanishning yo'qolishi paytida va uni qayta tiklashdan so'ng, klaster va bu navbat o'qish va yozish uchun mavjud edi.

Avtomatik davolash rejimi

E'tibor bermaslik rejimiga o'xshash ishlaydi, faqat klasterning o'zi ulanishni ajratish va tiklashdan keyin avtomatik ravishda yo'qotilgan tomonni tanlaydi. Yo'qotilgan tomon klasterga bo'sh qaytadi va navbat faqat o'sha tomonga yuborilgan barcha xabarlarni yo'qotadi.

Ozchilik rejimini pauza qilish

Agar biz mantiqiy bo'linishga ruxsat berishni istamasak, unda bizning yagona variantimiz - klaster bo'limidan keyin kichikroq tomonda o'qish va yozishni bekor qilish. Broker uning kichikroq tomonda ekanligini ko'rgach, u ishni to'xtatadi, ya'ni barcha mavjud ulanishlarni yopadi va yangilarini rad etadi. U soniyada bir marta ulanishni tiklashni tekshiradi. Ulanish qayta tiklangandan so'ng u ishlashni davom ettiradi va klasterga qo'shiladi.

Guruch. 22. Uchta nashriyot uchta broker bilan bog'langan. Ichkarida, klaster barcha so'rovlarni Broker 2 da asosiy navbatga yo'naltiradi.

Broker 1 va 2 keyin Broker 3 dan ajralib chiqadi. Broker 3 o'z oynasini master darajasiga ko'tarish o'rniga, XNUMX-bandni to'xtatib turadi va mavjud bo'lmaydi.

Guruch. 23. Broker 3 pauza qiladi, barcha mijozlarni o'chiradi va ulanish so'rovlarini rad etadi.

Ulanish tiklangandan so'ng u klasterga qaytadi.

Keling, asosiy navbat Broker 3 da joylashgan boshqa misolni ko'rib chiqaylik.

Guruch. 24. Broker 3-da asosiy navbat.

Keyin bir xil ulanish yo'qolishi sodir bo'ladi. Broker 3 pauza qiladi, chunki u kichikroq tomonda. Boshqa tomondan, tugunlar Broker 3 yiqilganini ko'radi, shuning uchun 1 va 2 Brokerlarning eski oynasi master darajasiga ko'tariladi.

Guruch. 25. Broker 2 mavjud bo'lmasa, 3-Brokerga o'tish.

Ulanish tiklanganda, Broker 3 klasterga qo'shiladi.

Guruch. 26. Klaster normal ishlashga qaytdi.

Bu erda tushunish kerak bo'lgan muhim narsa shundaki, biz izchillikka erishamiz, lekin biz mavjudlikni ham olishimiz mumkin, agar Biz mijozlarni bo'limning aksariyat qismiga muvaffaqiyatli o'tkazamiz. Ko'pgina vaziyatlarda men shaxsan ozchilikni to'xtatib turish rejimini tanlagan bo'lardim, lekin bu, albatta, individual holatga bog'liq.

Mavjudligini ta'minlash uchun mijozlar xostga muvaffaqiyatli ulanishini ta'minlash muhimdir. Keling, variantlarimizni ko'rib chiqaylik.

Mijozlarning ulanishini ta'minlash

Ulanish yo'qolganidan keyin mijozlarni klasterning asosiy qismiga yoki ishlaydigan tugunlarga (bitta tugun ishlamay qolgandan keyin) qanday yo'naltirish bo'yicha bizda bir nechta variant mavjud. Birinchidan, eslaylikki, ma'lum bir navbat ma'lum bir tugunda joylashgan, ammo marshrutlash va siyosatlar barcha tugunlarda takrorlanadi. Mijozlar istalgan tugunga ulanishi mumkin va ichki marshrutlash ularni kerakli joyga yo'naltiradi. Ammo tugun to'xtatilganda, u ulanishlarni rad etadi, shuning uchun mijozlar boshqa tugunga ulanishi kerak. Agar tugun tushib qolsa, u umuman qila olmaydi.

Bizning variantlarimiz:

• Klasterga faqat tugunlar bo'ylab aylanadigan yuk balanslagichi yordamida kirish mumkin va mijozlar muvaffaqiyatli bo'lgunga qadar qayta ulanishga harakat qilishadi. Agar tugun ishlamay qolsa yoki to'xtatilgan bo'lsa, ushbu tugunga ulanishga urinishlar muvaffaqiyatsizlikka uchraydi, ammo keyingi urinishlar boshqa serverlarga o'tadi (aylanma rejimda). Bu qisqa muddatli ulanishning yo'qolishi yoki tezda qayta tiklanadigan o'chirilgan server uchun javob beradi.
• Klasterga yuk balanslagichi orqali kiring va to'xtatilgan/muvaffaqiyatsiz tugunlar aniqlangandan so'ng ularni ro'yxatdan olib tashlang. Agar biz buni tezda qilsak va mijozlar ulanishni qaytadan sinab ko'rish imkoniga ega bo'lsak, biz doimiy mavjudlikka erishamiz.
• Har bir mijozga barcha tugunlar ro'yxatini bering va mijoz ulanish vaqtida ulardan birini tasodifiy tanlaydi. Agar ulanishga urinayotganda xatolik yuzaga kelsa, u ulanmaguncha ro'yxatdagi keyingi tugunga o'tadi.
• DNS-dan foydalanib, muvaffaqiyatsiz/to'xtatilgan tugundan trafikni olib tashlang. Bu kichik TTL yordamida amalga oshiriladi.

topilmalar

RabbitMQ klasterining afzalliklari va kamchiliklari mavjud. Eng jiddiy kamchiliklar quyidagilardir:

• klasterga qo'shilishda tugunlar o'z ma'lumotlarini o'chirib tashlaydi;
• sinxronizatsiyani blokirovka qilish navbatning mavjud bo'lmasligiga olib keladi.

Barcha qiyin qarorlar ushbu ikki me'moriy xususiyatdan kelib chiqadi. Agar RabbitMQ klaster qayta ulanganda ma'lumotlarni saqlab qolsa, sinxronizatsiya tezroq bo'lar edi. Agar u bloklanmaydigan sinxronizatsiyaga qodir bo'lsa, u katta navbatlarni qo'llab-quvvatlagani ma'qul. Ushbu ikkita muammoni hal qilish RabbitMQ-ning xatoga chidamli va yuqori darajadagi xabar almashish texnologiyasi sifatida ishlashini sezilarli darajada yaxshilaydi. Quyidagi holatlarda RabbitMQ ni klasterlash bilan tavsiya qilishdan ikkilanaman:

• Ishonchsiz tarmoq.
• Ishonchsiz saqlash.
• Juda uzun navbatlar.

Yuqori mavjudlik sozlamalari haqida gap ketganda, quyidagilarni ko'rib chiqing:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (yoki autoheal)
• doimiy xabarlar
• ba'zi tugun ishlamay qolganda mijozlar faol tugunga ulanishiga ishonch hosil qiling

Muvofiqlik (ma'lumotlar xavfsizligi) uchun quyidagi sozlamalarni ko'rib chiqing:

• Iste'molchi tomonida nashriyot tasdiqlaydi va qo'lda tasdiqlaydi
• ha-promote-on-failure=when-synced, agar noshirlar keyinroq qayta urinib ko'rishlari mumkin bo'lsa va sizda juda ishonchli xotira bo'lsa! Aks holda qo'ying =always.
• ha-sync-mode=automatic (lekin katta nofaol navbatlar uchun qo'lda rejim talab qilinishi mumkin; shuningdek, mavjud bo'lmagani xabarlarning yo'qolishiga olib keladimi yoki yo'qligini ko'rib chiqing)
• Ozchilik rejimini pauza qilish
• doimiy xabarlar

Biz nosozliklarga chidamlilik va yuqori mavjudlik masalalarini hali ko‘rib chiqmaganmiz; masalan, ma'muriy protseduralarni qanday xavfsiz bajarish kerak (masalan, yangilanishlar). Shuningdek, federatsiya va Shovel plagini haqida gapirishimiz kerak.

Agar boshqa biror narsani o'tkazib yuborgan bo'lsam, iltimos, menga xabar bering.

Mening ham qarang post, bu erda men RabbitMQ klasterida Docker va Blockade-dan foydalanib, ushbu maqolada tasvirlangan xabarlarni yo'qotish stsenariylarini sinab ko'raman.

Serialdagi oldingi maqolalar:
№ 1 - habr.com/ru/company/itsumma/blog/416629
№ 2 - habr.com/ru/company/itsumma/blog/418389
№ 3 - habr.com/ru/company/itsumma/blog/437446

Manba: www.habr.com