Bosh sahifa Wiki Message broker

Message broker

Message broker — producer yuborgan xabarlarni qabul qilib, saqlab, routing qoidalari asosida consumerlarga yetkazadigan vositachi tizim. U xizmatlarni vaqt va joy bo‘yicha bo‘sh bog‘laydi: producer consumer ayni paytda ishlayotganini yoki uning manzilini bilishi shart emas. Queue, publish-subscribe, event streaming va request-reply patternlari broker imkoniyatiga qarab qo‘llanadi.

Queue modeli

Work queue’da bir xabar consumer guruhidagi odatda bitta workerga beriladi. Bir nechta worker parallel ishlab throughputni oshiradi. Broker xabarni delivery qiladi, consumer muvaffaqiyatli ishlagach acknowledge yuboradi. Ack kelmasa visibility timeout yoki connection uzilishidan keyin xabar qayta yetkazilishi mumkin.

At-most-once xabarni yo‘qotishi mumkin, lekin duplicate bermaslikka yaqin. At-least-once xabarni saqlab retry qiladi, biroq duplicate ehtimoli bor. Exactly-once broker doirasida maxsus transaction va idempotent producer bilan ta’minlanishi mumkin, ammo database, email yoki payment kabi tashqi side effect end-to-end idempotency talab qiladi.

Publish-subscribe

Pub/sub’da bitta message bir nechta subscription yoki consumer guruhiga nusxalanadi. Billing, analytics va notification bir eventni mustaqil olishi mumkin. Topic yoki exchange message categoryni, routing key esa aniq yo‘lni belgilaydi. Fanout barcha subscriberga, direct aniq keyga, topic pattern bo‘yicha routing qiladi.

Yangi subscriber eski xabarlarni oladimi, retention va subscription turiga bog‘liq. Ephemeral subscriber offline paytda eventni yo‘qotishi mumkin. Durable subscription cursor yoki offsetni saqlab, keyin davom etadi. Retention tugasa juda ortda qolgan consumer data’ni boshqa manbadan qayta qurishi kerak.

Ordering

Global ordering qimmat va scalingni cheklaydi. Ko‘p broker partition yoki queue doirasida tartib kafolatlaydi. Bir entityga tegishli eventlar bir partitionga tushishi uchun order ID kabi partition key ishlatiladi. Hot key bitta partitionni ortiqcha yuklashi mumkin.

Retry qilingan xabar keyingi xabarlar ortida qayta kelib, tartibni o‘zgartirishi mumkin. Strict ordering talabida bitta xato message partitionni to‘xtatadi yoki per-key processing qo‘llanadi. Consumer version va event sequence bilan stale update’ni aniqlashi mumkin.

Durability

Persistent message diskka va kerak bo‘lsa bir nechta broker replica’ga yoziladi. Producer acknowledgement qaysi bosqichda muvaffaqiyat sanalishini belgilaydi. Leader memoryga qabul qilishi bilan ack tez, quorum diskka yozgach ack esa bardoshliroq, lekin sekinroq.

Broker replica backup o‘rnini bosmaydi. Operator xatosi, retention yoki zararli delete barcha nusxaga tarqalishi mumkin. Muhim event log export, snapshot va replay rejasi bilan saqlanadi. Message ichidagi shaxsiy data retention va o‘chirish talablariga mos bo‘ladi.

Xato xabarlar

Consumer vaqtinchalik xatoda exponential backoff va jitter bilan retry qiladi. Doimiy invalid message cheksiz “poison message” loop yaratmasligi uchun maksimal urinishdan keyin dead-letter queue’ga o‘tadi. DLQ monitoring va qayta ishlash workflow’siga ega; u xabarlar abadiy unutiladigan ombor emas.

Message schema versionlanadi. Consumer unknown fieldni ko‘tara olishi, producer esa required maydonni birdan olib tashlamasligi kerak. Schema registry compatibility qoidalarini avtomatik tekshirishi mumkin. Deserialization ishonchsiz input sifatida size va type limit bilan bajariladi.

Xavfsizlik va kuzatuv

Producer faqat kerakli topicga publish, consumer faqat o‘z subscriptioniga read ruxsat oladi. TLS transportni, mTLS yoki token client identityni himoya qiladi. Message payload end-to-end maxfiy bo‘lishi kerak bo‘lsa application encryption ishlatiladi; broker routing metadata’ni baribir ko‘rishi mumkin.

Queue depth, oldest message age, consumer lag, publish/consume rate, redelivery va DLQ soni kuzatiladi. Faqat queue length pastligi yaxshi holat emas: producer ishlamay qolgan bo‘lishi mumkin. Trace context message headerda uzatiladi, ammo credential yoki katta baggage qo‘shilmaydi.

Bog‘liq tushunchalar

Queue, Publish-subscribe, Consumer, Producer, Dead-letter queue, Event streaming, Delivery semantics