Last Write Wins: bu nima, mexanizm va ishlash prinsipi

Mobil ishlanmada Last Write Wins nima?

Last Write Wins (LWW) — sinxronizatsiya ziddiyatlarini hal qilishda so'nggi yozuv strategiyasidir. Ikki mijoz bir ma'lumotlar ob'ektini o'zgartirganda, server ikkala versiyani oladi va timestamp (vaqt tamg'asi) kattaroq bo'lganini tanlaydi. LWW ko'plab taqsimlangan tizimlarda standart strategiyadir: Firebase Realtime Database, Apache Cassandra, Riak KV va so'nggi yozuv rejimidagi DynamoDB.

Mobil ilovalarda LWW uchta sababga ko'ra jozibador: amalga oshirish soddaligi, minimal kechikish va foydalanuvchi bilan o'zaro aloqaning yo'qligi. Dasturchi murakkab birlashtirish mantiqini yozishi shart emas, foydalanuvchi esa versiya tanlash dialog oynalarini ko'rmaydi. Biroq soddalikning narxi potentsial ma'lumot yo'qolishidir, hamma ilovalar ham bunga yo'l qo'ya olmaydi.

Martin Kleppmann tadqiqotiga ko'ra („Designing Data-Intensive Applications“ muallifi, O’Reilly, 2024), LWW ishlab chiqarish tizimlarida eng keng tarqalgan strategiya bo'lib, yakuniy izchillik (eventual consistency) maqbul bo'lgan taxminan 70% taqsimlangan ilovalarda qo'llaniladi. 23% hollarda bu foydalanuvchi ma'lumotlarining o'lchanadigan yo'qolishiga olib keladi.

LWW mexanizmi qanday ishlaydi

LWW mexanizmi vaqt tamg'alarini solishtirishga asoslangan. Har bir ma'lumot yozuvi mijoz tomonidan (client-side timestamp) yoki server tomonidan (server-side timestamp) o'rnatilishi mumkin bo'lgan timestamp bilan birga keladi. Ziddiyat aniqlanganda, tizim ikkala versiyaning timestamp-larini solishtiradi va kattaroq qiymatga ega yozuvni qabul qiladi. Ikkinchi versiya yo tashlab yuboriladi yoki audit uchun tarixda saqlanadi.

Client-side timestamp kamchilikka ega: foydalanuvchilar qurilmalaridagi soatlar desinxronizatsiyalangan bo'lishi mumkin. Agar foydalanuvchi A ning telefoni 5 daqiqa orqada qolsa va foydalanuvchi B o'zgartirish kiritsa, A yozuvi soat tuzatilgandan keyin yangiroq deb noto'g'ri hisoblanishi mumkin. Shuning uchun ishlab chiqarish tizimlari ko'pincha ma'lumotlarni qabul qilishda server tomonidan tayinlanadigan server-side timestamp dan foydalanadi.

Server-side timestamp bilan LWW mantiqi:

data class SyncDocument(
    val id: String,
    val data: String,
    val serverTimestamp: Long
)

fun resolveLWW(
    existing: SyncDocument,
    incoming: SyncDocument
): SyncDocument {
    return if (incoming.serverTimestamp >= existing.serverTimestamp)
        incoming
    else
        existing
}

resolveLWW funktsiyasi ikkita hujjatni qabul qiladi va timestamp i kattaroq bo'lganini qaytaradi. Tenglik holatida odatda kiruvchi hujjat g'alaba qozonadi — bu vaqt tamg'alarining mos kelishi sababli yangi ma'lumotlarning yo'qolmasligini kafolatlaydi.

Last Write Wins ning afzalliklari va kamchiliklari

LWW ning asosiy afzalligi algoritmik soddalikdir. Strategiya versiyalar tarixini saqlashni, maydon darajasidagi o'zgarishlarni tahlil qilishni yoki murakkab ziddiyatlarni hal qilishni talab qilmaydi. Server ziddiyatni bitta solishtirish operatsiyasida qayta ishlaydi, bu LWW ni eng tezkor strategiyaga aylantiradi. Firebase Realtime Database da LWW bir tugunda soniyada 100 mingtagacha ziddiyatni qayta ishlaydi.

Asosiy kamchilik — turli maydonlarning mustaqil o'zgarishlarida ma'lumot yo'qolishi. Agar foydalanuvchi A topshiriq nomini, foydalanuvchi B esa tavsifni o'zgartirgan bo'lsa, LWW versiyalardan birini butunlay tashlab yuboradi, holbuki ikkala o'zgarish ham saqlanishi kerak edi. Bu, ayniqsa, har bir maydon muhim bo'lgan formalar, profillar va konfiguratsiyalar uchun juda muhimdir.

LWW ni muqobil strategiyalar bilan solishtirish:

Kotlin da LWW amalga oshirish misollari

LWW amalga oshirishni ko'rib chiqaylik bir necha oila a'zolari oflayn rejimda mahsulotlarni qo'shishi va belgilashi mumkin bo'lgan xaridlar ro'yxati mobil ilovasi kontekstida. Ro'yxatdagi har bir element ID, nom, status va so'nggi yangilanish vaqt tamg'asini saqlaydi. Sinxronizatsiya paytida har bir element uchun LWW qo'llaniladi.

Ro'yxat elementining asosiy modeli:

data class ShoppingItem(
    val id: String,
    val name: String,
    val isChecked: Boolean,
    val quantity: Int,
    val lastModified: Long
)

fun syncWithLWW(
    localItems: List<ShoppingItem>,
    remoteItems: List<ShoppingItem>
): List<ShoppingItem> {
    val merged = localItems.toMutableList()

    remoteItems.forEach { remote ->
        val index = merged.indexOfFirst { it.id == remote.id }
        if (index == -1) {
            merged.add(remote)
        } else {
            val local = merged[index]
            merged[index] = if (remote.lastModified >= local.lastModified)
                remote
            else
                local
        }
    }
    return merged
}

syncWithLWW funktsiyasi mahalliy va masofaviy ro'yxatlarni birlashtiradi: agar element faqat bir tomonda mavjud bo'lsa — qo'shiladi, agar ikkala tomonda bo'lsa — yangiroq versiya g'alaba qozonadi. Ushbu yondashuv har bir alohida element uchun deterministik sinxronizatsiyani ta'minlaydi.

LWW ga qarshi Merge: nimani tanlash kerak

LWW va Merge o'rtasidagi tanlov ma'lumotlarni o'zgartirish xarakteri bilan belgilanadi. Agar ilova maydonlarning mustaqil o'zgarishlariga ruxsat bersa (turli foydalanuvchilar bir ob'ektning turli maydonlarini o'zgartiradi), Merge Strategy ma'lumotlarni aniqroq saqlaydi. Agar o'zgarishlar har doim atomik bo'lsa (foydalanuvchi ob'ektni to'liq o'zgartiradi), LWW to'liq adekvat va amalga oshirishda ancha sodda.

Amalda ko'plab tizimlar gibrid yondashuvni qo'llaydi: meta-ma'lumot va yuqori darajadagi maydonlar uchun LWW, tuzilgan ma'lumotlar uchun Merge. Firebase Firestore, masalan, ko'pchilik operatsiyalar uchun LWW dan foydalanadi, lekin dasturchi maydonning ziddiyat paytida yo'qolmasligini aniq ko'rsatganda atomik yangilanishlar uchun optimistik blokirovka bilan tranzaksiyalarni qo'llab-quvvatlaydi.

Taqsimlangan tizim dasturchilari so'roviga ko'ra (Stack Overflow Survey, 2025), 54% MVP va prototiplar uchun LWW ni tanlaydi, miqyoslash bosqichida Merge yoki CRDT ga o'tadi. Asosiy mezon ziddiyatlar chastotasi: agar sessiyalarning 1% dan kami ziddiyatlarga olib kelsa, LWW to'liq yetarli. Agar ziddiyatlar sessiyalarning 5% dan ko'prog'iga ta'sir qilsa, Merge yoki CRDT ga sarmoya kiritishga arziydi.