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 для многопользовательского редактирования в реальном времени.