Conflict resolution — bir obyekt yoki ma’lumotning mos kelmaydigan bir nechta versiyasi paydo bo‘lganda qaysi natijani saqlash yoki qanday birlashtirishni belgilovchi jarayondir. Konflikt offline tahrir, multi-writer replikatsiya, concurrent transaction yoki versiya boshqaruvida yuz beradi. Yechim faqat texnik tartib emas; biznes invariant va foydalanuvchi niyatini saqlashi kerak.
Konfliktni aniqlash
Version number yoki ETag client o‘qigan holat o‘zgarganini aniqlaydi. Vector clock ikki versiyaning biri ikkinchisidan kelib chiqqanmi yoki ular concurrentmi ko‘rsatishi mumkin. Lamport timestamp tartib beradi, lekin concurrency haqida to‘liq ma’lumot bermaydi. Git common ancestor va ikki branch diffidan uch tomonlama merge qiladi.
Fieldlar turli bo‘lsa avtomatik merge mumkin: bir foydalanuvchi sarlavha, boshqasi rangni o‘zgartirgan. Ayni field o‘zgarsa semantika kerak. Array indeks bo‘yicha merge element insertida noto‘g‘ri; barqaror element ID yaxshiroq.
Yechim siyosatlari
Last-write-wins eng katta timestampli versiyani oladi. Sodda, ammo clock skew va yo‘qolgan update xavfi bor. Server-assigned logical version client soatidan xavfsizroq, lekin concurrent niyatni baribir tashlaydi. First-write-wins keyingi yozuvni rad etib, callerga conflict qaytaradi.
Application merge summa uchun qo‘shish, set uchun union, status uchun domain priority ishlatishi mumkin. Counterga LWW noto‘g‘ri, chunki parallel incrementlardan biri yo‘qoladi. CRDT amallar tartibidan qat’i nazar bir xil natijaga yaqinlashadigan maxsus data turini beradi, ammo barcha biznes qoidani ifodalamaydi.
Offline-first
Qurilma offline paytda local o‘zgarishlar operation logda saqlanadi. Sync base version, local patch va remote currentni solishtiradi. Conflict bo‘lmasa patch qo‘llanadi. Konfliktda userga ikkala qiymat, vaqt va muallif ko‘rsatiladi; faqat “local yoki server” tanlovi katta hujjat uchun qo‘pol bo‘lishi mumkin.
Delete bilan update to‘qnashuvi alohida siyosat talab qiladi. Tombstone yetarli muddat saqlanmasa eski offline qurilma o‘chirilgan recordni qayta tiriltirishi mumkin. Per-device sync cursor va stable operation ID duplicate uploadni kamaytiradi.
Database va transaction
Optimistic concurrency conditional write rad etilganda applicationga merge beradi. Serializable isolation ayrim conflictlarni transactionni abort qilish bilan oldini oladi. Multi-master database conflict log yoki resolver function ishlatishi mumkin. Resolver deterministik, side effectsiz va barcha replika versiyasida bir xil bo‘lishi zarur.
Unique constraint conflictida “tasodifiy bittasini tanlash” biznes identitetni aralashtiradi. Deduplikatsiya matching score, authoritative source va manual reviewga tayanishi mumkin. Merge qilingan recordlar lineage va auditda bog‘lanadi.
Sinov va kuzatuv
Test parallel update, offline uzun davr, clock skew, delete-update va retry kombinatsiyasini qamrab oladi. Property-based test merge commutative, associative va idempotent bo‘lishi kerak bo‘lgan holatlarni tekshiradi. Conflict rate, auto-merge, manual queue, yo‘qolgan field va resolution latency kuzatiladi.
Resolutiondan oldingi versiyalar retention doirasida saqlansa xatoni qaytarish osonlashadi. Maxfiy data audit logda ortiqcha ko‘paytirilmaydi. Yaxshi siyosat yashirin data yo‘qotish o‘rniga noaniq holatni aniq ko‘rsatadi.
Audit va foydalanuvchi tajribasi
Avtomatik birlashtirish har doim to‘g‘ri emas. Bir foydalanuvchi manzilni, boshqasi yetkazib berish hududini o‘zgartirsa, maydonlar alohida bo‘lsa ham biznes jihatdan bog‘liq bo‘lishi mumkin. Muhim yozuvlarda asl versiyalar, tanlangan natija va qaror sababi audit uchun saqlanadi. Qo‘lda hal qilish interfeysi farqlarni tushunarli ko‘rsatishi va foydalanuvchining ishini yo‘qotmasligi kerak.
Bog‘liq tushunchalar
Optimistic concurrency control, Vector clock, CRDT, Last-write-wins, Merge conflict, Tombstone, Offline-first