Conflict Resolution: strategiyalar, birlashtirish va ishlash prinsipi

Mobil ilovalarda mojarolarni hal qilish nima?

Mojarolarni hal qilish — qarama-qarshi o‘zgarishlar aniqlangandan so‘ng tarqalgan ma’lumotlarni yagona kelishilgan holatga keltirish jarayoni. Markazlashtirilgan tizimlarda mojarolar yuzaga kelmaydi: server so‘rovlarni ketma-ket qayta ishlaydi. Oflayn rejimli mobil ilovalarda mijoz ma’lumotlarni mahalliy o‘zgartiradi va keyinroq server bilan sinxronlashadi. Agar ikki mijoz bir ob’ektni o‘zgartirgan bo‘lsa, server bir xil identifikatorga ega, ammo turli mazmundagi ikki versiyani oladi.

Mojarolar zaif bog‘langan replikatsiyada (eventual consistency) muqarrar, tizim bir zumda kelishilganlikni mavjudlik va samaradorlik uchun qurbon qiladi. Princeton University tadqiqotchilariga ko‘ra (Aggarwal et al., GEO paper, KDD 2024), kechiktirilgan replikatsiyali tizimlar cho‘qqi yuklarda 28% ko‘proq samaradorlik ko‘rsatadi, ammo to‘g‘ri ishlash uchun mojaro hal qilish mexanizmlarini talab qiladi.

Hal qilish strategiyasi bu tizim avtomatik ravishda qo‘llaydigan algoritmdir. Turli ma’lumotlar bazalari va freymvorklar turli strategiyalarni amalga oshiradi: Firebase Realtime Database LWW dan foydalanadi, CouchDB Merge qo‘llab-quvvatlaydi, Figma va Notion esa arxitekturani CRDT asosida quradi.

Ma’lumotlar sinxronizatsiyasida nima uchun mojarolar yuzaga keladi

Mojarolarning asosiy sababi — ma’lumotlarning mahalliy nusxasi bilan ishlaydigan ikki yoki undan ortiq mijoz tomonidan bir resursning bir vaqtda o‘zgartirilishi. Oddiy stsenariy: foydalanuvchi A Trello-da vazifani oflayn tahrirlaydi, bir vaqtning o‘zida foydalanuvchi B boshqa qurilmada xuddi shu vazifaning tavsifini o‘zgartiradi. Ikkalasi ham o‘z versiyalarini mahalliy saqlaydi. Qurilmalar tarmoqqa ulanganda server bir maydon uchun ikki xil qiymat oladi.

Qo‘shimcha omillar — tarmoq kechikishlari va tarmoq bo‘linishi (network partition). Raft yoki Paxos protokolidan foydalanadigan tarqalgan ma’lumotlar bazalarida klaster rahbari vaqtincha mavjud bo‘lmaganda va so‘rovlar turli tugunlar tomonidan qayta ishlanganda mojaro yuzaga kelishi mumkin. Amazon DynamoDB whitepaper (2025) ma’lumotlariga ko‘ra, masshtablanadigan NoSQL tizimlaridagi barcha yozish operatsiyalarining taxminan 0,3% aniqlanishi mumkin bo‘lgan mojarolarga olib keladi.

Mojarolar noto‘g‘ri ma’lumot tuzilmasidan ham yuzaga keladi. Agar ilova operatsiyalar hisoblagichi yoki ishtirokchilar ro‘yxatini saqlasa, ikki oflayn mijoz ketma-ket mos kelmaydigan operatsiyalarni bajarishi mumkin. Masalan, mijoz A ro‘yxat oxiriga element qo‘shadi, mijoz B esa o‘rtadan elementni o‘chiradi — sinxronizatsiya paytida server qaysi harakatni birinchi qo‘llashni bilmaydi.

Last Write Wins — vaqt bo‘yicha g‘olib strategiyasi

Last Write Wins (LWW) — raqobatlashuvchi versiyalardan eng oxirgi vaqt belgisiga ega yozuv tanlanadigan strategiya. Tizim har bir versiyaning timestamp-ni solishtiradi va yangisini qabul qilib, eskisini bekor qiladi. Bu deterministik mexanizm: bir xil belgilar to‘plami bilan natija har doim bir xil bo‘lib, noaniqlikni yo‘q qiladi. LWW Firebase Realtime Database, Apache Cassandra va Riak KV da amalga oshirilgan.

Mobil ilovalarda LWW amalga oshirish soddaligi tufayli ayniqsa jozibali. Mijoz versiyalar orasidagi farqni tahlil qilishi, o‘zgarishlar tarixini saqlashi yoki foydalanuvchiga tanlash dialogini ko‘rsatishi shart emas. Server qarorni millisekundlarda qabul qiladi. Biroq LWW ning asosiy kamchiligi bor — ma’lumot yo‘qolishi. Agar ikki foydalanuvchi bir vaqtning o‘zida formaning turli maydonlarini to‘ldirsa, ulardan birining versiyasi butunlay bekor qilinadi.

LWW ning REST API orqali sinxronizatsiya bilan mobil eslatma ilovasida ishlash namunasi:

data class Note(
    val id: String,
    val title: String,
    val content: String,
    val updatedAt: Long
)

fun resolveWithLWW(
    local: Note,
    remote: Note
): Note {
    return if (local.updatedAt >= remote.updatedAt) local
    else remote
}

resolveWithLWW funksiyasi vaqt belgilarini solishtiradi va joriy versiyani qaytaradi. Timestamp teng bo‘lganda (yuqori yozish chastotasida sodir bo‘ladi) odatda mahalliy versiya g‘olib keladi.

Merge Strategy — mojaro versiyalarini birlashtirish

Merge Strategy — tizim versiyalardan birini butunlay bekor qilmaydigan, aksincha ikkalasidagi o‘zgarishlarni kelishilgan holatda birlashtirishga harakat qiladigan yondashuv. Bu Git-da filiallarni birlashtirishga o‘xshaydi: har bir mojaro alohida maydonlar yoki operatsiyalar darajasida hal qilinadi. Merge strategiyalari avtomatik (CRDT, OT) va qo‘lda (foydalanuvchi variant tanlaydi) turlariga bo‘linadi.

Eng mashhur amalga oshirish uch tomonlama birlashtirish (three-way merge) dir. Tizim uch versiyani saqlaydi: mahalliy, masofaviy va ularning umumiy ajdodi (ajralishdan oldingi bazaviy versiya). Agar bir maydonni faqat bitta mijoz o‘zgartirgan bo‘lsa, uning o‘zgarishi avtomatik qabul qilinadi. Agar ikkala mijoz bir maydonni o‘zgartirgan bo‘lsa — hal qilishni talab qiladigan mojaro qayd etiladi. CouchDB va PouchDB hujjatlarni sinxronlash uchun ushbu modeldan faol foydalanadi.

Foydalanuvchi profili uchun uch tomonlama birlashtirishni amalga oshirish namunasi:

data class Profile(
    val name: String,
    val email: String,
    val avatarUrl: String
)

fun threeWayMerge(
    base: Profile,
    local: Profile,
    remote: Profile
): Profile {
    return Profile(
        name = if (local.name != base.name) local.name
                else remote.name,
        email = if (local.email != base.email) local.email
                else remote.email,
        avatarUrl = if (remote.avatarUrl != base.avatarUrl) remote.avatarUrl
                    else local.avatarUrl
    )
}

Uch tomonlama birlashtirish ma’lumot tuzilmasi yetarli darajada barqaror bo‘lganda samarali. Maydon nomlarini o‘zgartirish, turlarni o‘zgartirish va massiv operatsiyalarida muammolar yuzaga keladi — bu hollarda murakkabroq mantiq talab qilinadi.

CRDT — mojarosiz ma’lumot tuzilmalari

CRDT (Conflict-Free Replicated Data Type) — markaziy koordinatorisiz ma’lumotlar konvergentsiyasini kafolatlaydigan matematik model. CRDT shunday loyihalashtirilganki, barcha operatsiyalar kommutativdir: qo‘llash tartibi yakuniy natijaga ta’sir qilmaydi. Bunga algebraik xususiyatlar orqali erishiladi: CRDT ni birlashtirish o‘zgarishlarni qabul qilish tartibidan qat’iy nazar har doim bir xil natijani beradi.

Asosiy CRDT turlariga G-Counter (faqat oshirishni qo‘llab-quvvatlovchi hisoblagich), PN-Counter (oshirish va kamaytirish bilan hisoblagich), LWW-Register (versiyalash bilan registr) va OR-Set (qo‘shish va o‘chirishni kuzatuvchi to‘plam) kiradi. Har bir tur ikki replikani birlashtirishda mojaro yuzaga kelmasligini kafolatlaydi. INRIA tadqiqotiga ko‘ra (Marc Shapiro et al., 2024), CRDT umumiy ma’lumot turlarining 95% uchun deterministik konvergentsiyani ta’minlaydi.

G-Counter namunasi — faqat oshirilishi mumkin bo‘lgan hisoblagich:

class GCounter {
    private val counts = mutableMapOf<String, Int>()

    fun increment(nodeId: String) {
        counts[nodeId] = (counts[nodeId] ?: 0) + 1
    }

    fun value(): Int = counts.values.sum()

    fun merge(other: GCounter) {
        other.counts.forEach { (node, count) ->
            counts[node] = maxOf(counts[node] ?: 0, count)
        }
    }
}

GCounter har bir tugun faqat o‘z hisoblagichini saqlashi va merge har bir tugun uchun maksimalni olishi tufayli birlashtirishning to‘g‘riligini kafolatlaydi. Bu markazlashtirilmagan tizimlarda ishlatiladigan mojarosiz tuzilmaning klassik namunasidir.

Mojarolarni hal qilish strategiyasini qanday tanlash kerak

Strategiya tanlash ma’lumotlarning xarakteri va foydalanish stsenariylariga bog‘liq. LWW eng so‘nggi versiya har doim ustuvor bo‘lgan ilovalar uchun optimal — yangiliklar lentasi, bildirishnomalar, statuslar. Merge Strategy har bir maydon mustaqil bo‘lgan tuzilgan hujjatlar uchun mos — foydalanuvchi profillari, formalar, konfiguratsiyalar. CRDT tarqalgan tizimlarda birgalikda tahrirlash, ro‘yxatlar va hisoblagichlar uchun idealdir.

Strategiyani tanlashda uch omil baholanadi: ma’lumotlar kelishilganligi, samaradorlik va amalga oshirish murakkabligi. LWW maksimal samaradorlik va minimal murakkablikni beradi, ammo ma’lumotlarni yo‘qotishi mumkin. Merge yuqori aniqlikni ta’minlaydi, ammo maydon darajasida o‘zgarishlarni aniqlash mexanizmini talab qiladi. CRDT matematik to‘g‘rilikni kafolatlaydi, ammo ma’lumot turlari va metadata hajmiga cheklovlar qo‘yadi.

Amaliyotda ko‘pincha kombinatsiyalangan yondashuv qo‘llaniladi: tizimlar metadata uchun LWW, hujjatlar mazmuni uchun Merge va ro‘yxat tuzilmalari uchun CRDT dan foydalanadi. Firebase Firestore, masalan, yuqori darajadagi maydonlar uchun LWW qo‘llaydi va atomik yangilanishlar uchun tranzaksiyalarni qo‘llab-quvvatlaydi. CouchDB o‘zgarishlar tarixini saqlagan holda Merge dan foydalanadi. Figma va Notion real vaqtda ko‘p foydalanuvchili tahrirlash uchun CRDT asosidagi arxitektura quradi.