Last Write Wins: bu nədir, mexanizm və iş prinsipi

Mobil inkişafda Last Write Wins nədir?

Last Write Wins (LWW) — sinxronizasiya konfliktlərini həll edərkən son yazı strategiyasıdır. İki müştəri eyni məlumat obyektini dəyişdikdə, server hər iki versiyanı alır və daha böyük vaxt damğası (timestamp) olanı seçir. LWW bir çox paylanmış sistemdə standart strategiyadır: Firebase Realtime Database, Apache Cassandra, Riak KV və son yazı rejimində DynamoDB.

Mobil tətbiqlərdə LWW üç səbəbdən cəlbedicidir: implementasiya sadəliyi, minimal gecikmə və istifadəçi ilə qarşılıqlı əlaqənin olmaması. Tərtibatçı mürəkkəb birləşmə məntiqi yazmalı deyil, istifadəçi isə versiya seçimi dialoqları görmür. Lakin sadəliyin qiyməti potensial məlumat itkisidir ki, bütün tətbiqlər özünə verə bilməz.

Martin Kleppmann-ın tədqiqatına görə („Designing Data-Intensive Applications” müəllifi, O’Reilly, 2024), LWW istehsal sistemlərində ən geniş yayılmış strategiyadır və son nəticədə ardıcıllığın (eventual consistency) məqbul olduğu təxminən 70% paylanmış tətbiqlərdə istifadə olunur. 23% hallarda bu, istifadəçilərin məlumat itkisinə səbəb olur.

LWW mexanizmi necə işləyir

LWW mexanizmi vaxt damğalarının müqayisəsinə əsaslanır. Hər məlumat yazısı müştəri tərəfindən (client-side timestamp) və ya server tərəfindən (server-side timestamp) təyin edilə bilən timestamp ilə müşayiət olunur. Konflikt aşkar edildikdə, sistem hər iki versiyanın timestamp-ni müqayisə edir və daha böyük dəyərə malik yazını qəbul edir. İkinci versiya ya atılır, ya da audit üçün tarixçədə saxlanılır.

Client-side timestamp-in çatışmazlığı var: istifadəçilərin cihazlarındakı saatlar sinxronizasiyadan çıxa bilər. Əgər istifadəçi A-nın telefonu 5 dəqiqə geri qalırsa və istifadəçi B dəyişiklik edirsə, saat düzəldildikdən sonra A-nın yazısı səhvən daha yeni hesab edilə bilər. Buna görə istehsal sistemləri daha çox server tərəfindən təyin edilən server-side timestamp istifadə edir.

Server-side timestamp ilə LWW məntiqi:

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 funksiyası iki sənədi qəbul edir və timestamp-i daha böyük olanı qaytarır. Bərabərlik halında adətən daxil olan sənəd qalib gəlir — bu, vaxt damğalarının üst-üstə düşməsi səbəbindən yeni məlumatların itirilməməsini təmin edir.

Last Write Wins-in üstünlükləri və çatışmazlıqları

LWW-nin əsas üstünlüyü alqoritmik sadəlikdir. Strategiya versiya tarixçəsinin saxlanmasını, sahə səviyyəsində dəyişikliklərin təhlilini və ya mürəkkəb konfliktlərin həllini tələb etmir. Server konflikti bir müqayisə əməliyyatı ilə həll edir ki, bu da LWW-ni ən sürətli strategiya edir. Firebase Realtime Database-də LWW bir qovşaqda saniyədə 100 minə qədər konflikti emal edir.

Əsas çatışmazlıq — müxtəlif sahələrin müstəqil dəyişiklikləri zamanı məlumat itkisidir. Əgər istifadəçi A tapşırığın adını, istifadəçi B isə təsvirini dəyişdisə, LWW versiyalardan birini tamamilə atacaq, halbuki hər iki dəyişiklik saxlanmalı idi. Bu, xüsusilə hər sahənin əhəmiyyətli olduğu formalar, profillər və konfiqurasiyalar üçün kritikdir.

LWW-nin alternativ strategiyalarla müqayisəsi:

Kotlin-də LWW implementasiya nümunələri

LWW implementasiyasını nəzərdən keçirək bir ailə üzvlərinin oflayn rejimdə məhsul əlavə edib qeyd edə biləcəyi alış-veriş siyahısı mobil tətbiqi kontekstində. Siyahının hər elementi ID, ad, status və son yenilənmə vaxt damğasını saxlayır. Sinxronizasiya zamanı hər element üçün LWW tətbiq edilir.

Siyahı elementinin əsas 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 funksiyası yerli və uzaq siyahıları birləşdirir: element yalnız bir tərəfdə varsa — əlavə edilir, hər iki tərəfdə varsa — daha yeni versiya qalib gəlir. Bu yanaşma hər bir fərdi element üçün deterministik sinxronizasiyanı təmin edir.

LWW vs Merge: nəyi seçməli

LWW və Merge arasında seçim məlumat modifikasiyasının xarakteri ilə müyən olunur. Əgər tətbiq sahələrin müstəqil dəyişikliklərinə icazə verirsə (müxtəlif istifadəçilər eyni obyektin müxtəlif sahələrini dəyişir), Merge Strategy məlumatları daha dəqiq qoruyacaq. Dəyişikliklər həmişə atomdırsa (istifadəçi obyekti tamamilə dəyişir), LWW tamamilə adekvatdır və implementasiyada çox daha sadədir.

Praktikada bir çox sistem hibrid yanaşma tətbiq edir: meta-məlumat və yuxarı səviyyəli sahələr üçün LWW, strukturlaşdırılmış məlumatlar üçün Merge. Firebase Firestore, məsələn, əksər əməliyyatlar üçün LWW istifadə edir, lakin tərtibatçı sahənin konflikt zamanı itirilməməli olduğunu açıqca göstərdikdə atom yeniləmələr üçün optimist bloklama ilə tranzaksiyaları dəstəkləyir.

Paylanmış sistem tərtibatçılarının sorğusuna görə (Stack Overflow Survey, 2025), 54% MVP və prototiplər üçün LWW seçir, miqyaslama mərhələsində isə Merge və ya CRDT-yə keçir. Əsas meyar konflikt tezliyidir: sessiyaların 1%-dən azı konfliktlə nəticələnirsə, LWW tamamilə kifayətdir. Konfliktlər sessiyaların 5%-dən çoxunu təsir edirsə, Merge və ya CRDT-yə investisiya etməyə dəyər.