Pub/Sub — publisher xabarni muayyan topicga yuboradigan, subscriberlar esa o‘zlari kuzatayotgan topic xabarlarini qabul qiladigan asinxron aloqa modelidir. Publisher qaysi subscriber xabarni olishini bevosita bilmaydi. Broker yoki messaging xizmati xabarlarni topic bo‘yicha ajratib, ishlab chiqaruvchi bilan iste’molchilar orasidagi bog‘liqlikni kamaytiradi.
Asosiy rollar
Publisher hodisa yoki ma’lumotni xabar sifatida e’lon qiladi. Topic mantiqiy kanal nomidir. Subscription ma’lum topicdan xabar olish holatini ifodalaydi. Bitta topicga bir nechta mustaqil subscription ulansa, har bir guruh xabarning o‘z nusxasini oladi.
Masalan, order.created hodisasini to‘lov, ombor va analytics xizmatlari alohida subscription orqali qabul qilishi mumkin. To‘lov xizmati xabarni qayta ishlagani ombor subscriptionidagi xabarni o‘chirib yubormaydi.
Yetkazish semantikasi
At-most-once model xabarni ko‘pi bilan bir marta yetkazadi; nosozlikda yo‘qolishi mumkin. At-least-once xabarni qayta yuboradi, shu sababli subscriber duplicate olishi mumkin. Exactly-once atamasi tizim doirasi va cheklovlariga bog‘liq; tashqi side effect bilan mutlaq bir martalik bajarilish ko‘pincha idempotency talab qiladi.
Subscriber xabarni muvaffaqiyatli qayta ishlagach acknowledgement yuboradi. Ack muddati o‘tsa, broker xabarni qayta yetkazishi mumkin. Doim xato beradigan xabar retry loopda qolmasligi uchun maksimal urinishdan so‘ng dead-letter queuega o‘tkaziladi.
Tartib va partition
Global xabar tartibini saqlash throughputni cheklashi mumkin. Ko‘p tizimlar faqat bitta partition yoki ordering key ichida tartib kafolatlaydi. Bir obyektga tegishli hodisalar bir key bilan yuborilsa, subscriber ularni ketma-ket ko‘radi. Turli keylar parallel qayta ishlanadi.
Subscriber sekinlashganda backlog o‘sadi. Consumer lag e’lon qilingan va qayta ishlangan pozitsiya farqini ko‘rsatadi. Auto scaling backlog yoki ishlash vaqtiga qarab consumer sonini oshirishi mumkin.
Xabar sxemasi
Xabar payloadi JSON, Protobuf, Avro yoki boshqa formatda bo‘ladi. Event nomi, versiya, event ID, vaqt va trace context metadata sifatida beriladi. Producer maydonni olib tashlasa eski subscriber buzilishi mumkin; schema evolyutsiyasi orqaga mos qoidalar bilan boshqariladi.
Katta binary faylni broker xabariga joylash o‘rniga object storagega yozib, xabarda manzil va checksum berilishi mumkin. Brokerning maksimal xabar hajmi va retention muddati hisobga olinadi.
Pub/Sub va queue farqi
Oddiy work queue xabarni raqobatlashuvchi workerlardan bittasiga ish sifatida beradi. Pub/Sub esa bir hodisani bir nechta mustaqil iste’molchiga tarqatadi. Amaliy broker ikkala modelni subscription va consumer group orqali qo‘llashi mumkin. Model tanlovi “ishni bir marta kimdir bajarsin” yoki “hodisani barcha tegishli tizim bilsin” ma’nosiga bog‘liq.
Idempotent subscriber
At-least-once yetkazishda event ID subscriber tomonidan qayta ishlangan yozuvlar jadvalida saqlanishi mumkin. Business o‘zgarish va event ID qaydi bitta local transactionda yozilsa, crashdan keyin duplicate side effect kamayadi. Tashqi email yoki payment kabi amal uchun provider idempotency key yoki alohida outbox kerak bo‘lishi mumkin. Subscriber xabarni ack qilishdan oldin barcha muhim ishni durable holatga keltiradi. Ack avval yuborilsa, keyingi crash xabarni yo‘qotadi; juda kech yuborilsa broker timeout sabab duplicate yetkazadi. Processing muddati ack deadline va lease extension bilan mos boshqariladi.
Xabar producer va subscriber soatlari farqli bo‘lishi mumkin; orderingni faqat client timestampga bog‘lash o‘rniga broker position yoki domain sequence bilan tekshirish aniqroq natija beradi.
Bog‘liq tushunchalar
message broker, topic, subscription, event-driven architecture, consumer, acknowledgement, dead-letter queue