Fencing Token — taqsimlangan lock yoki lease egasiga beriladigan, har yangi egalikda monoton ortib boruvchi tartib raqami. U taqsimlangan tizimdagi aniq consistency, replication yoki fault-handling masalasini ifodalaydi. Kafolatlar faqat termin nomidan emas, protocol modeli, failure farazlari va implementatsiya hujjatidan aniqlanadi.
Mohiyati
Client lease olganda token ham oladi va har write so‘roviga uni qo‘shadi. Storage yoki boshqarilayotgan resurs oxirgi qabul qilingan tokendan kichik qiymatli operatsiyani rad etadi. Shu yo‘l bilan muddati tugagan eski client kechikib qaytsa ham yangi egadan keyin data yozolmaydi.
Fencing Token alohida algoritm yoki konfiguratsiya sifatida emas, client xulqi, storage persistence va tarmoq noaniqligi bilan birga ko‘riladi. Bir tugundagi muvaffaqiyat boshqa replica ham shu state’ni commit qilganini avtomatik anglatmaydi. Shu sabab acknowledgementning aniq ma’nosi va visible state chegarasi hujjatlashtiriladi.
Ishlash tartibi
Lease faqat vaqtga asoslanadi; process uzoq pausega tushib, lease tugaganini bilmay qolishi mumkin. Fencing token esa resursning o‘zida eski egani ajratadi. Token tasodifiy lock identifikatori emas, tartiblanuvchi epoch bo‘lishi kerak.
Fencing Token bilan ishlaydigan tizimda failure modeli oldindan yoziladi. Xabar kechikishi, yo‘qolishi, tugun restarti va network partition bir xil hodisa sifatida talqin qilinmaydi. Har biri uchun client ko‘radigan javob, saqlanadigan state va recovery ketma-ketligi belgilanadi. Timeout noaniqlikni aniqlaydi, ammo sababni o‘zi isbotlamaydi.
Kafolatlar va farqlar
Token tekshiruvi faqat coordinator tomonida qolsa himoya to‘liq emas. Yakuniy storage, actuator yoki API monotonlikni enforce qilishi, token overflow va state tiklanishi ham hisobga olinishi zarur.
Fencing Token dizaynida safety va liveness ajratiladi. Safety buzilishi qarama-qarshi commit yoki noto‘g‘ri qiymatga, liveness buzilishi esa tizimning oldinga siljimasligiga olib keladi. Timeoutni qisqartirish livenessni tezlashtirishi mumkin, biroq sekin tarmoqda false failure va keraksiz leader almashishini oshiradi.
Amaliy tekshiruv
Fencing Token diagnostikasida client error, coordinator state va replica log bir vaqt chizig‘ida bog‘lanadi. Clock sinxronligi yetarli bo‘lmasa correlation ID va log index ishlatiladi. Retry birlamchi xatoni yashirmasligi uchun dastlabki response ham saqlanadi. Faqat joriy state emas, unga olib kelgan tarix ham tekshiriladi.
Fencing Token bilan ishlaydigan API noaniq natijani clientga aniq ifodalaydi. Timeout operatsiya bajarilmadi degani bo‘lmasligi mumkin: server commit qilib, javob yo‘lda yo‘qolgan bo‘lishi ehtimol. Idempotency key, operation ID yoki read-back tekshiruvi duplicate write’ni kamaytiradi. Client cheksiz retry qilmaydi; exponential backoff, jitter va umumiy deadline ishlatiladi. Bu qoidalar overload paytida barcha clientning bir vaqtda qayta so‘rov yuborib, tizimni yanada band qilishiga yo‘l qo‘ymaydi.
Fencing Token holatini kuzatishda configuration version, role yoki epoch, commit nuqtasi, queue va log ko‘rsatkichlari birlashtiriladi. Alert operator bajara oladigan tekshiruvga bog‘lanadi: qaysi node, qaysi key yoki transaction va qaysi vaqt oralig‘i ko‘rilishi aniq yoziladi. Aggregate dashboarddan keyin xom dalil bilan tasdiqlash noto‘g‘ri tashxisni kamaytiradi.
Fencing Tokenga oid bahoni qayta ishlab bo‘lishi uchun test topologiyasi, software versiyasi, fault injection va kutilgan invariant saqlanadi. Yakuniy natija taxmin yoki bitta log satriga emas, bir-birini tasdiqlovchi state, history va o‘lchovlarga asoslanadi. Qabul qilingan cheklovlar ham natija bilan birga yozilib, boshqa workloadga ko‘r-ko‘rona ko‘chirilmaydi.
Bog‘liq tushunchalar
distributed lease, distributed lock, epoch number, stale writer, mutual exclusion, consensus