В oxirgi maqola biz RabbitMQ klasterini xatolarga chidamlilik va yuqori mavjudligi uchun ko'rib chiqdik. Endi keling, Apache Kafkani chuqur qazib olaylik.

Bu erda replikatsiya birligi bo'limdir. Har bir mavzu bir yoki bir nechta bo'limga ega. Har bir bo'limda izdoshlari bo'lgan yoki bo'lmagan etakchi mavjud. Mavzuni yaratishda siz bo'limlar sonini va replikatsiya koeffitsientini belgilaysiz. Odatiy qiymat 3 ga teng, bu uchta replikatsiyani bildiradi: bitta yetakchi va ikkita izdosh.

Guruch. 1. To'rt bo'lim uchta broker o'rtasida taqsimlanadi

Barcha o'qish va yozish so'rovlari rahbarga boradi. Obunachilar vaqti-vaqti bilan etakchiga so'nggi xabarlarni olish uchun so'rov yuboradilar. Iste'molchilar hech qachon izdoshlarga murojaat qilmaydi; ikkinchisi faqat ortiqcha va xatolarga chidamlilik uchun mavjud.

Bo'lim xatosi

Broker muvaffaqiyatsizlikka uchraganida, bir nechta bo'limlarning rahbarlari ko'pincha muvaffaqiyatsizlikka uchraydi. Ularning har birida boshqa tugunning izdoshi yetakchiga aylanadi. Aslida, bu har doim ham shunday emas, chunki sinxronizatsiya omili ham ta'sir qiladi: sinxronlangan izdoshlar bor yoki yo'qmi, agar bo'lmasa, sinxronlashtirilmagan replikaga o'tishga ruxsat beriladimi. Ammo hozircha narsalarni murakkablashtirmaylik.

Broker 3 tarmoqni tark etadi va 2-brokerda 2-bo'limga yangi rahbar saylanadi.

Guruch. 2. Broker 3 vafot etadi va uning 2-brokerdagi izdoshi 2-bo‘limning yangi rahbari etib saylanadi.

Keyin 1-broker ketadi va 1-bo'lim ham o'z rahbarini yo'qotadi, uning roli 2-brokerga o'tadi.

Guruch. 3. Bitta broker qoldi. Barcha yetakchilar bitta brokerda, ortiqcha ortiqcha

Broker 1 onlayn rejimiga qaytganida, u har bir bo'limga biroz ortiqchalikni ta'minlab, to'rtta izdoshni qo'shadi. Ammo barcha rahbarlar hali ham 2-brokerda qolishdi.

Guruch. 4. Liderlar 2-brokerda qoladilar

Broker 3 paydo bo'lganda, biz har bir qism uchun uchta nusxaga qaytamiz. Ammo barcha rahbarlar hali ham broker 2da.

Guruch. 5. 1 va 3-brokerlarni qayta tiklashdan so'ng rahbarlarni muvozanatsiz joylashtirish

Kafkada RabbitMQ ga qaraganda yaxshiroq lider muvozanatini tiklash vositasi mavjud. U erda siz uchinchi tomon plaginini yoki skriptini ishlatishingiz kerak edi, u migratsiya paytida ortiqchalikni kamaytirish orqali asosiy tugunni ko'chirish siyosatini o'zgartirdi. Bundan tashqari, katta navbatlar uchun biz sinxronizatsiya vaqtida mavjud bo'lmasligini qabul qilishimiz kerak edi.

Kafka yetakchi roli uchun “afzal qilingan replikalar” tushunchasiga ega. Mavzu bo'limlari yaratilganda, Kafka yetakchilarni tugunlar bo'ylab teng ravishda taqsimlashga harakat qiladi va o'sha birinchi yetakchilarni afzal deb belgilaydi. Vaqt o'tishi bilan, serverning qayta ishga tushirilishi, nosozliklar va ulanishning uzilishi tufayli, etakchilar yuqorida tavsiflangan ekstremal holatda bo'lgani kabi, boshqa tugunlarga ham tushishi mumkin.

Buni tuzatish uchun Kafka ikkita variantni taklif qiladi:

Variant auto.leader.rebalance.enable=true boshqaruvchi tugunga yetakchilarni afzal qilingan replikalarga avtomatik ravishda qayta tayinlash va shu bilan bir xil taqsimotni tiklash imkonini beradi.
Administrator skriptni ishga tushirishi mumkin kafka-preferred-replica-election.sh qo'lda qayta tayinlash uchun.

Guruch. 6. Qayta muvozanatlashdan keyin nusxalar

Bu muvaffaqiyatsizlikning soddalashtirilgan versiyasi edi, ammo bu erda juda murakkab narsa yo'q bo'lsa-da, haqiqat yanada murakkab. Hammasi sinxronlashtirilgan replikalarga tushadi (In-Sync Replicas, ISR).

Sinxronlashtirilgan replikalar (ISR)

ISR - bu "sinxronlashtirilgan" (sinxronlashtirilgan) deb hisoblangan bo'limning nusxalari to'plami. Rahbar bor, ammo izdoshlari bo'lmasligi mumkin. Agar kuzatuvchi interval tugashidan oldin barcha yetakchi xabarlarining aniq nusxalarini yaratgan bo'lsa, sinxronlangan hisoblanadi. replica.lag.time.max.ms.

Quyidagi hollarda kuzatuvchi ISR to'plamidan olib tashlanadi:

oraliq uchun tanlash so'rovini bermadi replica.lag.time.max.ms (o'lgan deb taxmin qilinadi)
intervalda yangilashga muvaffaq bo'lmadi replica.lag.time.max.ms (sekin deb hisoblanadi)

Kuzatuvchilar intervalda namuna olish so'rovlarini qiladilar replica.fetch.wait.max.ms, sukut bo'yicha 500ms.

ISR maqsadini aniq tushuntirish uchun biz ishlab chiqaruvchining tasdiqlarini va ba'zi muvaffaqiyatsizlik stsenariylarini ko'rib chiqishimiz kerak. Ishlab chiqaruvchilar broker tasdiqlashni qachon yuborishini tanlashi mumkin:

acks=0, tasdiqlash yuborilmadi
acks=1, tasdiqlash rahbar o'zining mahalliy jurnaliga xabar yozgandan so'ng yuboriladi
acks=all, tasdiqlash ISRdagi barcha replikalar xabarni mahalliy jurnallarga yozgandan so'ng yuboriladi

Kafka terminologiyasida, agar ISR xabarni saqlagan bo'lsa, u "majburiy" hisoblanadi. Acks=all - eng xavfsiz variant, ammo qo'shimcha kechikish ham qo'shiladi. Muvaffaqiyatsizlikning ikkita misolini va turli xil "acks" variantlari ISR kontseptsiyasi bilan qanday o'zaro bog'liqligini ko'rib chiqaylik.

Acks=1 va ISR

Ushbu misolda biz ko'ramizki, agar rahbar barcha izdoshlardan kelgan har bir xabarning saqlanishini kutmasa, agar rahbar muvaffaqiyatsizlikka uchrasa, ma'lumotlar yo'qolishi mumkin. Sinxronlanmagan kuzatuvchiga oʻtishni sozlash orqali yoqish yoki oʻchirish mumkin nopok.rahbar.saylov.enable.

Ushbu misolda ishlab chiqaruvchi acks=1 qiymatiga ega. Bo'lim barcha uch broker bo'ylab taqsimlanadi. Broker 3 ortda qoldi, u sakkiz soniya oldin yetakchi bilan sinxronlashtirildi va hozirda 7456 xabar ortda. Broker 1 atigi bir soniya orqada qoldi. Bizning prodyuserimiz lider kutmagan sekin yoki o'lik izdoshlarsiz xabar yuboradi va tezda tasdiq oladi.

Guruch. 7. ISR uchta nusxali

Broker 2 muvaffaqiyatsiz tugadi va ishlab chiqaruvchi ulanish xatosini oladi. Etakchilik 1-brokerga o'tgandan so'ng, biz 123 ta xabarni yo'qotamiz. 1-brokerdagi izdosh ISRning bir qismi edi, lekin u tushib ketganda lider bilan to'liq sinxronlashtirilmadi.

Guruch. 8. Xabarlar ishlamay qolganda yo'qoladi

Konfiguratsiyada bootstrap.servers Ishlab chiqaruvchining ro'yxatga olingan bir nechta brokerlari bor va yangi bo'lim rahbari bo'lgan boshqa brokerni so'rashi mumkin. Keyin u 1-broker bilan aloqa o'rnatadi va xabarlarni jo'natishni davom ettiradi.

Guruch. 9. Xabarlarni yuborish qisqa tanaffusdan keyin davom etadi

Broker 3 bundan ham orqada. U olish soʻrovlarini beradi, lekin sinxronlay olmaydi. Buning sababi brokerlar o'rtasidagi tarmoq ulanishining sustligi, saqlash muammosi va boshqalar bo'lishi mumkin. U ISRdan olib tashlangan. Endi ISR bitta nusxadan iborat - etakchi! Ishlab chiqaruvchi xabarlarni jo'natishda va tasdiqlashlarni olishda davom etmoqda.

Guruch. 10. 3-brokerdagi izdosh ISR dan olib tashlanadi

Broker 1 pastga tushadi va etakchilik roli 3 xabarni yo'qotish bilan 15286-brokerga o'tadi! Ishlab chiqaruvchi ulanish xatosi haqida xabar oladi. ISRdan tashqarida etakchiga o'tish faqat sozlash tufayli mumkin edi unclean.leader.election.enable=true. Agar u o'rnatilgan bo'lsa yolg'on, keyin o'tish sodir bo'lmaydi va barcha o'qish va yozish so'rovlari rad etiladi. Bunday holda, biz 1-broker o'zining buzilmagan ma'lumotlari bilan replikada qaytishini kutamiz, u yana etakchilikni o'z qo'liga oladi.

Guruch. 11. Broker 1 tushadi. Muvaffaqiyatsizlik yuzaga kelganda, ko'p sonli xabarlar yo'qoladi

Ishlab chiqaruvchi oxirgi broker bilan aloqa o'rnatadi va u endi bo'limning rahbari ekanligini ko'radi. U 3-brokerga xabar yuborishni boshlaydi.

Guruch. 12. Qisqa tanaffusdan so'ng xabarlar yana 0-bo'limga yuboriladi

Biz yangi aloqalarni o'rnatish va yangi rahbarni qidirish uchun qisqa uzilishlardan tashqari, ishlab chiqaruvchi doimiy ravishda xabarlar yuborayotganini ko'rdik. Ushbu konfiguratsiya barqarorlik (ma'lumotlar xavfsizligi) hisobiga mavjudligini ta'minlaydi. Kafka minglab xabarlarni yo'qotdi, lekin yangi yozuvlarni qabul qilishda davom etdi.

Acks=all va ISR

Keling, ushbu stsenariyni yana takrorlaymiz, lekin bilan acks=hammasi. Broker 3 o'rtacha to'rt soniya kechikishga ega. Ishlab chiqaruvchi bilan xabar yuboriladi acks=hammasi, va endi tezkor javob ololmaydi. Rahbar xabarni ISRdagi barcha replikalar tomonidan saqlanishini kutadi.

Guruch. 13. Uch nusxali ISR. Ulardan biri sekin, natijada yozib olish kechikishiga olib keladi

To'rt soniya qo'shimcha kechikishdan so'ng, broker 2 ack yuboradi. Barcha nusxalar endi to'liq yangilangan.

Guruch. 14. Barcha nusxalar xabarlarni saqlaydi va ack yuboradi

Broker 3 endi orqada qoladi va ISRdan olib tashlanadi. ISRda sekin replikalar qolmaganligi sababli kechikish sezilarli darajada kamayadi. Broker 2 endi faqat 1-brokerni kutadi va u o'rtacha 500 milodiy kechikishga ega.

Guruch. 15. 3-brokerdagi replika ISRdan olib tashlanadi

Keyin 2-broker tushadi va etakchilik xabarlarni yo'qotmasdan 1-brokerga o'tadi.

Guruch. 16. Broker 2 tushadi

Ishlab chiqaruvchi yangi rahbarni topadi va unga xabarlar yuborishni boshlaydi. Kechikish vaqti yanada kamayadi, chunki ISR endi bitta nusxadan iborat! Shuning uchun variant acks=hammasi ortiqcha qo'shmaydi.

Guruch. 17. 1-brokerdagi replika xabarlarni yo'qotmasdan yetakchilik qiladi

Keyin 1-broker ishdan chiqadi va etakchi 3 xabarni yo'qotgan holda 14238-brokerga o'tadi!

Guruch. 18. Broker 1 o'ladi va nopok sozlamalar bilan etakchilik o'tishi keng ma'lumotlar yo'qotilishiga olib keladi

Variantni oʻrnatolmadik nopok.rahbar.saylov.enable ma'noga kiradi haqiqiy. Odatiy bo'lib, u tengdir yolg'on. Sozlamalar acks=hammasi с unclean.leader.election.enable=true ba'zi qo'shimcha ma'lumotlar xavfsizligi bilan foydalanish imkoniyatini beradi. Ko'rib turganingizdek, biz hali ham xabarlarni yo'qotishimiz mumkin.

Ammo ma'lumotlar xavfsizligini oshirishni xohlasak nima bo'ladi? qo'yishingiz mumkin unclean.leader.election.enable = noto'g'ri, lekin bu bizni ma'lumotlarni yo'qotishdan himoya qilmaydi. Agar rahbar qattiq yiqilib, ma'lumotlarni o'zi bilan olib ketgan bo'lsa, u holda xabarlar hali ham yo'qoladi va administrator vaziyatni tiklamaguncha mavjudlik yo'qoladi.

Barcha xabarlar ortiqcha bo'lishini ta'minlash va aks holda yozuvni bekor qilish yaxshiroqdir. Keyin, hech bo'lmaganda, broker nuqtai nazaridan, ma'lumotlarning yo'qolishi faqat bir vaqtning o'zida ikki yoki undan ortiq nosozliklar yuz bergan taqdirda mumkin.

Acks=all, min.insync.replicas va ISR

Mavzu konfiguratsiyasi bilan min.insync.replicas Biz ma'lumotlar xavfsizligi darajasini oshirmoqdamiz. Oldingi stsenariyning oxirgi qismini yana bir bor ko'rib chiqaylik, lekin bu safar bilan min.insync.replicas=2.

Shunday qilib, 2-broker replika yetakchisiga ega va 3-brokerdagi izdosh ISRdan olib tashlanadi.

Guruch. 19. Ikki nusxadan olingan ISR

Broker 2 tushib ketadi va yetakchilik xabarlarni yo‘qotmasdan 1-brokerga o‘tadi. Ammo endi ISR faqat bitta nusxadan iborat. Bu yozuvlarni qabul qilish uchun minimal raqamga mos kelmaydi va shuning uchun broker yozishga urinishda xato bilan javob beradi NotEnoughReplicas.

Guruch. 20. ISR soni min.insync.replicas da ko'rsatilganidan bitta kam

Ushbu konfiguratsiya barqarorlik uchun mavjudlikni qurbon qiladi. Xabarni tan olishdan oldin biz uning kamida ikkita nusxaga yozilganligiga ishonch hosil qilamiz. Bu ishlab chiqaruvchiga ko'proq ishonch beradi. Bu erda xabarning yo'qolishi, agar xabar qo'shimcha izdoshga takrorlanmaguncha, qisqa vaqt oralig'ida bir vaqtning o'zida ikkita replika ishlamay qolsa, mumkin, bu ehtimoldan yiroq. Ammo agar siz super paranoyak bo'lsangiz, replikatsiya omilini 5 ga o'rnatishingiz mumkin va min.insync.replicas tomonidan 3. Bu yerda uchta broker rekordni yo'qotish uchun bir vaqtning o'zida tushishi kerak! Albatta, siz ushbu ishonchlilik uchun qo'shimcha kechikish vaqtida to'laysiz.

Ma'lumotlar xavfsizligi uchun mavjudlik zarur bo'lganda

Xuddi shunday RabbitMQ bilan ish, ba'zan ma'lumotlar xavfsizligi uchun foydalanish imkoniyati zarur. Bu erda siz nima haqida o'ylashingiz kerak:

Nashriyotchi shunchaki xatoni qaytara oladimi va 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 javob yo'q bo'lsa, mavjudlikni optimallashtirish ma'lumotlar xavfsizligini yaxshilaydi. Yozib olmaslik oʻrniga mavjudlikni tanlasangiz, kamroq maʼlumot yoʻqotasiz. Shunday qilib, barchasi muvozanatni topishga to'g'ri keladi va qaror muayyan vaziyatga bog'liq.

ISRning ma'nosi

ISR to'plami ma'lumotlar xavfsizligi va kechikish o'rtasidagi optimal muvozanatni tanlash imkonini beradi. Masalan, replikalarning ko'pchiligi ishlamay qolganda mavjudligini ta'minlang, kechikish bo'yicha o'lik yoki sekin replikalarning ta'sirini minimallashtiring.

Biz ma'noni o'zimiz tanlaymiz replica.lag.time.max.ms ehtiyojlaringizga ko'ra. Asosan, bu parametr biz qancha kechikishni qachon qabul qilishga tayyorligimizni bildiradi acks=hammasi. Standart qiymat o'n soniya. Agar bu siz uchun juda uzoq bo'lsa, uni qisqartirishingiz mumkin. Keyin ISRdagi o'zgarishlarning chastotasi ortadi, chunki izdoshlar olib tashlanadi va tez-tez qo'shiladi.

RabbitMQ shunchaki takrorlanishi kerak bo'lgan ko'zgular to'plamidir. Sekin oynalar qo'shimcha kechikishlarni keltirib chiqaradi va o'lik nometalllar har bir tugunning mavjudligini tekshiradigan paketlar javob berishini kutishi mumkin. ISR - bu kechikish muammolarini oldini olishning qiziqarli usuli. Ammo biz ortiqchalikni yo'qotish xavfi bor, chunki ISR faqat etakchiga qisqarishi mumkin. Ushbu xavfdan qochish uchun sozlamadan foydalaning min.insync.replicas.

Mijoz ulanishi kafolati

Sozlamalarda bootstrap.servers ishlab chiqaruvchi va iste'molchi mijozlarni ulash uchun bir nechta brokerlarni belgilashi mumkin. G'oya shundan iboratki, bitta tugun tushib ketganda, mijoz ulanishni ochishi mumkin bo'lgan bir nechta zaxiralar qoladi. Bular, albatta, bo'lim rahbarlari emas, balki oddiygina dastlabki yuklash uchun tramplindir. Mijoz ulardan qaysi tugunni o'qish/yozish bo'limi yetakchisi joylashganligini so'rashi mumkin.

RabbitMQ-da mijozlar istalgan tugunga ulanishi mumkin va ichki marshrutlash so'rovni kerakli joyga yuboradi. Bu RabbitMQ oldida yuk balansini o'rnatishingiz mumkinligini anglatadi. Kafka mijozlardan tegishli bo'lim yetakchisi joylashgan tugunga ulanishni talab qiladi. Bunday vaziyatda siz yuk balansini o'rnatolmaysiz. Roʻyxat bootstrap.servers Muvaffaqiyatsizlikdan keyin mijozlar to'g'ri tugunlarga kirishlari va ularni topishlari juda muhimdir.

Kafka konsensus arxitekturasi

Hozirgacha biz klaster brokerning qulashi va yangi rahbar qanday saylanishi haqida qanday bilib olishini ko'rib chiqmadik. Kafka tarmoq bo'limlari bilan qanday ishlashini tushunish uchun avvalo konsensus arxitekturasini tushunishingiz kerak.

Har bir Kafka klasteri Zookeeper klasteri bilan birga joylashtirilgan bo‘lib, u tizimga ma’lum bir holat bo‘yicha konsensusga erishishga imkon beruvchi taqsimlangan konsensus xizmati bo‘lib, mavjudlikdan ko‘ra izchillikni birinchi o‘ringa qo‘yadi. O'qish va yozish operatsiyalarini tasdiqlash uchun Zookeeper tugunlarining ko'pchiligining roziligi talab qilinadi.

Zookeeper klaster holatini saqlaydi:

Mavzular ro'yxati, bo'limlar, konfiguratsiya, joriy yetakchi replikalari, afzal qilingan replikalar.
Klaster a'zolari. Har bir broker Zookeeper klasteriga ping yuboradi. Agar ma'lum vaqt ichida u ping qabul qilmasa, Zookeeper brokerni mavjud emas deb yozadi.
Tekshirish moslamasi uchun asosiy va zaxira tugunlarni tanlash.

Nazoratchi tugun replika yetakchilarini saylash uchun mas'ul bo'lgan Kafka brokerlaridan biridir. Zookeeper kontrollerga klasterga a'zolik va mavzu o'zgarishlari haqida bildirishnomalar yuboradi va nazoratchi bu o'zgarishlar bo'yicha harakat qilishi kerak.

Masalan, o'nta bo'limli va replikatsiya koeffitsienti 3 ga teng bo'lgan yangi mavzuni olaylik. Tekshiruvchi har bir bo'lim uchun yetakchini tanlashi, brokerlar o'rtasida yetakchilarni optimal taqsimlashga harakat qilishi kerak.

Har bir bo'lim boshqaruvchisi uchun:

ISR va yetakchi haqidagi Zookeeper ma'lumotlarini yangilaydi;
Ushbu bo'limning nusxasini o'z ichiga olgan har bir brokerga LeaderAndISRBuyrug'ini yuboradi, bu brokerlarni ISR va yetakchi haqida xabardor qiladi.

Liderli broker yiqilganida, Zookeeper nazoratchiga xabar yuboradi va u yangi rahbarni saylaydi. Shunga qaramay, nazoratchi avval Zookeeper-ni yangilaydi va keyin har bir brokerga rahbariyat o'zgarishi haqida xabar beruvchi buyruq yuboradi.

Har bir rahbar ISRlarni yollash uchun javobgardir. Sozlamalar replica.lag.time.max.ms u erga kim kirishini belgilaydi. ISR o'zgarganda, rahbar yangi ma'lumotlarni Zookeeperga uzatadi.

Hayvonot bog'i boshlig'i har qanday o'zgarishlar haqida doimo xabardor qilinadi, shunda muvaffaqiyatsizlikka uchragan taqdirda rahbariyat muammosiz yangi rahbarga o'tadi.

Guruch. 21. Kafka konsensus

Replikatsiya protokoli

Replikatsiya tafsilotlarini tushunish sizga mumkin bo'lgan ma'lumotlarni yo'qotish stsenariylarini yaxshiroq tushunishga yordam beradi.

Namuna olish so'rovlari, Log End Offset (LEO) va Highwater Mark (HW)

Biz kuzatuvchilar vaqti-vaqti bilan etakchiga olib kelish so'rovlarini yuborishlarini ko'rib chiqdik. Standart interval 500ms. Bu RabbitMQ-dan farqi shundaki, RabbitMQ-da replikatsiya navbat oynasi tomonidan emas, balki master tomonidan boshlanadi. Usta o'zgarishlarni ko'zgularga suradi.

Rahbar va barcha izdoshlar Log End Offset (LEO) va Highwater (HW) yorlig'ini saqlaydi. LEO belgisi oxirgi xabarning ofsetini mahalliy nusxada saqlaydi va HW oxirgi topshiriqning ofsetini saqlaydi. Esda tutingki, topshiriq holati uchun xabar barcha ISR replikalarida saqlanib qolishi kerak. Bu shuni anglatadiki, LEO odatda HW dan biroz oldinda.

Rahbar xabarni qabul qilganda, uni mahalliy sifatida saqlaydi. Kuzatuvchi o'zining LEO-ni yuborish orqali olib kelish so'rovini beradi. Keyin rahbar ushbu LEO dan boshlab xabarlar to'plamini yuboradi va joriy HW ni ham uzatadi. Rahbar barcha replikatsiyalar xabarni berilgan ofsetda saqlaganligi haqida ma'lumot olganda, u HW belgisini siljitadi. Faqat rahbar HWni ko'chirishi mumkin va shuning uchun barcha izdoshlar o'zlarining so'rovlariga javoblardagi joriy qiymatni bilishadi. Bu shuni anglatadiki, izdoshlar xabarda ham, HW bilimida ham liderdan orqada qolishi mumkin. Iste'molchilar xabarlarni faqat joriy HWgacha qabul qilishadi.

E'tibor bering, "doimiy" diskka emas, balki xotiraga yozilgan degan ma'noni anglatadi. Ishlash uchun Kafka ma'lum bir vaqt oralig'ida disk bilan sinxronlashtiriladi. RabbitMQ ham shunday intervalga ega, lekin u xabarni master va barcha oynalar diskka yozgandan keyingina nashriyotga tasdiqnoma yuboradi. Kafka ishlab chiquvchilari, ishlash sabablariga ko'ra, xabar xotiraga yozilishi bilanoq ack yuborishga qaror qilishdi. Kafka ortiqchalik tan olingan xabarlarni faqat xotirada qisqa muddatga saqlash xavfini qoplaydi.

Rahbarning muvaffaqiyatsizligi

Lider yiqilganda, Zookeeper boshqaruvchiga xabar beradi va u yangi yetakchi replikasini tanlaydi. Yangi rahbar o'zining LEO bo'yicha yangi HW belgisini o'rnatadi. Keyin izdoshlar yangi rahbar haqida ma'lumot olishadi. Kafka versiyasiga qarab, izdosh ikkita stsenariydan birini tanlaydi:

U mahalliy jurnalni ma'lum HWga qisqartiradi va yangi rahbarga ushbu belgidan keyin xabarlar uchun so'rov yuboradi.
Rahbarga rahbar etib saylangan paytdagi HWni bilish uchun so'rov yuboradi va keyin jurnalni ushbu ofsetga qisqartiradi. Keyin u ushbu ofsetdan boshlab davriy olib kelish so'rovlarini qila boshlaydi.

Quyidagi sabablarga ko'ra kuzatuvchi jurnalni kesishi kerak bo'lishi mumkin:

Rahbar muvaffaqiyatsizlikka uchraganida, Zookeeperda ro'yxatdan o'tgan ISR to'plamidagi birinchi izdoshi saylovda g'alaba qozonadi va yetakchiga aylanadi. ISRdagi barcha izdoshlar, garchi "sinxronlashtirilgan" deb hisoblansa ham, sobiq rahbardan barcha xabarlarning nusxalarini olmagan bo'lishi mumkin. Taqdim etilgan izdoshda eng so'nggi nusxasi bo'lmasligi mumkin. Kafka replikalar o'rtasida farq yo'qligini ta'minlaydi. Shunday qilib, nomuvofiqliklarni oldini olish uchun har bir izdosh o'z jurnalini yangi rahbarning saylanish vaqtidagi HW qiymatiga qisqartirishi kerak. Bu sozlashning yana bir sababi acks=hammasi izchillik uchun juda muhimdir.
Xabarlar vaqti-vaqti bilan diskka yoziladi. Agar barcha klaster tugunlari bir vaqtning o'zida ishlamay qolsa, unda turli xil ofsetlarga ega replikalar disklarda saqlanadi. Brokerlar internetga qaytganlarida, saylangan yangi rahbar o'z izdoshlarining orqasida bo'lishi mumkin, chunki u boshqalardan oldin diskda saqlangan.

Klaster bilan uchrashuv

Klasterga qayta qo'shilganda, replikalar yetakchi muvaffaqiyatsizlikka uchragandek bajaradi: ular yetakchining nusxasini tekshiradi va jurnalini uning HW ga (saylov vaqtida) qisqartiradi. Taqqoslash uchun, RabbitMQ qayta birlashtirilgan tugunlarni mutlaqo yangi deb hisoblaydi. Ikkala holatda ham broker mavjud holatni bekor qiladi. Agar avtomatik sinxronizatsiya ishlatilsa, usta "butun dunyo kutsin" usulida yangi oynaga mutlaqo barcha joriy tarkibni takrorlashi kerak. Ushbu operatsiya davomida master hech qanday o'qish yoki yozish operatsiyalarini qabul qilmaydi. Bunday yondashuv katta navbatlarda muammolarni keltirib chiqaradi.

Kafka taqsimlangan jurnal bo'lib, umuman olganda, u RabbitMQ navbatiga qaraganda ko'proq xabarlarni saqlaydi, bu erda ma'lumotlar o'qilgandan keyin navbatdan olib tashlanadi. Faol navbatlar nisbatan kichik bo'lib qolishi kerak. Ammo Kafka o'zining saqlash siyosatiga ega jurnal bo'lib, u kunlar yoki haftalar davrini belgilashi mumkin. Navbatni blokirovka qilish va to'liq sinxronizatsiya yondashuvi taqsimlangan jurnal uchun mutlaqo qabul qilinishi mumkin emas. Buning o'rniga, Kafka izdoshlari, agar ularning nusxasi yetakchidan oldinda bo'lsa, o'z jurnalini liderning HW ga (u saylanganda) qisqartiradi. Ko'proq ehtimoliy holatda, izdosh orqada qolganda, u hozirgi LEO dan boshlab olib kelish so'rovlarini qila boshlaydi.

Yangi yoki qayta qo'shilgan izdoshlar ISRdan tashqarida boshlanadi va majburiyatlarda qatnashmaydi. Ular shunchaki guruh bilan birga ishlaydilar, ular yetakchiga yetib borguncha va ISR ga kirguniga qadar imkon qadar tezroq xabarlarni oladilar. Hech qanday qulf yo'q va barcha ma'lumotlarni tashlab yuborishning hojati yo'q.

Ulanishning yo'qolishi

Kafka RabbitMQ ga qaraganda ko'proq komponentlarga ega, shuning uchun klaster uzilib qolganda u yanada murakkab xatti-harakatlar to'plamiga ega. Ammo Kafka dastlab klasterlar uchun mo'ljallangan, shuning uchun echimlar juda yaxshi o'ylangan.

Quyida bir nechta ulanishning buzilishi stsenariylari keltirilgan:

1-stsenariy: Izdosh yetakchini ko‘rmaydi, lekin hayvonot bog‘i boshlig‘ini ko‘radi.
2-stsenariy: Rahbar hech qanday izdoshlarni ko'rmaydi, lekin baribir Zookeeperni ko'radi.
3-stsenariy: Izdosh yetakchini ko‘radi, lekin hayvonot bog‘i boshlig‘ini ko‘rmaydi.
4-stsenariy: Rahbar izdoshlarni ko'radi, lekin hayvonot bog'i boshlig'ini ko'rmaydi.
Stsenariy 5: Izdosh boshqa Kafka tugunlaridan ham, Zookeeperdan ham butunlay alohida.
Stsenariy 6: Lider boshqa Kafka tugunlaridan ham, Zookeeperdan ham butunlay ajratilgan.
Stsenariy 7: Kafka boshqaruvchi tuguni boshqa Kafka tugunini ko'ra olmaydi.
Stsenariy 8: Kafka boshqaruvchisi Zookeeperni ko'rmaydi.

Har bir stsenariyning o'ziga xos xatti-harakati bor.

1-stsenariy: Obunachi yetakchini ko‘rmaydi, lekin Zookeeperni ko‘radi

Guruch. 22. 1-stsenariy: uchta nusxaning ISR

Ulanishdagi nosozlik 3-brokerni 1 va 2-brokerlardan ajratadi, lekin Zookeeper-dan emas. Broker 3 endi olish so‘rovlarini yubora olmaydi. Vaqt o'tgandan keyin replica.lag.time.max.ms u ISRdan o'chiriladi va xabarlarni qabul qilishda qatnashmaydi. Ulanish tiklangandan so‘ng, u so‘rovlarni olishni davom ettiradi va yetakchiga yetib kelganida ISRga qo‘shiladi. Zookeeper pinglarni olishda davom etadi va broker tirik va yaxshi deb taxmin qiladi.

Guruch. 23. 1-stsenariy: Agar broker replica.lag.time.max.ms oralig'ida olib kelish so'rovi olinmasa, ISRdan o'chiriladi.

RabbitMQ-dagi kabi split-miya yoki tugun suspenziyasi mavjud emas. Buning o'rniga, ortiqcha ish kamayadi.

2-stsenariy: Rahbar hech qanday izdoshlarni ko'rmaydi, lekin baribir Zookeeperni ko'radi

Guruch. 24. Stsenariy 2. Rahbar va ikkita izdosh

Tarmoqqa ulanishning buzilishi liderni izdoshlardan ajratib turadi, ammo broker Zookeeperni ko'rishi mumkin. Birinchi stsenariyda bo'lgani kabi, ISR qisqaradi, lekin bu safar faqat etakchiga tushadi, chunki barcha izdoshlar olish so'rovlarini yuborishni to'xtatadilar. Shunga qaramay, mantiqiy bo'linish yo'q. Buning o'rniga, ulanish tiklanmaguncha yangi xabarlar uchun ortiqcha yo'qotish mavjud. Zookeeper pinglarni olishda davom etmoqda va broker tirik va yaxshi ekanligiga ishonadi.

Guruch. 25. Stsenariy 2. ISR faqat yetakchiga qisqardi

Stsenariy 3. Izdosh yetakchini ko‘radi, lekin hayvonot bog‘i boshlig‘ini ko‘rmaydi

Izdosh Zookeeperdan ajratiladi, lekin yetakchi bilan brokerdan emas. Natijada, izdosh olish so'rovlarini berishda va ISR a'zosi bo'lishda davom etadi. Zookeeper endi pinglarni qabul qilmaydi va broker halokatini qayd etmaydi, lekin u faqat izdosh bo'lgani uchun tiklanishdan keyin hech qanday oqibatlar bo'lmaydi.

Guruch. 26. 3-stsenariy: kuzatuvchi yetakchiga olib kelish so‘rovlarini yuborishda davom etadi

Stsenariy 4. Rahbar izdoshlarni ko'radi, lekin Zookeeperni ko'rmaydi

Guruch. 27. Stsenariy 4. Rahbar va ikkita izdosh

Rahbar Zookeeperdan ajratilgan, ammo izdoshlari bo'lgan brokerlardan emas.

Guruch. 28. 4-stsenariy: Zookeperdan ajratilgan rahbar

Biroz vaqt o'tgach, Zookeeper broker xatosini qayd qiladi va bu haqda boshqaruvchiga xabar beradi. U izdoshlari orasidan yangi rahbarni tanlaydi. Biroq, asl rahbar o'zini etakchi deb o'ylashda davom etadi va kirishlarni qabul qilishni davom ettiradi acks=1. Obunachilar endi unga olib kelish so'rovlarini yuborishmayapti, shuning uchun u ularni o'lik deb hisoblaydi va ISRni o'ziga qisqartirishga harakat qiladi. Ammo Zookeeper bilan aloqasi yo'qligi sababli, u buni amalga oshira olmaydi va o'sha paytda boshqa yozuvlarni qabul qilishdan bosh tortadi.

xabarlar acks=hammasi tasdiqlashni olmaydi, chunki ISR birinchi navbatda barcha replikalarni yoqadi va xabarlar ularga etib bormaydi. Dastlabki rahbar ularni ISRdan olib tashlashga harakat qilganda, u buni qila olmaydi va hech qanday xabarlarni qabul qilishni to'xtatadi.

Mijozlar tez orada etakchining o'zgarishini sezadilar va yozuvlarni yangi serverga yuborishni boshlaydilar. Tarmoq qayta tiklangandan so'ng, boshlang'ich lider u endi yetakchi emasligini ko'radi va jurnalni farqlashning oldini olish uchun yangi rahbar muvaffaqiyatsizlik vaqtidagi HW qiymatiga qisqartiradi. Keyin u yangi rahbarga olib kelish so'rovlarini yuborishni boshlaydi. Dastlabki rahbardan yangi rahbarga takrorlanmagan barcha yozuvlar yo'qoladi. Ya'ni, ikki rahbar ishlayotgan bir necha soniya ichida dastlabki rahbar tomonidan tan olinmagan xabarlar yo'qoladi.

Guruch. 29. Stsenariy 4. 1-brokerdagi lider tarmoq tiklanganidan keyin izdoshga aylanadi.

Stsenariy 5: Izdosh boshqa Kafka tugunlaridan ham, Zookeeperdan ham butunlay alohida

Izdosh boshqa Kafka tugunlaridan ham, Zookeeperdan ham butunlay ajratilgan. U tarmoq tiklanmaguncha o'zini ISRdan olib tashlaydi, keyin esa boshqalarga yetib oladi.

Guruch. 30. Stsenariy 5: Izolyatsiya qilingan izdosh ISR dan olib tashlanadi

Stsenariy 6: Lider boshqa Kafka tugunlaridan ham, Zookeeperdan ham butunlay ajralib turadi

Guruch. 31. Stsenariy 6. Rahbar va ikkita izdosh

Rahbar o'z izdoshlaridan, boshqaruvchi va hayvonot bog'i xodimidan butunlay ajratilgan. Qisqa vaqt ichida u arizalarni qabul qilishni davom ettiradi acks=1.

Guruch. 32. Stsenariy 6: Liderni boshqa Kafka va Zookeeper tugunlaridan ajratish

Muddati tugaganidan keyin so'rovlar qabul qilinmagan replica.lag.time.max.ms, u ISRni o'ziga qisqartirishga harakat qiladi, lekin Zookeeper bilan aloqa yo'qligi sababli buni qila olmaydi, keyin u yozishni qabul qilishni to'xtatadi.

Shu bilan birga, Zookeeper izolyatsiya qilingan brokerni o'lik deb belgilaydi va nazoratchi yangi rahbarni saylaydi.

Guruch. 33. Stsenariy 6. Ikki rahbar

Asl rahbar bir necha soniya davomida arizalarni qabul qilishi mumkin, ammo keyin har qanday xabarlarni qabul qilishni to'xtatadi. Mijozlar har 60 soniyada so'nggi metama'lumotlar bilan yangilanadi. Ular rahbarning o'zgarishi haqida xabardor qilinadi va yangi rahbarga arizalar yuborishni boshlaydi.

Guruch. 34. Stsenariy 6: Ishlab chiqaruvchilar yangi rahbarga o'tadilar

Ulanish yo'qolganidan beri dastlabki rahbar tomonidan kiritilgan barcha tasdiqlangan yozuvlar yo'qoladi. Tarmoq qayta tiklangach, asl yetakchi Zookeeper orqali u endi yetakchi emasligini aniqlaydi. Keyin u o'z jurnalini saylov paytida yangi rahbarning HW-ga qisqartiradi va izdosh sifatida so'rovlar yuborishni boshlaydi.

Guruch. 35. Stsenariy 6: Asl yetakchi tarmoq ulanishi tiklangandan keyin izdoshga aylanadi

Bunday holatda, mantiqiy ajralish qisqa vaqt ichida sodir bo'lishi mumkin, ammo faqat agar acks=1 и min.insync.replicas shuningdek 1. Mantiqiy ajralish yo tarmoq tiklangandan so‘ng, asl yetakchi o‘zining yetakchi emasligini anglaganda yoki barcha mijozlar yetakchi o‘zgarganini anglab, yangi rahbarga yozishni boshlaganda – qaysi biri birinchi bo‘lib sodir bo‘lsa, avtomatik ravishda tugaydi. Har holda, ba'zi xabarlar yo'qoladi, lekin faqat bilan acks=1.

Ushbu stsenariyning yana bir varianti mavjud bo'lib, tarmoq bo'linishidan oldin, izdoshlar ortda qolib ketishdi va lider ISRni faqat o'ziga siqib qo'ydi. Keyin ulanishning yo'qolishi sababli izolyatsiyalanadi. Yangi rahbar saylanadi, lekin asl yetakchi hattoki arizalarni qabul qilishda davom etadi acks=hammasi, chunki ISRda undan boshqa hech kim yo'q. Tarmoq qayta tiklangandan keyin bu yozuvlar yo'qoladi. Ushbu variantdan qochishning yagona yo'li min.insync.replicas = 2.

Stsenariy 7: Kafka boshqaruvchi tugun boshqa Kafka tugunini ko‘ra olmaydi

Umuman olganda, Kafka tugunlari bilan aloqa uzilgandan so'ng, boshqaruvchi unga rahbar o'zgarishi haqidagi ma'lumotlarni uzata olmaydi. Eng yomon holatda, bu 6-stsenariyda bo'lgani kabi, qisqa muddatli mantiqiy ajralishga olib keladi. Ko'pincha, broker, agar ikkinchisi muvaffaqiyatsiz bo'lsa, etakchilikka nomzod bo'lib qolmaydi.

Stsenariy 8: Kafka boshqaruvchisi Zookeeperni ko'rmaydi

Zookeeper yiqilgan kontrollerdan ping qabul qilmaydi va boshqaruvchi sifatida yangi Kafka tugunini tanlaydi. Asl boshqaruvchi o'zini shunday ko'rsatishda davom etishi mumkin, lekin u Zookeeperdan bildirishnomalarni olmaydi, shuning uchun u bajaradigan hech qanday vazifaga ega bo'lmaydi. Tarmoq qayta tiklangach, u endi boshqaruvchi emasligini, balki oddiy Kafka tuguniga aylanganini tushunadi.

Stsenariylardan xulosalar

Biz kuzatuvchilar ulanishining yo'qolishi xabarning yo'qolishiga olib kelmasligini, balki tarmoq qayta tiklanmaguncha ortiqcha miqdorni vaqtincha qisqartirishini ko'ramiz. Bu, albatta, agar bir yoki bir nechta tugun yo'qolsa, ma'lumotlar yo'qolishiga olib kelishi mumkin.

Agar yetakchi aloqa uzilishi tufayli Zookeeperdan ajralsa, bu xabarlarning yo‘qolishiga olib kelishi mumkin. acks=1. Zookeeper bilan aloqaning yo'qligi ikki rahbar bilan qisqa mantiqiy bo'linishga olib keladi. Ushbu muammo parametr yordamida hal qilinadi acks=hammasi.

Parametr min.insync.replicas Ikki yoki undan ortiq replikatsiyalar bunday qisqa muddatli stsenariylar 6-stsenariyda bo'lgani kabi yo'qolgan xabarlarga olib kelmasligiga qo'shimcha kafolat beradi.

Yo'qotilgan xabarlarning qisqacha mazmuni

Keling, Kafkada ma'lumotlarni yo'qotishning barcha usullarini sanab o'tamiz:

Agar xabarlar yordamida tasdiqlangan bo'lsa, har qanday etakchining muvaffaqiyatsizligi acks=1
Etakchilikning har qanday nopok o'tishi, ya'ni ISRdan tashqaridagi izdoshga, hatto bilan acks=hammasi
Agar xabarlar yordamida tasdiqlangan bo'lsa, rahbarni Zookeeperdan ajratish acks=1
ISR guruhini allaqachon o'ziga qisqartirgan liderni to'liq izolyatsiya qilish. Barcha xabarlar yo'qoladi, hatto acks=hammasi. Bu faqat to'g'ri bo'lsa min.insync.replicas=1.
Barcha bo'lim tugunlarining bir vaqtning o'zida ishlamay qolishi. Xabarlar xotiradan qabul qilinganligi sababli, ba'zilari hali diskka yozilmagan bo'lishi mumkin. Serverlarni qayta ishga tushirgandan so'ng, ba'zi xabarlar etishmayotgan bo'lishi mumkin.

Rahbarlarning nopok o'tishlarini taqiqlash yoki kamida ikkita ishdan bo'shatishni ta'minlash orqali oldini olish mumkin. Eng bardoshli konfiguratsiya kombinatsiyadir acks=hammasi и min.insync.replicas 1 dan ortiq.

RabbitMQ va Kafka ishonchliligini to'g'ridan-to'g'ri taqqoslash

Ishonchliligi va yuqori mavjudligini ta'minlash uchun ikkala platforma ham birlamchi va ikkilamchi replikatsiya tizimini amalga oshiradi. Biroq, RabbitMQ Axilles tovoniga ega. Muvaffaqiyatsizlikdan keyin qayta ulanishda tugunlar o'z ma'lumotlarini o'chirib tashlaydi va sinxronizatsiya bloklanadi. Bu qo‘shaloqlik RabbitMQ-da katta navbatlarning uzoq umr ko‘rishini shubha ostiga qo‘yadi. Siz qisqartirilgan ortiqcha yoki uzoq blokirovka vaqtlarini qabul qilishingiz kerak bo'ladi. Ortiqchalikni kamaytirish katta hajmdagi ma'lumotlarni yo'qotish xavfini oshiradi. Ammo, agar navbatlar kichik bo'lsa, ortiqcha bo'lish uchun, qisqa vaqt ichida mavjud bo'lmaslik (bir necha soniya) takroriy ulanish urinishlari yordamida hal qilinishi mumkin.

Kafkada bunday muammo yo'q. U ma'lumotlarni faqat rahbar va izdosh o'rtasidagi tafovut nuqtasidan olib tashlaydi. Barcha umumiy ma'lumotlar saqlanadi. Bundan tashqari, replikatsiya tizimni bloklamaydi. Yangi izdosh yetib kelganda, rahbar postlarni qabul qilishda davom etadi, shuning uchun devoplar uchun klasterga qo'shilish yoki qayta qo'shilish ahamiyatsiz vazifaga aylanadi. Albatta, replikatsiya paytida tarmoq tarmoqli kengligi kabi muammolar hali ham mavjud. Agar siz bir vaqtning o'zida bir nechta izdoshlarni qo'shsangiz, tarmoqli kengligi chegarasiga duch kelishingiz mumkin.

Klasterdagi bir nechta serverlar bir vaqtning o'zida ishlamay qolganda RabbitMQ ishonchliligi bo'yicha Kafkadan ustundir. Yuqorida aytib o'tganimizdek, RabbitMQ xabarni master va barcha oynalar tomonidan diskka yozgandan keyingina nashriyotga tasdiqlashni yuboradi. Ammo bu ikki sababga ko'ra qo'shimcha kechikishni qo'shadi:

fsync har bir necha yuz millisekundda
Ko'zguning ishdan chiqishini faqat har bir tugunning mavjudligini tekshiradigan paketlarning ishlash muddati (to'r belgisi) tugaganidan keyin sezilishi mumkin. Agar oyna sekinlashsa yoki tushib qolsa, bu kechikishni qo'shadi.

Kafkaning garovi shundan iboratki, agar xabar bir nechta tugunlarda saqlansa, u xabarlarni xotiraga tushishi bilanoq tan oladi. Shu sababli, har qanday turdagi xabarlarni yo'qotish xavfi mavjud (hatto acks=hammasi, min.insync.replicas=2) bir vaqtning o'zida ishlamay qolganda.

Umuman olganda, Kafka dasturiy ta'minotning yaxshi ishlashini namoyish etadi va boshidanoq klasterlar uchun mo'ljallangan. Ishonchlilik uchun kerak bo'lsa, izdoshlar soni 11 tagacha oshirilishi mumkin. Replikatsiya omili 5 va sinxronizatsiyadagi replikalarning minimal soni min.insync.replicas=3 xabarni yo'qotish juda kam uchraydigan hodisaga aylanadi. Agar sizning infratuzilmangiz ushbu replikatsiya nisbati va ortiqchalik darajasini qo'llab-quvvatlasa, siz ushbu variantni tanlashingiz mumkin.

RabbitMQ klasteri kichik navbatlar uchun yaxshi. Ammo tirbandlik bo'lsa, hatto kichik navbatlar ham tez o'sishi mumkin. Navbatlar kattalashganidan keyin siz mavjudlik va ishonchlilik o'rtasida qiyin tanlov qilishingiz kerak bo'ladi. RabbitMQ klasteri odatiy bo'lmagan holatlar uchun eng mos keladi, bu erda RabbitMQ moslashuvchanligining afzalliklari uning klasterlashning har qanday kamchiliklaridan ustun turadi.

RabbitMQ ning katta navbatlarga nisbatan zaifligiga qarshi davolardan biri ularni kichikroq navbatlarga bo'lishdir. Agar siz butun navbatni to'liq buyurtma qilishni talab qilmasangiz, faqat tegishli xabarlarni (masalan, ma'lum bir mijozdan kelgan xabarlar) yoki umuman buyurtma qilmasangiz, unda bu variant maqbuldir: mening loyihamga qarang. Qayta muvozanatlashtiruvchi navbatni ajratish uchun (loyiha hali boshlang'ich bosqichda).

Va nihoyat, RabbitMQ va Kafkaning klasterlash va replikatsiya mexanizmlaridagi bir qator xatolar haqida unutmang. Vaqt o'tishi bilan tizimlar yanada etuk va barqaror bo'ldi, ammo hech qanday xabar yo'qotishdan 100% xavfsiz bo'lmaydi! Bundan tashqari, ma'lumotlar markazlarida katta hajmdagi baxtsiz hodisalar sodir bo'ladi!

Agar men biror narsani o'tkazib yuborgan bo'lsam, xatoga yo'l qo'ygan bo'lsam yoki biron bir fikrga qo'shilmasangiz, sharh yozing yoki men bilan bog'laning.

Mendan tez-tez so'rashadi: "Nima tanlash kerak, Kafka yoki RabbitMQ?", "Qaysi platforma yaxshiroq?". Haqiqat shundaki, bu haqiqatan ham sizning vaziyatingizga, joriy tajribangizga va hokazolarga bog'liq. Men o'z fikrimni bildirishga ikkilanyapman, chunki barcha foydalanish holatlari va mumkin bo'lgan cheklovlar uchun bitta platformani tavsiya qilish haddan tashqari soddalashtirish bo'ladi. Men ushbu maqolalar turkumini siz o'z fikringizni shakllantirishingiz uchun yozdim.

Aytmoqchimanki, ikkala tizim ham bu sohada yetakchi hisoblanadi. Men bir oz noxolis bo'lishim mumkin, chunki loyihalardagi tajribamdan men kafolatlangan xabarlarni buyurtma qilish va ishonchlilik kabi narsalarni qadrlayman.

Men bunday ishonchlilik va kafolatlangan buyurtmaga ega bo'lmagan boshqa texnologiyalarni ko'raman, keyin RabbitMQ va Kafkaga qarayman va bu ikkala tizimning ajoyib qiymatini tushunaman.

Manba: www.habr.com

RabbitMQ va Kafka: xatolarga chidamlilik va yuqori mavjudlik