Message Queue nima va nimaga kerak? Producer, consumer, broker
Assalamu Alaykum bugun distributed sistemalarda message queuelar nimaga kerakligini va uni foyda hamda zararlarini ko’rib chiqamiz.
Message queuedan oldin asinxronizm haqida biroz tushunishimiz kerak.
Asynchronism
Asinxronzim bu ko’p vaqt oladigan so’rov vaqtini kamaytirishga yoki o’sha vaqtda qilishni oldini olishga yordam beradi. Bu uni oldindan process qilish orqali bo’lishi mumkin . Oddiy qilib aytganda so’rov natijasini siz tezda hoziroq olmasligingiz mumkin va bu siz uchun okay.
Queuelar hamma joyda bor Operatsion sistema bu threadpool va keladigan vazifalar ko’rinishida , tarmoqda esa uzatilayotgan packetlar qabul qilish darjasiga qarab uzatilishi va qolganlari kutib turishida , distributed sistemada esa hozir aytganimizdek message queue asinxronizm uchun kerak va ularning hammasi bir mantiq ustiga qurilgan.
Message queue nima ?
Hozir message queue g’oyasini tushuntirishga harakat qilaman . Servislar bir birini to’g’ridan to’g’ri chaqirsa va kutsa , chaqiruvchi javob beruvchi servis tezligicha tez va ishonchliligicha ishonchli bo’ladi . Agar u sekin bo’lsa demak chaqiruvchi servis ham sekin tuyuladi . Queuelar bularning orasida turib servislar orasidagi bog’liqlikni olib tashlaydi va chaqiruvchi servis endi tezda men vazifani keyingi servisga berdim deya javob qaytaradi.
Queue bu yerda ikki servis o’rtasida so’rovlar uchun buffer vazifasini (ikkinchi servis qulasa ham queue unga so’rovlarni qabul qiladi va u qayta ishga tushganda bularni process qiliadi ) o’z zimmasiga oladi . Bu sistemaga birdaniga kuchaygan yuklamani queueda saqlab qolishga va xatoliklarni qayta urinib ko’rishga , workerlarni alohida kengaytirishga yordam beradi. Bundan tashqari oldingi maqolada aytganimizdek to’g’ridan to’g’ri chaqiruvda( bir servisdagi so’rov ko’p vaqt olishi timeoutga olib keladi. Masalan rasm yuklash bu jarayonda rasm yuklanadi va foydalanuvchiga ko’rsatiladi ammo orqa tarafda uni kichraytirish va har xil turlarga o’girish amalga oshadi. Bu to’g’ridan to’g’ri chaqiruvda bittasi xato ketishi hammasini to’xtatadi . Message queue esa bizga fault tolerance va chidamlilikni beradi va har bir qisma alohida qayta urinish mumkin .
Queuelar pull yoki push uslubida bo’ladi . Pullda consumer kelib yangilikni olib ketadi va Pushda broker yangi xabarlarni consumerga yetkazadi.
Asinxronizm va message queue haqida bildik endi Message queue ishlatish turlarini va ular nimaga kerakligini ko’rib chiqamiz :
Message queues
Message queue xabarni qabul qiladi ushlab turadi va yetkazib beradi. Agarda operatsiya juda sekin amalga oshsa message queueni ushbu workflow bo’yicha ishlatishingiz mumkin :
Dastur queuega xabarni yuboradi va foydalanuvchiga xabar holati haqida bildiradi
Worker keyinchalik u xabarni olib , process qiladi va u tugatilganligi haqida xabar beradi.
Bu holatda foydalanuvchi. boshqa ishlar qilishdan bloklanmagan va berilgan vazifa orqa tarafda amalga oshaveradi . Bu vaqtda bazan foydalanuvchi biroz process operatsiya qilishi mumkin masalan maqola chop etildi va u sizning (muallifning) ro’yxatida chiqadi ammo hamma kuzatuvchilaringizga hali yetib bormagan bo’lishi mumkin.
Task queuelar
Task queuelar vazifa va unga aloqador ma’lumotlarni qabul qiladi , ishga tushurib natijani qaytaradi . Ular ma’lum bir vaqtga rejalashtirishni ham qo’llab quvvatlaydi va CPU intensive vazifalarni orqa tarafda ishlatishga yodam beradi.
Celery bu uchun misol bo’lishi mumkin va unda Python uchun support bor.
Message queueni asosiy qismlari
Producer
Producer xabarlarni yartadi va queuega yuboradi, producer qaysi consumer buni process qilishini bilishi shart emas yoki uni hozir ishlayotganini.
Misollar : Upload servis, checkout servis
Consumer
Consumer xabarni qabul qiladi va ishni amalga oshiradi. Bir necha consumerlar bir queuedan bir vaqtda o’qishi mumkin.
Misollar: email worker, image processor , payment worker
Message (xabar)
Xabar bu queue orqali yuborilga ish. Va u odatda bularni o’z ichiga oladi :
Payload (biznesga aloqador ma’lumotlar) bu ishni amalga oshirish uchun kerak
Metadata — bu qo’shimcha xabar ma’lumotlari (id, qachon yuborilgan track qilish uchun id va qayta urinish soni)
Xabar iloji boricha kichkina va aniq bo’lishi kerak hamda versiyalangan (o’zgarishlarni bilish uchun) . Katta fayllar object storageda saqlanadi va queue xabarlar fayl linkini o’zida olib boradi to’liq faylni emas.
Queue
Queue consumer xabarni process qilguncha saqlab turadi. Tanlangan sistemaga qarab u navbatni saqlashi , muhimlilikni qo’llab quvvatlashi va xabarni o’qilgandan keyin saqlashi yoki o’chirib yuborishi mumkin.
Broker
Broker bu queueda saqlash va uni yetkazib berish sistemasi. U producerlardan message qabul qiladi, saqlaydi, consumerlarga yetkazib beradi , acknowledmentlarni tekshirib boradi va boshqa qoidalarni qo’llab turadi masalan, qayta urinish , xabar qancha saqlanishi kerak va dead lettering .
Bunda misol RabbitMQ, Amazon SQS, Google Cloud Pub/Sub, Azure Service Bus va Redis Streams . Kafka odatiy brokerdan boshqacharoq ishlaydi .
Xabarlarni yo’qotmaslik — u qanday ishlaydi ?
Xabarlarni yo’qotib qo’ymaslik uchun biz ularni haqiqatda yetib borganini bilishimiz kerak . Bizda hozir ikki nuqta bor bu 1- producerdan brokergacha kelgan xabarni broker saqlaganini bilib olish , 2-si consumer xabarni process qildimi yoki yoq shuni bilish .
Producer xabar brokerga yetib borganini bilishi
Bunda 2 xil mode bor :
Fire and forget (xabarni yuboradi tamom) javobni kutmaydi. Bu tez ammo broker o’chib qolgan bo’lsa yoki xabar yo’qolsa producer bilmaydi.
Acknowledgment bilan — bunda producer broker xabarni olib saqlaganini tasdiqlagandan so’ng muvafaqiyatli deb hisoblaydi . Ammo hali consumer xabarni oldi degani emas.
Brokerda consumer xabarni olib process qilgani bilish
Bu holatda consumer xabarni to’liq process qilib bo’lgandan so’ng ack ma’lumotni brokerga yuboradi va u bu xabar process qilinganini biladi.
Bundan tashqari 2 ta consumer bir vaqtda bir xabarni process qilmasligi uchun consumer xabarni lock qilishi(boshqalar olishidan) yoki boshqa consumerlardan vaqtincha yashirishi kerak , bu message queuelardan implementatsiyaga qarab har xil bo’ladi ammo hammasida hisobga olingan . Bu lock ma’lum vaqt ushlab turiladi agar shu vaqt ichida tugatilganiligi haqida xabar kelmasa u qayta ochiladi .
Bu uslub bilan ham bizda edge caselar bor masalan consumer ishni tugatdi ammo ack qilishdan oldin o’chib qoldi va bu brokerda xabar process qilinmadi deganini va uni qayta boshqa consumerga berdi shuning uchun ular idempotent bo’lishi kerak . Ya’ni qayta qayta process qilinganda ham sistemadagi holat bir xil bo’lishi kerak.
Idempotency haqida alohida maqola qilinadi.
Xabar yetkazib berish kafolatlari
Qachonki consumer xabarni muvaffaqiyatsiz process(bu servis uni process qilolmagan yoki process qilib ack qilishga ulgurmagan bo’lishi mumkin) qilsa biz xabarni yo’qotamiz yoki uni qayta jo’natishimiz kerak bu duplikatsiya degani .
Shuning uchun bizda ushbu yetkazib berish kafolatlari mavjud :
At least once (kamida bir marta)
Bunda xabar process qilish xatolik bersa uni qayta jo’natib ko’radi ammo bu duplikatsiyani yaratadi . Consumer idempotent bo’lishi kerak.
At most once(ko’pida bir marta)
Bunda xabar eng ko’pi bilan 1 marta boradi yani yuboriladi agar fail bo’lsa qayta harakat qilinmaydi bu juda tez ammo. xatolik bo’lsa xabarni yo’qotasiz.
At least once bu industriya standarti hisoblanadi (hech kim ma’lumot yo’qotishni xohlamaydi) .
Bizda exactly once ham bor bu Kafka tomonida taklif qilinadi (ammo bu ichki bo’lganligi uchun Kafka deep diveda to’liq tushuntiriladi)
Qachon queue ishlatish kerak ?
Eng oddiy tushunish uslubi bu sizga hozir natija kerak emas keyin ham olsangiz bo’ladi bu holatda message queue ishlatgan yaxshi , decoupling uchun birdaniga oshgan yuklamani salqab qolish uchun va ishonchlilik uchun ishlatish tavsiya qilinadi.
Note: strict latency requirement bo’lganda ishlatish tavsiya qilinmaydi (qachon javob kelishini bilmaymiz)
Back pressure
Agarda queuedagi messagelar soni keskin o’sib ketsa va u berilgan xotiradan ko’p bo’lib ketishi mumkin va natijada performance tushadi . Back pressure orqali queue hajmiga chegara qo’yiladi va bu bizga tez javob vaqtini taminlashga yordam beradi . Queue to’lib qolsa foydalanuvchi 503 xatolik olib keyinroq harakat qilishi so’raladi .
Har xil xatolikla va trade offlar
Queue oshayotgan throughputni qanday qabul qiladi ?
Queueni partitionlash yani bo’lib tashlash orqali horizontal scaling qilamiz , har bir consumer alohida partition bilan ishlaydi .
Bir partition doim faqat bitta consumer guruhdagi bir consumer orqali ishlaydi shuning uchun eng maksimal foydali bu consumerlar soni partitionlar soniga teng bo’lishi .
Tartib esa faqat shu partition ichida kafolat beriladi shunda bir accountdan pul yechish va tashlash accountid key bo’lgani uchun shu partitionga keladi . Bu yerda partition keyni to’g’ri tanlash ham juda muhim . Trade off esa agar random key bilan partition bo’lsa tartibdan voz kechishingiz kerak.
Producer consumer process qilishidan ko’proq message yuborsa nima bo’ladi ?
Agarda bu holatda hech narsa qilmasangiz message queue xotirasi to’ladi va o’chib qoladi .Bu holatda cloud providerlar odatda autoscaling taklif qilishadi yoki consumerlarni xabar soniga asoslab scaling qilish mumkin (Kubernatesda KEDA uslubi mavjud buunda xabarlar soni berilgan qiymatga yetganda yangi podlarni qo’shadi va tushgandan so’ng keraksiz podlarni o’chirib tashlaydi) bu birdaniga ko’paygan xabarlarni process qilishga yordam beradi .
Boshqa uslub esa tepada aytganimiz backpressure queue xabarlar soniga chegara qo’yish , bundan tashqari monitoring uchun queuedagi xabarlar soniga ham alert ulash kerak bo’ladi.
Bazan xabarni process qilish xatolik beradi nima qilish kerak ?
Ba’zi xabarlar process qilish bir necha marta xatolik beradi agarda buni to’g'rilamasak yoki oldini olmasak ular cheksiz qaytib kelaveradi va ularni soni ortib boraveradi va sizda haqiqiy to’g’ri xabarlar qolib ketadi .
Shuning uchun bazi berilgan chegaradan so’ng ularni dead letter queularga qo’yiladi bu yerga hamma muammoli xabarlar boradi va uni developer qayta tekshirib ko’radi qo’lda va sabablarni qidiradi.
Agar queue o’chib qolsa nima bo’ladi ?
Ba’zi message queuelar masalan kafka xabarlarni diskga yozib qo’yadi va uni bir nechta broker orqali replikatsiya qilishimiz mumkin shunda agar birortasi o’chib qolsa qolgani uni o’rnini oladi va odatdagidek davom etadi.
Eng mashhur queuelar
Kafka queue va stream processing sifatida ishlatsa ham bo’ladi. Amazon SQS esa fifa bor va iloji boricha tartiblashga urinadi va biz bilgan RabbitMQ bor.
Xulosa
Xulosa qilib aytadigan bo’lsa sizga javob hozir kerak bo’lmagan yoki uzoq vaqt ishlaydigan vazifalarni message queue orqali workerga berib ishlatish sistemani javob berish vaqtini hamda chidamliligini oshiradi , shu bilan birga servislar orasidagi bog’liqligam kamayadi . Yetkazib berish kafolatiga kelsak Agarda sizga aniq xabar kerak bo’lsa at least once ishlatilinadi balkim anlitika uchun at most once ishlatish mumkin .