Conflict Resolution: strategiyalar, birləşmə və iş prinsipi

Mobil tətbiqlərdə konfliktlərin həlli nədir?

Konfliktlərin həlli — ziddiyyətli dəyişikliklər aşkarlanmasından sonra paylanmış məlumatların vahid ardıcıl vəziyyətə gətirilməsi prosesidir. Mərkəzləşdirilmiş sistemlərdə konfliktlər yaranmır: server sorğuları ardıcıl emal edir. Oflayn rejimli mobil tətbiqlərdə müştəri məlumatları lokal olaraq dəyişdirir və daha sonra serverlə sinxronlaşdırır. İki müştəri eyni obyekti dəyişdiribsə, server eyni identifikatora lakin fərqli məzmuna malik iki versiya alır.

Konfliktlər zəif əlaqəli replikasiyada (eventual consistency) qaçınılmazdır, sistem ani ardıcıllığı əlçatanlıq və performans naminə qurban verir. Princeton University tədqiqatçılarına görə (Aggarwal et al., GEO paper, KDD 2024), gecikmiş replikasiyalı sistemlər pik yüklərdə 28% daha çox performans göstərir, lakin düzgün işləmə üçün konflikt həll mexanizmləri tələb edir.

Həll strategiyası sistemin avtomatik tətbiq etdiyi alqoritmdir. Müxtəlif verilənlər bazaları və freymvorklar fərqli strategiyalar həyata keçirir: Firebase Realtime Database LWW istifadə edir, CouchDB Merge dəstəyini əlavə edir, Figma və Notion isə arxitekturanı CRDT əsasında qurur.

Məlumat sinxronizasiyası zamanı konfliktlər niyə yaranır

Konfliktlərin əsas səbəbi — məlumatların lokal surəti ilə işləyən iki və ya daha çox müştəri tərəfindən eyni resursun eyni vaxtda dəyişdirilməsidir. Tipik ssenari: istifadəçi A Trello-da tapşırığı oflayn redaktə edir, eyni zamanda istifadəçi B başqa cihazda eyni tapşırığın təsvirini dəyişdirir. Hər ikisi öz versiyalarını lokal saxlayır. Cihazlar şəbəkəyə qoşulduqda server eyni sahə üçün iki fərqli dəyər alır.

Əlavə amillər — şəbəkə gecikmələri və şəbəkə bölünməsidir (network partition). Raft və ya Paxos protokolu istifadə edən paylanmış verilənlər bazalarında klaster lideri müvəqqəti əlçatmaz olduqda və sorğular müxtəlif qovşaqlar tərəfindən emal edildikdə konflikt yarana bilər. Amazon DynamoDB whitepaper (2025) məlumatlarına görə, miqyaslana bilən NoSQL sistemlərində bütün yazma əməliyyatlarının təxminən 0,3%-i aşkar edilə bilən konfliktlərə səbəb olur.

Konfliktlər hççinin yanlış məlumat strukturundan yaranır. Tətbiq əməliyyat sayını və ya iştirakçı siyahısını saxlayırsa, iki oflayn müştəri ardıcıl olaraq uyğun olmayan əməliyyatlar həyata keçirə bilər. Məsələn, müştəri A siyahının sonuna element əlavə edir, müştəri B isə ortadan elementi silir — sinxronizasiya zamanı server hansı hərəkətin əvvəlcə tətbiq ediləcəyini bilmir.

Last Write Wins — zamana görə qalib strategiyası

Last Write Wins (LWW) — rəqabət edən versiyalardan ən son vaxt damğasına malik yazının seçildiyi strategiyadır. Sistem hər versiyanın timestamp-ni müqayisə edir və daha yenisini qəbul edib köhnəsini ləğv edir. Bu deterministik mexanizmdir: eyni damğa dəsti ilə nəticə həmişə eynidir, qeyri-müyyənliyi aradan qaldırır. LWW Firebase Realtime Database, Apache Cassandra və Riak KV-də tətbiq edilmişdir.

Mobil tətbiqlərdə LWW tətbiq sadəliyinə görə xüsusilə cəlbedicidir. Müştəri versiyalar arasındakı fərqi təhlil etməli, dəyişiklik tarixçəsini saxlamalı və ya istifadəçiyə seçim dialoqu göstərməlidir. Server qərarı millisaniyələr ərzində qəbul edir. Lakin LWW-nin əsas çatışmazlığı var — məlumat itkisi. İki istifadəçi eyni vaxtda formanın müxtəlif sahələrini doldurursa, onlardan birinin versiyası tamamilə ləğv ediləcək.

LWW-nin REST API vasitəsilə sinxronizasiya ilə mobil qeyd tətbiqində işləmə nümunəsi:

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 funksiyası vaxt damğalarını müqayisə edir və aktual versiyanı qaytarır. Timestamp bərabər olduqda (yüksək yazma tezliyində baş verir) adətən lokal versiya qalib gəlir.

Merge Strategy — konflikt edən versiyaların birləşməsi

Merge Strategy — sistemin versiyalardan birini tamamilə ləğv etmədiyi, əksinə hər ikisindən dəyişiklikləri ardıcıl vəziyyətdə birləşdirməyə çalışdığı yanaşmadır. Bu Git-də budaqların birləşməsinə bənzəyir: hər konflikt ayrı-ayrı sahələr və ya əməliyyatlar səviyyəsində həll edilir. Merge strategiyaları avtomatik (CRDT, OT) və əl ilə (istifadəçi variant seçir) bölünür.

Ən tanınmış tətbiq üçtərəfli birləşmədir (three-way merge). Sistem üç versiya saxlayır: lokal, uzaq və onların ortaq əcdadı (ayrılmadan əvvəlki baza versiyası). Bir sahəni yalnız bir müştəri dəyişdiribsə, onun dəyişikliyi avtomatik qəbul edilir. Hər iki müştəri eyni sahəni dəyişdiribsə — həll tələb edən konflikt qeydə alınır. CouchDB və PouchDB sənədlərin sinxronizasiyası üçün bu modeldən fəal istifadə edir.

İstifadəçi profili üçün üçtərəfli birləşmənin tətbiq nümunəsi:

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
    )
}

Üçtərəfli birləşmə məlumat strukturu kifayət qədər sabit olduqda effektivdir. Sahə adlarının dəyişdirilməsi, tiplərin dəyişdirilməsi və massiv əməliyyatları zamanı problemlər yaranır — bu hallarda daha mürəkkəb məntiq tələb olunur.

CRDT — konfliktsiz məlumat strukturları

CRDT (Conflict-Free Replicated Data Type) — mərkəzi koordinator olmadan məlumatların konvergensiyasına zəmanət verən riyazi modeldir. CRDT elə dizayn edilmişdir ki, bütün əməliyyatlar kommutativdir: tətbiq ardıcıllığı son nəticəyə təsir etmir. Bu cəbri xüsusiyyətlər sayəsində əldə edilir: CRDT-nin birləşməsi dəyişikliklərin alınma ardıcıllığından asılı olmayaraq həmişə eyni nəticəni verir.

Əsas CRDT növlərinə G-Counter (yalnız artırmaçı dəstəkləyən sayıcı), PN-Counter (artırma və azaltma ilə sayıcı), LWW-Register (versiyalaşdırma ilə registr) və OR-Set (əlavə və silməni izləyən çoxluq) daxildir. Hər növ iki replikanın birləşməsi zamanı konflikt yaranmayacağına zəmanət verir. INRIA tədqiqatlarına görə (Marc Shapiro et al., 2024), CRDT məşhur məlumat tiplərinin 95%-i üçün deterministik konvergensiya təmin edir.

G-Counter nümunəsi — yalnız artırıla bilən sayıcı:

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 hər qovşağın yalnız öz sayıcısını saxlaması və merge-in hər qovşaq üçün maksimum götürməsi sayəsində birləşmənin düzgünlüyünə zəmanət verir. Bu, mərkəzləşdirilməmiş sistemlərdə istifadə edilən konfliktsiz strukturun klassik nümunəsidir.

Konfliktlərin həlli strategiyasını necə seçməli

Strategiya seçimi məlumatların xarakterindən və istifadə ssenarilərindən asılıdır. LWW ən son versiyanın həmişə prioritet olduğu tətbiqlər üçün optimaldır — xəbər lenti, bildirişlər, statuslar. Merge Strategy hər sahənin müstəqil olduğu strukturlaşdırılmış sənədlər üçün uyğundur — istifadəçi profilləri, formalar, konfiqurasiyalar. CRDT paylanmış sistemlərdə birgə redaktə, siyahılar və sayıcılar üçün idealdır.

Strategiya seçərkən üç amil qiymətləndirilir: məlumat ardıcıllığı, performans və tətbiq mürəkkəbliyi. LWW maksimal performans və minimal mürəkkəblik təmin edir, lakin məlumat itirə bilər. Merge yüksək dəqiqlik təmin edir, lakin sahə səviyyəsində dəyişiklik aşkarlama mexanizmi tələb edir. CRDT riyazi düzgünlüyə zəmanət verir, lakin məlumat tipləri və metadatanın ölçüsü ilə bağlı məhdudiyyətlər qoyur.

Praktikada tez-tez kombinə edilmiş yanaşma tətbiq olunur: sistemlər metadata üçün LWW, sənəd məzmunu üçün Merge və siyahı strukturları üçün CRDT istifadə edir. Firebase Firestore, məsələn, üst səviyyəli sahələr üçün LWW tətbiq edir və atom yeniləmələr üçün tranzaksiyaları dəstəkləyir. CouchDB dəyişiklik tarixçəsini saxlayaraq Merge istifadə edir. Figma və Notion real vaxtda çoxistifadəçi redaktə üçün CRDT əsaslı arxitektura qurur.