Tranzaksion mesejing

Tranzaksion mesejing - bu lokal holat o’zgarishlari (BD/kesh) va broker/shina xabarlari o’rtasida muvofiqlikni ta’minlaydigan arxitektura usullari to’plami. Maqsad: nosozliklar, retrajlar, kattalashtirish va ko’p tenantlik holatlarida «xabar yo’qolmagan va takrorlanmagan holati qayd etilgan».

1) Yetkazib berish semantikasi

At-most-once: tez va arzon, yo’qotishlar bo’lishi mumkin, dubllar yo’q.
At-least-once: xabarlarni yo’qotmaydi, dubli bo’lishi mumkin → idempotentlik talab etiladi.
(Samarali) Exactly-once: yo’qotishlar va biznes effektlari uchun ko’rinadigan dubllar yo’q, texnikalar kombinatsiyasi (outbox/inbox, prodyuser/konsumer tranzaksiyalari, dedup) bilan erishiladi.

2) Nima uchun «ikki yozuv» xavfli?

«Avval DBga yozib olamiz, so’ngra shinaga jo’natamiz» degan sodda mantiq (yoki aksincha) qadamlar orasiga tushganda yirtiladi: ma’lumotlar qayd etilgan, voqea esa yo’qolgan; yoki hodisa tugadi, ammo maʼlumot yoʻq. Tranzaksion mesejing bu tafovutni bartaraf etadi.

3) Bazaviy patternlar

3. 1 Outbox (ishlab chiqaruvchi)

Bitta lokal tranzaksiyada biznes-o’zgarish va satrni «outbox» jadvaliga yozamiz; alohida publicher outbox o’qiydi va brokerga retralar va backoff bilan nashr etadi. Yo’qotishlar chiqarib tashlandi; iste’molchilarning idempotentligini o’zgartirish.

3. 2 Inbox/Idempotent Consumer (isteʼmolchi)

Effektni bajarishdan oldin konsumer’INSERT’ni’inbox (consumer, event_id)’ga birlamchi kalit sifatida kiritadi. Kalit toʻqnashuvi = hodisa allaqachon koʻrib chiqilgan → oʻtkazib yuborilmoqda. Shunday qilib, «samarali exactly-once» ga erishiladi.

3. 3 Read-Process-Write ofset tranzaksiyasi bilan

Logga yo’naltirilgan shinalar uchun shablon: konsumer batch o’qiydi, xuddi shu tranzaksiyada biznes o’zgarishi va «o’tgan ofset» ni qayd etadi. Kommitdan keyin broker xabarlarni iste’mol qilingan deb hisoblaydi. Bu «o’qish → yiqilish → takrorlash» ni bartaraf etadi.

3. 4 TSS/Servislararo effektlar uchun saga

Kelishilgan multishagli jarayon kerak bo’lganda, TCC yoki sage’lardan foydalaning; xabarlar - buyruqlar/hodisalar transporti, tranzaksionlik esa - qadamlar va kompensatsiyalar darajasida.

4) Idempotent prodyuserlar va konsumerlar

Prodyuser: barqaror’message _ id ’/’ idempotency _ key’, bir xil kalit bilan qayta yuborish obunachilarga yangi effektlar yaratmaydi; kalit ketma-ketligini saqlang.
Konsumer:’inbox’+ biznes-idempotentlik (upsert/merge, oxirgi versiya/taftishni tekshirish).

5) Tartib va sabablar

Bitta ob’ektning voqealari tartibda bo’lishi uchun biznes kalitiga (masalan,’aggregate _ id’,’tenant _ id’) qo’ng’iroq qiling.
Partiya ichida ketma-ket raqamlar/vaqt belgilarini saqlang; DLQ redrayvida «kalit bo’yicha va izchil» rioya qiling.
Agar global tartib muhim bo’lmasa, kalitning mahalliy tartibini ta’minlang va domen invariantlarini aniqlang.

6) Offsetlar va effektlarni qayd etish

A variant: «DBga ofset»

«Oxirgi qayta ishlangan ofset (partition, offset)» ni domen maʼlumotlarini oʻzgartiradigan tranzaksiyaga yozing. Qayta boshlanganda, keyingi ofsetdan qaytadan taʼsir qilishdan qoching.

B variant: «Broker tranzaksiyasi»

Ba’zi brokerlar prodyuser/konsumerning bitta tranzaksiyasi doirasida xabarlar va ofsetlarning atom yozuvini qo’llab-quvvatlaydi. Agar mavjud bo’lsa, foydalaning, lekin har doim iste’molchiga o’xshashlik bilan to’ldiring.

7) Retrai, backoff, DLQ

Faqat retraibl xatolarni (taymaut, 5xx), eksponensial backoff va jitter bilan takrorlang.
Non-retraibl (schema/validatsiya) - meta-ma’lumotlar (tenant, key, offset, sabab) bilan darhol DLQda.
DLQ redrayvni dozalash (batch, rate limit), aylanishdan oldin sxemani tekshirish, kalit tartibiga rioya qilish.

8) Ko’p tenantlik va mintaqalar

’tenant _ id’,’plan’,’region’soʻzlarini meta maʼlumotlar va partiyalash kalitlariga kiriting.
Per-tenant fairness: «shovqinli» mijoz boshqalardan byudjetni chiqarmasligi uchun nashr/qayta ishlashni cheklang.
Residency: xabarlar va outboxni domen maʼlumotlari bilan bir hududda saqlang; mintaqalararo replikatsiyalar - asinxron agregatlar.

9) Kuzatuv va audit

Treysing: korrelatsiya’event _ id ’/’ aggregate _ id ’/’ saga _ id’, span «read → process → write/commit».
Metrika: nashr/ishlov berish (p95/p99), muvaffaqiyat ulushi, DLQ-rate, redrayv muvaffaqiyati, «dublikatlar bostirildi».
Logi: muvaffaqiyat uchun qisqacha; xatolar haqida batafsil ma’lumot (sabab, urinish, kalit, ofset).
Audit: kim redrayvil/konkida uchdi, qanday batch va qanday natija bilan.

10) Xavfsizlik va muvofiqlik

Payload uchun PIIni minimallashtiring; DLQ/logiga koʻchirilganda niqoblang.
Tashqi shinalar uchun xabarlarni imzolang/shifrlang; xizmatlar orasida mTLS’dan foydalaning.
Saqlash muddatini va «unutish huquqini» boshqaring per tenant/region.

11) Integratsiyaning namunaviy sxemalari

1. Xizmat manbai (write-side)

Lokal tranzaksiya: domen yozuvi + outbox.
Reklama: batchi,’SKIP LOCKED’, backoff, per tenant limitlari.
Lag’now − occurred_at' monitoringi.

2. Xizmat isteʼmolchisi (read-side)

Batch oʻqish → urinish’INSERT inbox (consumer, event_id)’→ muvaffaqiyatli bajarilsa.
Xuddi shu tranzaksiyada biz «o’tgan ofset» ni (A varianti) qayd etamiz yoki brokerning tranzaksiyasiga (B varianti) tayanamiz.
Xato: retray yoki DLQ siyosati.

3. Proyeksiya/materiallashtirilgan tur

Faqat idempotent apdeytlar (upsert), dedupning ixcham kalitlari, nazorat summalarini davriy solishtirish.

12) Konfiguratsiya shablonlari (misol)

yaml producer:
idempotency_key: event_id partition_key: "{tenant_id}:{aggregate_id}"
retry:
max_attempts: 8 initial_ms: 200 max_ms: 8000 strategy: exponential_full_jitter

consumer:
batch: 500 offset_commit: "with_domain_tx"  # или "broker_tx"
inbox_enabled: true concurrency_per_partition: 4 dlq:
enabled: true batch_redrive: 200 rate_limit_per_sec: 50 order_by_key: true

observability:
metrics:
- processing_lag_ms
- publish_success_ratio
- dlq_rate
- redrive_success_ratio tracing_tags: [event_id, tenant_id, aggregate_id, partition, offset]

13) Sotishdan oldingi chek-varaq

• «Ikki yozuv» bartaraf etildi: prodyuserda outbox yoki konsumerda bitta tranzaksiyada ofset va effektni tuzatish.
• Idempotent konsumer:’inbox ’/dedup-jurnal, operatsiyalarning biznes-idempotentligi.
• Biznes-kalit bo’yicha partiyalashtirish, mahalliy tartibga rioya qilingan.
• Backoff + jitter bilan retraylar, xatolar tasnifi, boy meta ma’lumotlar bilan DLQ.
• Redrayv dozalangan, xavfsiz; pleybuklar bor.
• Ko’p tenant limitlar va ustuvorliklar; teglar’tenant _ id/plan/region’.
• Telemetriya: lag’lar, muvaffaqiyat ulushi, «dublikatlar bostirilgan», alertlar p95/p99.
• PII/retenshna/shifrlash siyosatiga rioya qilindi.
• Testlar: qadamlar orasiga tushish, dublikatlar, kalit tartibi, ommaviy redrayv.

14) Tipik xatolar

Outbox/offset tranzaksiyalarisiz alohida qadamlar bilan shinga jo’natish va DBga yozish.
Idempotentsiz konsumer nojo’ya ta’sirlarni takrorlaydi.
Global tartib «qanday bo’lmasin» - qimmat va kamdan-kam hollarda oqlanadi; kalit tartibi yetarli.
Limitsiz ommaviy redrayv → ikkilamchi hodisa.
Treysing/lag-metrik yo’qligi → «yashirin degradatsiya».
DLQ/loglarda PII aralashtirish.

15) Tezkor retseptlar

SaaS-hodisalar: Outbox + idempotent konsumer (inbox), partiyalashtirish’tenant _ id: aggregate _ id’.
ETL/proyeksiyalar: Bir tranzaksiyada ofsetlarni fiksatsiya qilgan holda Read-process-write, batchi 500-1000, upsert.
Yuqori yuk: publicherlarni shardalash,’SKIP LOCKED’, WFQ per tenant, lagni nazorat qilish.
Qattiq komplayens zonasi: mintaqaviy outbox, payload shifrlash, retenshn va redrayv auditi.

Xulosa

Tranzaksion mesejing - ma’lumotlar va xabarlarni birlashtirish intizomi. Outbox/inbox, idempotentlik, ofsetlarni tuzatish va DLQ bilan boshqariladigan retrajlarni birlashtirib, siz global blokirovkalarsiz amaliy exactly-once xatti-harakatlarga ega bo’lasiz va hatto nosozliklar, cho’qqilar va murakkab ko’p-tenant foydalanishda ham SLOni saqlaysiz.