Conflict Resolution: стратегии, сливане и принцип на работа

Какво е решаването на конфликти в мобилните приложения?

Решаването на конфликти е процесът на привеждане на разпределените данни до единно съгласувано състояние след откриване на противоречиви промени. В централизираните системи конфликти не възникват: сървърът обработва заявките последователно. В мобилните приложения с офлайн режим клиентът променя данните локално и синхронизира с сървъра по-късно. Ако два клиента са променили един и същ обект, сървърът получава две версии с един и същ идентификатор, но различно съдържание.

Конфликтите са неизбежни при слабо свързана репликация (eventual consistency), когато системата жертва незабавната съгласуваност заради наличност и производителност. Според изследователите от Princeton University (Aggarwal et al., GEO paper, KDD 2024), системите с закъсняла репликация показват 28% по-висока производителност при пикови натоварването, но изискват механизми за решаване на конфликти за правилна работа.

Стратегията за решаване е алгоритъм, който системата прилага автоматично при откриване на конфликт. Различните бази от данни и рамки изпълняват различни стратегии: Firebase Realtime Database използва LWW, CouchDB добавя подкрепа за Merge, а Figma и Notion изграждат архитектура на CRDT.

Защо възникват конфликти при синхронизацията на данни

Основната причина за конфликтите са едновременните промени на един и същ ресурс от два или повече клиента, работещи с локално копие на данните. Типичен сценарий: потребителят А редактира задача в Trello офлайн, докато потребителят Б променя описанието на същата задача на друго устройство. И двамата запазват своите версии локално. Когато устройствата се свържат към мрежата, сървърът получава две различни стойности за едно поле.

Допълнителните фактори включват мрежови забавяния и разделяне на мрежата (network partition). В разпределените бази от данни, използващи протокол Raft или Paxos, конфликт може да възникне, когато лидерът на кластъра е временно недостъпен и заявките се обработват от различни възли. Според Amazon DynamoDB whitepaper (2025), около 0,3% от всички операции за запис в мащабируемите NoSQL системи водят до откриваеми конфликти.

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

Last Write Wins — стратегията на победителя по време

Last Write Wins (LWW) — стратегия, при която от конкуриращите версии се избира записът с най-късното времево клетво. Системата сравнява timestamp на всяка версия и приема по-новата, отхвърляйки старата. Това е детерминиран механизъм: с един и същ набор от клетва резултатът е винаги един и същ, което елиминира неопределеността. LWW е изпълнен в Firebase Realtime Database, Apache Cassandra и Riak KV.

В мобилните приложения LWW е особено атрактивен поради простотата на изпълнението. Клиентът няма нужда да анализира разликата между версиите, да съхранява историята на промените или да показва на потребителя диалог за избор. Сървърът взима решение за милисекунди. LWW обаче има фундаментален недостатък — загуба на данни. Ако двама потребители едновременно попълват различни полета на един формуляр, версията на един от тях ще бъде напълно отхвърлена.

Пример за работа на LWW в мобилно приложение за бележки с синхронизация чрез REST API:

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 сравнява времевите клетва и върща актуалната версия. При равни timestamp (което се случва при висока честота на запис) обикновено печели локалната версия.

Merge Strategy — сливане на конфликтни версии

Merge Strategy — подход, при който системата не отхвърля напълно една от версиите, а се опитва да комбинира промените и от двете в едно съгласувано състояние. Това е аналогично на сливането на клонки в Git: всяка конфликт се решава на ниво на отделни полета или операции. Merge стратегиите се разделят на автоматични (CRDT, OT) и ръчни (потребителят избира вариант).

Най-известното изпълнение е трипосочното сливане (three-way merge). Системата съхранява три версии: локална, отдалечена и тяхния общ предшественик (базовата версия преди разделянето). Ако едно поле е било променено само от един клиент, неговата промяна се приема автоматично. Ако и двамата клиента са променили едно и също поле — се записва конфликт, който изисква решаване. CouchDB и PouchDB активно използват този модел за синхронизация на документи.

Пример за изпълнение на трипосочно сливане за потребителски профил:

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

Трипосочното сливане е ефективно, когато структурата на данните е достатъчно стабилна. Проблеми възникват при преименуване на полета, промяна на типове и операции с масиви — в тези случаи се изисква по-сложна логика.

CRDT — структури от данни без конфликти

CRDT (Conflict-Free Replicated Data Type) — математически модел, който гарантира конвергенция на данните без централен координатор. CRDT са проектирани така, че всички операции са комутативни: редът на прилагане не повлиява крайния резултат. Това се постига чрез алгебрични свойства: сливането на CRDT винаги дава един и същ резултат, независимо от реда на получаване на промените.

Основните типове CRDT включват G-Counter (брояч, поддържащ само увеличаване), PN-Counter (брояч с увеличаване и намаляване), LWW-Register (регистър с версиониране) и OR-Set (множество, проследящо добавяне и премахване). Всеки тип гарантира, че при сливане на две реплики няма да възникнат конфликти. Според изследването на INRIA (Marc Shapiro et al., 2024), CRDT осигуряват детерминирана конвергенция за 95% от обикновените типове данни.

Пример за G-Counter — брояч, който може да се само увеличава:

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 гарантира правилността на сливането, тъй като всеки възел съхранява само своя брояч, а merge взима максимума за всеки възел. Това е класически пример за структура без конфликти, използвана в децентрализираните системи.

Как да изберете стратегия за решаване на конфликти

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

При избора на стратегия се оценяват три фактора: консистентност на данните, производителност и сложност на изпълнението. LWW осигурява максимална производителност и минимална сложност, но може да загуби данни. Merge осигурява висока точност, но изисква механизъм за откриване на промени на ниво поле. CRDT гарантира математическа правилност, но налага ограничения върху типовете данни и размера на метаданните.

В практика често се прилага комбиниран подход: системите използват LWW за метаданни, Merge за съдържание на документи и CRDT за списъчни структури. Firebase Firestore, например, прилага LWW за полета на най-горното ниво и подкрепя транзакции за атомни актуализации. CouchDB използва Merge с съхранение на историята на промените. Figma и Notion изграждат архитектура, базирана на CRDT, за многопотребителско редактиране в реално време.