GH GambleHub

Exactly-once semantika

exactly-once aslida nima

«exactly-once» ko’pincha ikki xil narsani tushunadi:
  • Yetkazib berish: xabar isteʼmolchiga aynan bir marta yetkazib beriladi.
  • Qayta ishlash: oxirgi nojo’ya ta’sir (DBga yozish, balansni o’zgartirish, boshqa hodisa emissiyasi) yetkazib berish yoki urinishlar ko’proq bo’lsa ham, aynan bir marta sodir bo’ladi.

Taqsimlangan tizimlarda ishlov berish semantikasi haqida gapirish ishonchliroq. Yetkazib berishni aniq bir marta ta’minlash qiyin (dublikatlar va takrorlash muqarrar), ammo yakuniy holat yagona qayta ishlashga teng bo’lishiga ishonch hosil qilish mumkin.


EOS qachon kerak va qachon kerak emas

Quyidagi hollarda EOS talab qilinadi:
  • Pul tranzaksiyalari va balanslar: ikki marta hisobdan chiqarishga yo’l qo’yilmaydi.
  • Litsenziyalar/kvotalar, billing hisoblagichlar hisobi.
  • Qaytarib bo’lmaydigan tashqi qo’ng’iroqlar (masalan, kalitni bir martalik faollashtirish).
at-least-once + idempotentlik, agar:
  • Samaralar qaytariladi yoki qoplanadi (sage, qaytarish).
  • Vitrinalar/loglarda vaqtinchalik dublikatlarga yo’l qo’yiladi.
  • Tranzaksiyalarni butun trakt bo’ylab olib o’tishdan ko’ra, idempotent sinkni ta’minlash arzonroq.

Model: end-to-end vs. hop-by-hop

Hop-by-hop EOS: har bir uchastka (manba → protsessor → qabul qiluvchi) o’z harakatini aynan bir marta qo’llashini kafolatlaydi.
End-to-end EOS: butun zanjir «fakt» dan «sayd-effekt» gacha bo’lgan natija yagona qayta ishlashga teng ekanligini kafolatlaydi.

Amalda end-to-end har bir xopda tranzaksiyalar va/yoki idempotentlik kombinatsiyasi orqali erishiladi.


Bazaviy qurilish bloklari

1. Idempotent operatsiyalari

Operatsiya kaliti boʻyicha bir xil soʻrovni takrorlash ham xuddi shunday natija beradi.

Ключи: `idempotency_key`/`event_id`/`operation_id`.
Amalga oshirish: TTL bilan «koʻrilgan» operatsiyalar jadvali ≥ kirish log retensiyasi.

2. «O’qish-qayta ishlash-yozish» tranzaksiyalari (read-process-write)

Ishning bitta atomar birligida nojo’ya ta’sir va o’qish taraqqiyoti (ofset/pozitsiya) qayd etiladi. Bu qadamlar orasiga tushganda «arvohlarni» yo’q qiladi.

3. Version/SEQUENCE

Agregat uchun versiya/hisoblagich saqlanadi; oʻzgarishlar faqat’expected _ version’mos kelsa qoʻllaniladi. Bir xil hodisani takrorlash → effektini bir marta oshirmaydi.

4. Deduplikatsiya

’(consumer_id, event_id) bo’ yicha yoki tabiiy’business _ id’operatsiyasi bo’yicha indeks.


Sotish patternlari

1) Tranzaksion log + ofset fiksatsiyasi bilan tranzaksion sink

Strim-protsessing uchun ideal.

Biz logdan o’qiymiz (faqat tasdiqlangan yozuvlar).
Koʻrib chiqilmoqda.

Bitta tranzaksiyada:
  • a) ta’sirni sink (DB/jadval) ga yozib olamiz,
  • b) «N ofsetgacha o’qildi» (xuddi shu DBda).
  • Commit. Restartda hamma narsa noto’g’ri yoki hech narsa yo’q.

Xossalari: takrorlash zararli emas; Xabar ikki marta oʻqilgan boʻlsa ham, effekt boʻyicha «bir marta».

2) Outbox + idempotent konsumer

Tranzaksion servis-prodyuserlar uchun.

Bitta DB tranzaksiyasida: domen yozuvini o’zgartiramiz va voqeani outboxda yozamiz.
Republikator voqeani xuddi shu’event _ id’bilan shinaga yetkazadi.
Konsumerlar voqealarni idempotent (dedup’event _ id’) da qoʻllaydilar.

Xossalari: prodyuser haqiqat yo’qolmasligini kafolatlaydi; konsumerlar aynan bitta samarani kafolatlaydi.

3) Kafka/Flink-ga o’xshash tizimlardagi EOS (konseptual jihatdan)

Idempotent prodyuser: jo’natish retralarida dubllardan himoya qiladi.
Prodyuserning tranzaksiyalari: topikaga yozuvlar guruhi + konsumerning siljishi atomar bo’ladi; o’quvchilar’read _ committed’izolyatsiyasidan foydalanadilar.
Protsessing tomoni (state store) holatini saqlaydi va uni tranzaksiya bilan birga kommitit qiladi.

Xossalari: Stora/task qayta ishga tushirilishi ikki marta taʼsir qilmaydi; «koʻrinmaydi».

4) Idempotent «siki» (sinks) upsert/merge orqali

Sink’operation _ id ’/’ event _ id’ni qabul qiladi va’UPSERT’ni bajaradi... WHERE NOT EXISTS`.

Nojo’ya ta’sir (masalan, hisoblash) «allaqachon qo’llanilganmi?»

Xossalari: taqsimlangan tranzaksiyalarsiz ombor chegarasida arzon EOS usuli.


Amalga oshirishning asosiy tafsilotlari

Amalning identifikatorlari

Takrorlash uchun aniqlangan boʻlishi kerak (retrada yangi UUID yaratmang).
Barqaror ko’rinish sohasiga (konsumerga/agregatga/tizimga) ega bo’lish.

Deduplikatsiya jadvali

Колонки: `consumer_id`, `operation_id`, `applied_at`, `ttl_expires_at`.
’(consumer_id, operation_id)’ bo’yicha indekslar.
TTL maksimal takrorlash oynasi ≥ (logning retentsiyasi + potentsial kechikishlar).

Optimistik raqobat

Agregat versiyasini write modelida saqlang.
Hodisa/buyruqni qoʻllashda’WHERE version =: expected’dan foydalaning; dublikat versiyani kattalashtirmaydi.

Buyurtma/tartib

EOS «xuddi shunday tartib» ga teng emas. Partitsiya kaliti (barcha agregat voqealari → bitta partitsiya) va/yoki «sequence» taqqoslash orqali konsistentlikni taʼminlang.

Idempotent tashqi chaqiruvlar

Xavfsiz usullar uchun (masalan, uchinchi tomon xizmatiga HTTP vebxuklari)’Idempotency-Key’qoʻshing va sherik uni qoʻllab-quvvatlashini talab qiling.


Tez-tez tuzoq

EOS faqat bitta joyda: agar sink idempotent bo’lsa, lekin siz ikkilamchi voqealarni idempotentsiz chiqarsangiz, «aynan ko’p marta» downstream olasiz.
Ikkita kommita: avval DBda, so’ngra brokerda kommit ofset - ular orasidagi yiqilish effektlarning dublikatlarini yaratadi.
Xom CDClar tashqarida: DB sxemasini o’zgartirish iste’molchilarning idempotentligini buzadi.
Beqaror kalitlar:’operation _ id’vaqt/randomga bogʻliq va retrada oʻzgaradi.


Qiymat va murosalar

Latentlik: tranzaksiyalar/izolyatsiya qilingan o’qishlar → o’sish p95/p99.
Omborxonalar overxed: dedup jadvallari, state stores, tranzaksiya loglari.
Foydalanish murakkabligi: tranzaksiyalar taymautlari, oqimlar rebalansi, «yopishgan» sessiyalar.
Diagnostika: ko’proq holatlar ("kamitda", "ko’rinadi read_committed", "orqaga qaytdi").

EOSni aniq tanlang: kritik agregatlar va effektlar uchun; qolganlarini idempotentlik va kompensatsiya bilan qoplang.


exactly-once sinovi

1. Fault-injection: qadamlar orasidagi jarayonning pasayishi «effektni yozib oldi» va «ofsetni yozib oldi».
2. Dublikatlar: xuddi shu xabarni 2-5 marta uzating, bitta effektga ishonch hosil qiling.
3. Restartlar va rebalans: vorkerlarni toʻxtatish/qayta ishga tushirish, ikki marta ishlov berilmaganini tekshirish.
4. Tarmoq flappisi: tranzaksiya oʻrtasidagi taymautlar, kommitni takrorlash.
5. Yuklash testlari: navbatlarning o’sishi → «tranzaksiyalarda abadiy» gacha tanazzul yo’qmi.


Mini-shablonlar (psevdo)

Idempotent sink ofset fiksatsiyasi bilan

pseudo begin tx if not exists(select 1 from dedup where consumer_id=:c and op_id=:id)
then apply_effect(...)    -- upsert / merge / add_one_time_action insert into dedup(c, id, applied_at) values(:c,:id, now)
end if update offsets set pos=:pos where consumer_id=:c commit

Agregat versiyasi bilan buyruq

pseudo begin tx update account set balance = balance +:delta,
version = version + 1 where id=:account_id and version=:expected_version;
if row_count=0 then error CONCURRENT_MODIFICATION commit

Xavfsizlik va komplayens

PII/PCI: minimal saqlang, «xom» maʼlumotlar oʻrniga tokenlardan foydalaning.
Audit:’operation _ id’,’trace _ id’, natija (APPLIED/ALREADY_APPLIED).
Saqlash siyosati: dedup jadvallarda TTL, ofset/loglarni arxivlash.


Anti-patternlar

«Haqiqiy exactly-once yetkazib berish»: ta’sirning idempotentligisiz transport protokoli darajasidagi dubllarni yo’q qilishga urinish.
Global taqsimlangan tranzaksiyalar hamma narsaga: barcha xizmatlar orqali XA/2PC - mo’rt va sekin.
Noidempotent nojo’ya ta’sirlarni aralashtirish (masalan, e-mail ofset kommitidan oldin yuborilgan).
Operatsiya kalitlari yo’qligi: foydali yukning «noyobligiga» tayanish.


Prodakshenning chek-varaqasi

  • Har bir tanqidiy ta’sirda idempotent kaliti mavjud.
  • Ofset/o’qish pozitsiyasi bitta effektli tranzaksiyada qayd etiladi.
  • Dedup jadvallari indekslangan; TTL ≥ log retensiyasi.
  • Agregatlar uchun optimistik raqobat (versiya/sequence) yoqilgan.
  • Oqimlar/topiklar «faqat maxfiy» (agar mavjud boʻlsa) rejimida oʻqiladi.
  • Dublikat va yiqilish testlari CI/CD’da mavjud.
  • Dashbordlar: takrorlash ulushi, muvaffaqiyatsiz tranzaksiyalar, blokirovka vaqti, laglar.
  • ’Idempotency-Keu ’/takrorlash/taymaut integratorlari uchun hujjatlar.

FAQ

EOSni tranzaksiyalarsiz taʼminlash mumkinmi?
Ko’pincha ha - sink’olarning idempotentligi (upsert/merge) va agregatlarni versiyalash orqali. Tranzaksiyalar kafolatlarni soddalashtiradi, lekin narxni oshiradi.

Hamma uchun «exactly-once» kerakmi?
Yo’q. U qimmat. Kompensatsiya mumkin bo’lmagan joyga/yo’lga qo’llang.

Xatlar/vebxuklarni EOS bilan qanday bogʻlash mumkin?
Xabarni kommitdan oldin bufer qiling, effektni tuzatgandan keyin yuboring; ’notification _ id’ ni saqlang va joʻnatishni idempotent qiling.

Nima muhimroq - yetkazib berish yoki qayta ishlash?
Qayta ishlash. Yetkazib berish takrorlanishi mumkin; yakuniy holat to’g "ri va yagona bo’lishi kerak.


Jami

Exactly-once - bu simda dubllar yo’qligi haqida emas, balki ta’sirning to’g’riligi haqida. Bunga idempotentlik, o’qish samarasi va taraqqiyotini atomar belgilash, oqilona partiyalashtirish va versiyalashtirish intizomi uyg’unligi erishiladi. Xatoning narxi nomaqbul bo’lgan joyda EOSni qo’llang va uning haqiqiyligini yiqilish va dubl sinovlari orqali tekshiring - transportga ishonmang.

Contact

Biz bilan bog‘laning

Har qanday savol yoki yordam bo‘yicha bizga murojaat qiling.Doimo yordam berishga tayyormiz.

Integratsiyani boshlash

Email — majburiy. Telegram yoki WhatsApp — ixtiyoriy.

Ismingiz ixtiyoriy
Email ixtiyoriy
Mavzu ixtiyoriy
Xabar ixtiyoriy
Telegram ixtiyoriy
@
Agar Telegram qoldirilgan bo‘lsa — javob Email bilan birga o‘sha yerga ham yuboriladi.
WhatsApp ixtiyoriy
Format: mamlakat kodi va raqam (masalan, +998XXXXXXXX).

Yuborish orqali ma'lumotlaringiz qayta ishlanishiga rozilik bildirasiz.