Merge Strategy — какво е, типове сливане и принцип на работа

Какво е Merge Strategy в мобилното разработване?

Merge Strategy — съвкупност от алгоритми, които обединяват конфликтни версии на данни, вместо да изберат една от тях. В мобилните приложения Merge се използва, когато два клиента независимо редактират различни полета или свойства на един обект. Вместо да отхвърли по-старата версия изцяло (както в LWW), системата анализира разликите на ниво отделни полета и формира резултатен обект, съдържащ промени от двете версии.

Ключовата разлика между Merge и LWW — запазване на промените на всеки потребител, при условие че не си противоречат. Ако потребител A е променил името на задачата, а потребител B — описанието, Merge ще запази и двете промени. Ако и двамата са променили едно и също поле — се регистрира конфликт, който изисква разрешаване. Това прави Merge предпочитан за приложения, където потребителите работят заедно с едни и същи данни.

Според доклада на Stripe Engineering Blog (2025), внедряването на Merge Strategy вместо LWW намали броя на жалбите на потребителите за загуба на данни с 76% в тяхното мобилно приложение за управление на проекти. Времето за обработка на конфликти обаче се увеличи с 15–30 ms, което се счита за приемлива цена за запазване на информацията.

Тристранно сливане: как работи механизмът

Тристранно сливане (three-way merge) — най-разпространената имплементация на Merge Strategy. Механизмът оперира с три версии на данни: базова (base — състояние преди разминаване), локална (local — версия на текущия клиент) и отдалечена (remote — версия от сървъра). Системата сравнява всяко поле от локалната и отдалечената версия с базовата, за да определи коя страна е променила кои полета.

Логиката за вземане на решения е проста: ако поле е променено само от един клиент (спрямо базата), неговата промяна се приема автоматично. Ако и двамата клиенти са променили едно и също поле — се регистрира конфликт, който може да бъде разрешен автоматично (по приоритет) или предаден на потребителя. Ако никой от клиентите не е променил поле — остава базовата стойност. Този подход гарантира, че независимите промени не се губят и не конфликтират.

Алгоритъм за тристранно сливане на ниво речник на полета:

fun threeWayMerge(
    base: Map<String, Any?>,
    local: Map<String, Any?>,
    remote: Map<String, Any?>
): Map<String, Any?> {
    val result = base.toMutableMap()
    val allKeys = base.keys + local.keys + remote.keys

    allKeys.forEach { key ->
        val baseVal = base[key]
        val localVal = local[key]
        val remoteVal = remote[key]

        result[key] = when {
            localVal == baseVal -> remoteVal
            remoteVal == baseVal -> localVal
            localVal == remoteVal -> localVal
            else -> // истински конфликт
                resolveConflict(key, localVal, remoteVal)
        }
    }
    return result
}

Функцията threeWayMerge последователно обработва всички ключове от трите версии. Ако локалната стойност съвпада с базовата — се приема отдалечената промяна. Ако отдалечената стойност съвпада с базовата — се приема локалната промяна. Ако и двете се различават от базата, но са равни помежду си — всяка една. Истински конфликт се регистрира само при различни промени от двете страни.

Автоматично и ръчно разрешаване на конфликти

Автоматично разрешаване се прилага, когато промените не се припокриват или когато системата може да определи правилната стойност въз основа на правила. Например за числови полета може да се избере максималната стойност, за текстови полета — конкатенация или по-нова версия. CouchDB използва автоматично сливане за полета на JSON документ, а за масиви — конкатенация с премахване на дубликати.

Ръчно разрешаване е необходимо, когато двама потребители са променили едно и също поле по различен начин. В този случай приложението показва диалог с три опции: „приеми локалната версия“, „приеми отдалечената версия“ или „слей ръчно“. Авторите на изследването на CMU (Carnegie Mellon University, 2024) отбелязват, че ръчното разрешаване намалява удовлетвореността на потребителите с 40%, поради което автоматичното сливане трябва да бъде максимизирано.

Стратегии за разрешаване за различни типове полета:

Примери за имплементация на сливане в Kotlin

Нека разгледаме имплементацията на Merge Strategy за потребителски профил в мобилно приложение със синхронизация чрез REST API. Профилът съдържа име, имейл, аватар и настройки за известия. Всяко поле може да бъде променено независимо на различни устройства на потребителя.

Data-клас на профила с версиониране на ниво полета:

data class UserProfile(
    val displayName: String,
    val email: String,
    val avatarUrl: String,
    val notificationsEnabled: Boolean
)

data class ProfileSnapshot(
    val profile: UserProfile,
    val version: Int
)

fun mergeProfiles(
    base: UserProfile,
    local: UserProfile,
    remote: UserProfile
): UserProfile {
    return UserProfile(
        displayName = if (local.displayName != base.displayName)
            local.displayName else remote.displayName,
        email = if (local.email != base.email)
            local.email else remote.email,
        avatarUrl = if (remote.avatarUrl != base.avatarUrl)
            remote.avatarUrl else local.avatarUrl,
        notificationsEnabled = if (local.notificationsEnabled != base.notificationsEnabled)
            local.notificationsEnabled
        else remote.notificationsEnabled
    )
}

Функцията mergeProfiles независимо обработва всяко поле на профила, избирайки версията, която се различава от базовата. При конфликт (и двете се различават от базата) приоритетът се определя от правилата на приложението. В примера за avatarUrl приоритет се дава на отдалечената версия, за останалите полета — на локалната.

Merge Strategy в базите данни на мобилни приложения

CouchDB и PouchDB — най-известните бази данни с вградена поддръжка на Merge Strategy. При репликация на документи CouchDB използва многонишкова репликация с откриване на конфликти на ниво документ. Базовата версия се съхранява в историята на ревизиите, а при конфликт системата запазва всички конфликтни клонове и предоставя на приложението API за разрешаването им чрез механизма за сливане.

В Firebase Firestore Merge е имплементиран чрез транзакции с оптимистично блокиране. Разработчикът може да посочи, че определени полета трябва да се актуализират атомарно, използвайки FieldValue.serverTimestamp() и FieldValue.arrayUnion(). Въпреки това, Firestore не поддържа пълно тристранно сливане — при конфликт транзакцията се повтаря с нови данни, което е еквивалентно на повторен опит, а не на истинско сливане.

За мобилни приложения на Kotlin Multiplatform и React Native Merge Strategy се имплементира от клиентска страна. Локалната база данни (SQLite, Realm) съхранява версията на всеки документ, а при синхронизация клиентът зарежда версията от сървъра и изпълнява сливането локално преди изпращане на резултата. Този подход осигурява запазване на данните дори при продължителна офлайн работа, когато се натрупват повече конфликти.