Last Write Wins：什么是它，机制和工作原理

移动开发中的 Last Write Wins 是什么？

Last Write Wins (LWW) — 是解决同步冲突时的最后写入策略。当两个客户端修改同一个数据对象时，服务器接收两个版本并选择具有较大时间戳 (timestamp) 的那一个。LWW 是许多分布式系统中的默认策略：Firebase Realtime Database、Apache Cassandra、Riak KV 和 DynamoDB（最后写入模式）。

在移动应用中，LWW 由于三个原因而具有吸引力：实现简单、延迟最小和无用户交互。开发人员不需要编写复杂的合并逻辑，用户也不会看到版本选择对话框。但简单的代价是潜在的数据丢失，并非所有应用程序都能承受。

据 Martin Kleppmann（《Designing Data-Intensive Applications》一书作者，O’Reilly, 2024）的研究，LWW 是生产系统中最广泛使用的策略，大约 70% 的分布式应用程序使用它，这些应用允许最终一致性 (eventual consistency)。在 23% 的情况下，它导致可测量的用户数据丢失。

LWW 机制如何工作

LWW 机制 基于时间戳的比较。每个数据记录都附带一个时间戳，可以由客户端设置 (client-side timestamp) 或服务器设置 (server-side timestamp)。检测到冲突时，系统比较两个版本的时间戳，并接受具有较大值的记录。第二个版本要么被丢弃，要么保存在历史中以供审计。

客户端时间戳有一个缺点：用户设备上的时钟可能不同步。如果用户 A 的手机迟了 5 分钟，而用户 B 进行了修改，那么在时钟纠正后，A 的记录可能被错误地视为更新。因此，生产系统更常使用服务器时间戳，由服务器在接收数据时分配。

使用服务器时间戳的 LWW 逻辑：

data class SyncDocument(
    val id: String,
    val data: String,
    val serverTimestamp: Long
)

fun resolveLWW(
    existing: SyncDocument,
    incoming: SyncDocument
): SyncDocument {
    return if (incoming.serverTimestamp >= existing.serverTimestamp)
        incoming
    else
        existing
}

resolveLWW 函数接收两个文档并返回时间戳较大的那个。如果相等，通常是入库文档胜出——这保证新数据不会因时间戳重叠而丢失。

Last Write Wins 的优缺点

LWW 的主要优点 是算法简单。该策略不需要存储版本历史、分析字段级别的变更或解决复杂冲突。服务器在单次比较操作中处理冲突，这使 LWW 成为最快的策略。在 Firebase Realtime Database 中，LWW 在单个节点上每秒可处理额 10 万次冲突。

主要缺点 — 不同字段独立变更时的数据丢失。如果用户 A 修改了任务名称，用户 B 修改了描述，LWW 将完全丢弃其中一个版本，尽管两个修改都应保留。这对于表单、个人资料和配置来说尤为关键，因为每个字段都很重要。

LWW 与替代策略的比较：

在 Kotlin 中实现 LWW 的示例

让我们考虑 LWW 的实现 在一个移动购物清单应用的上下文中，多个家庭成员可以在离线情况下添加和标记商品。清单中的每个元素存储 ID、名称、状态和最后更新的时间戳。在同步时，LWW 被应用于每个元素。

列表元素的基本模型：

data class ShoppingItem(
    val id: String,
    val name: String,
    val isChecked: Boolean,
    val quantity: Int,
    val lastModified: Long
)

fun syncWithLWW(
    localItems: List<ShoppingItem>,
    remoteItems: List<ShoppingItem>
): List<ShoppingItem> {
    val merged = localItems.toMutableList()

    remoteItems.forEach { remote ->
        val index = merged.indexOfFirst { it.id == remote.id }
        if (index == -1) {
            merged.add(remote)
        } else {
            val local = merged[index]
            merged[index] = if (remote.lastModified >= local.lastModified)
                remote
            else
                local
        }
    }
    return merged
}

syncWithLWW 函数合并本地和远程列表：如果元素只在一边存在——添加，如果两边都存在——较新的版本胜出。这种方法为每个单独的元素提供了确定性同步。

LWW 与 Merge：如何选择

在 LWW 和 Merge 之间选择 取决于数据修改的性质。如果应用允许字段的独立修改（不同用户修改同一对象的不同字段），Merge 策略将更准确地保存数据。如果修改总是原子的（用户修改整个对象），LWW 完全合适且实现起来简单得多。

在实践中，许多系统采用混合方法：LWW 用于元信息和顶层字段，Merge 用于结构化数据。例如，Firebase Firestore 在多数操作中使用 LWW，但支持乐观锁的事务，用于原子更新，当开发人员明确指定字段不应在冲突中丢失时。

据分布式系统开发者调查 (Stack Overflow Survey, 2025)，54% 的人为 MVP 和原型选择 LWW，在扩展阶段转向 Merge 或 CRDT。关键标准是冲突频率：如果会话中冲突发生率低于 1%，LWW 就完全够用。如果冲突影响超过 5% 的会话，就值得投资于 Merge 或 CRDT。