TCC Transaction — distributed business operationni uchta aniq bosqichga ajratadigan transaction pattern: Try, Confirm, Cancel. Har participant resursni avval rezerv qiladi, umumiy jarayon muvaffaqiyatli bo‘lsa tasdiqlaydi, xato bo‘lsa rezervni bekor qiladi.
TCC application-level distributed transaction bo‘lib, participant service’lar maxsus Try, Confirm va Cancel operationlarini amalga oshirishi kerak.
Try
Try bosqichi operationni darhol yakunlamasdan kerakli resursni tekshiradi va rezerv qiladi.
Masalan:
- inventory band qilish;
- balansni freeze qilish;
- joyni vaqtincha ushlash;
- quota rezervi;
- booking yaratish.
Try muvaffaqiyatli bo‘lsa Confirm yoki Cancel uchun transaction ID qaytaradi.
Confirm
Barcha participantlarning Try bosqichi muvaffaqiyatli tugasa coordinator Confirm yuboradi.
Confirm rezervni yakuniy business natijaga aylantiradi.
Masalan:
- rezervlangan stockni sotilgan qilish;
- frozen balansni yechib paymentga aylantirish;
- bookingni tasdiqlash.
Confirm idempotent bo‘lishi kerak.
Cancel
Biror Try xato bersa yoki umumiy deadline tugasa oldingi muvaffaqiyatli Try’lar uchun Cancel yuboriladi.
Cancel:
- rezervni bo‘shatadi;
- frozen mablag‘ni qaytaradi;
- temporary recordni cancelled qiladi.
Cancel ham qayta chaqirilishga chidamli bo‘lishi kerak.
Coordinator
Coordinator transaction qatnashchilarini va bosqichlarini boshqaradi.
U saqlaydi:
- global transaction ID;
- participantlar;
- Try natijalari;
- final qaror;
- Confirm yoki Cancel progressi;
- retry;
- timeout.
Coordinator state durable bo‘lishi kerak.
Resource reservation
TCCning markaziy g‘oyasi resource’ni transaction davomida lock qilib turish o‘rniga business darajada rezerv qilish.
available = 10
reserved = 2
Try reservedni oshiradi.
Confirm available va reservedni yakuniy o‘zgartiradi.
Cancel reservedni kamaytiradi.
Business lock
Rezerv business lock vazifasini bajaradi.
Boshqa transaction available miqdorni hisoblaganda reserved qiymatni inobatga oladi.
Bu database lockdan uzoqroq yashashi mumkin.
Expiration va cleanup zarur.
Empty rollback
Cancel participant Try’ni umuman bajarmagan holatda ham kelishi mumkin.
Masalan, networkda Try request yo‘qolgan, ammo coordinator Cancel yubordi.
Cancel “rezerv topilmadi” holatini xavfsiz muvaffaqiyat deb qabul qilishi mumkin.
Bu empty rollback muammosini boshqaradi.
Hanging
Try request kechikib, Cancel allaqachon bajarilgandan keyin kelishi mumkin.
Agar Try endi rezerv yaratsa transaction cancelled bo‘lsa ham resource band bo‘lib qoladi.
Participant global transaction holatini saqlab, Canceldan keyingi kech Try’ni rad etadi.
Bu hanging muammosi.
Idempotency
Network retry sabab Confirm yoki Cancel bir necha marta keladi.
Participant transaction ID va operation holatini saqlaydi.
State machine:
TRYING
→ CONFIRMED
yoki
→ CANCELLED
Confirmed holatni qayta Confirm qilish side effectni takrorlamaydi.
Timeout
Try reservation cheksiz saqlanmaydi.
Expiration:
bilan boshqariladi.
Participant mustaqil expire qilsa coordinator kech Confirm yuborishi mumkin.
Deadline contracti bir xil bo‘lishi kerak.
TCC va Two-Phase Commit
2PC database resource managerlarining prepare va commit imkoniyatiga tayanadi.
TCC business API’larni Try, Confirm va Cancel sifatida loyihalashni talab qiladi.
2PC lock va transaction logga, TCC esa reservation va compensationga yaqin.
TCC yuqori application complexity evaziga service mustaqilligini saqlaydi.
TCC va Saga
Saga har qadamni local transaction va compensationga ajratadi.
TCC avval barcha kerakli resurslarni Try bilan rezerv qiladi, keyin umumiy Confirm beradi.
TCC kuchliroq oldindan reservation talab qiladi.
Saga irreversible qadamlar bilan ham ishlashi mumkin.
Payment misoli
Try:
amountni freeze qilish
Confirm:
frozen amountni merchantga o‘tkazish
Cancel:
freeze’ni olib tashlash
Real payment provider barcha uch operationni qo‘llashi kerak.
Faqat charge va refund TCC bilan aynan bir xil emas.
Inventory misoli
Try available stockni rezerv qiladi.
Confirm rezervni orderga yakuniy biriktiradi.
Cancel stockni qaytaradi.
Parallel requestlarda atomic conditional update va unique transaction key ishlatiladi.
Failure
Confirm ayrim participantlarda muvaffaqiyatli, boshqalarida xato bo‘lishi mumkin.
Coordinator Confirmni muvaffaqiyatga erishguncha retry qiladi.
Confirm qaroridan keyin Cancelga qaytish odatda mumkin emas.
Manual intervention talab qilinishi mumkin.
Observability
Har global transaction bo‘yicha:
- Try latency;
- reservation;
- Confirm;
- Cancel;
- retry;
- expired reservation;
- hanging request;
- final status
kuzatiladi.
Qolib ketgan TRYING recordlar alert beradi.
Try isolation
Try rezerv yaratgandan keyin boshqa transaction shu resursni available deb ko‘rmasligi kerak.
Participant query va update’lari reservationni hisobga oladi.
Aks holda bir inventory bir necha transactionga rezerv qilinishi mumkin.
Confirm recovery
Coordinator Confirm qarorini durable saqlagach participant vaqtincha unavailable bo‘lsa ham Confirm retry qilinadi.
Bu bosqichdan keyin global transaction Cancelga qaytmaydi.
Operator qolib ketgan confirmationlarni kuzatadi.
Reservation cleanup
Participant expired Try recordlarni davriy tozalaydi.
Cleanup coordinator final holatini tekshirishi yoki global deadline’dan xavfsiz margin kutishi kerak.
Juda erta cleanup kech Confirmni buzadi.
Audit
Har Try, Confirm va Cancel chaqirig‘i global transaction ID bilan audit qilinadi.
Operator qaysi participant rezerv qilgani va qaysi compensation qolib ketganini ko‘ra oladi.
Maxfiy payment ma’lumoti audit logda mask qilinadi.
Capacity
Uzoq Try reservationlari available resource’ni vaqtincha kamaytiradi.
Timeout juda uzun bo‘lsa real foydalanilmayotgan stock yoki balans band qoladi.
Juda qisqa timeout esa normal user workflow’ini bekor qiladi.
Bog‘liq tushunchalar
Try-Confirm-Cancel, Distributed transaction, Resource reservation, Business lock, Idempotency, Saga pattern, Two-Phase Commit, Compensation, Coordinator