Conflict Resolution：策略、合并与工作原理

移动应用中的冲突解决是什么？

冲突解决是将分布式数据在检测到矛盾更改后引导到统一一致状态的过程。在集中式系统中不会产生冲突：服务器顺序处理请求。在具有离线模式的移动应用中，客户端本地修改数据并且后续与服务器同步。如果两个客户端修改了同一对象，服务器将收到两个具有相同标识符但内容不同的版本。

在弱耦合复制（eventual consistency）中冲突是不可避免的，系统为了可用性和性能而牺牲即时一致性。据普林斯顿大学的研究人员（Aggarwal et al.，GEO paper，KDD 2024）称，具有延迟复制的系统在峰值负荷下显示出高券28%的性能，但需要冲突解决机制才能正确运行。

解决策略是一种算法，系统在检测到冲突时自动应用。不同的数据库和框架实现了不同的策略：Firebase Realtime Database使用LWW，CouchDB添加了Merge支持，而Fig据和Notion基于CRDT构建架构。

为什么数据同步时会产生冲突

冲突的主要原因是两个或多个客户端同时修改同一资源，这些客户端使用数据的本地副本工作。典型场景：用户A离线编辑Trello中的任务，同时用户B在另一台设备上修改同一任务的描述。两人都将其版本本地保存。当设备连接到网络时，服务器收到同一字段的两个不同值。

其他因素包括网络延迟和网络分割（network partition）。在使用Raft或Paxos协议的分布式数据库中，当集群领导者暂时不可用且请求由不同节点处理时，可能产生冲突。据Amazon DynamoDB白皮书（2025）称，可扩展NoSQL系统中所有写入操作约0.3%会导致可检测的冲突。

冲突也可能由于不合适的数据结构而产生。如果应用存储操作计数器或参与者列表，两个离线客户端可能执行顺序上不兼容的操作。例如，客户端A在列表末尾添加了元素，而客户端B从中间删除了元素，在同步时服务器不知道应该先应用哪个操作。

Last Write Wins — 按时间决定胜者的策略

Last Write Wins（LWW）是一种策略，从竞争版本中选择具有最新时间戳的记录。系统比较每个版本的时间戳并接受较新的版本，抛弃旧的版本。这是一种确定性机制：在相同的时间戳集合下，结果始终相同，消除了不确定性。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函数比较时间戳并返回当前版本。当时间戳相等时（在高写入频率时发生），通常本地版本胜出。

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构建架构，实现实时多用户编辑。