CRDT如何实现多端状态同步？

在分布式协作系统里，用户往往在手机、平板、甚至嵌入式面板上同时编辑同一份数据。若不引入专门的冲突解决机制，网络抖动或离线操作会导致状态分歧。CRDT（Conflict‑free Replicated Data Type）正是为这种“多端同步”场景而生的数学工具。

CRDT 基本原理

CRDT 的核心是把每一次本地写入抽象为可合并的操作，并保证所有副本在任意顺序接收这些操作后得到相同的结果。常见的实现方式分为两类：基于状态的（state‑based，又称 CvRDT）通过周期性广播完整副本；基于操作的（operation‑based，又称 Op‑CRDT）只传递增量操作。两者都遵循幂等、可交换和结合性这三个代数属性，从而在网络分区恢复时自然收敛。

多端冲突的根本原因

冲突往往来源于三点：① 同一步骤在不同设备上并发写入；② 网络延迟导致消息到达顺序被打乱；③ 部分设备可能长时间离线，只在恢复后一次性推送积压的变更。若仅依赖最后写入者覆盖（last‑write‑wins），就会出现用户在手机上看到的状态与实际硬件面板不一致的尴尬局面。

常用 CRDT 类型与实现要点

• G‑Counter：仅增量计数，合并时取最大值。
• PN‑Counter：在 G‑Counter 基础上加负计数实现可减。
• G‑Set：无序集合，合并取并集。
• OR‑Set：带唯一标识的集合，支持添加与删除。
• LWW‑Register：记录时间戳的寄存器，冲突时保留最新写入。
• RGA（Replicated Growable Array）：序列型 CRDT，用于文本或列表的顺序维护。

实际同步流程示例

localOp = {type:'inc', id:uuid(), ts:now()}
apply(localOp)               // 乐观更新本地状态
sendToBroker(localOp)        // MQTT/WS 推送
onMessage(remoteOp) {
    merged = merge(localState, remoteOp)
    render(merged)
}

边缘与云端的协同策略

在资源受限的边缘设备上，完整的状态副本往往占用数百 KiB，这对 128 MiB 内存的微控制器已经是不小的负担。常见做法是让边缘仅保留操作日志，定期把压缩后的日志上传至云端；云端负责持久化全量快照，并在需要时下发给新加入的终端。为了避免“时钟漂移”导致的 LWW 冲突，系统会在每条操作中附带单调递增的版本向量（Version‑Vector），并在合并时比较对应设备的最高序号。这样既能保障离线期间的本地交互流畅，又能在网络恢复后实现毫秒级的全局收敛。

当所有端点都遵循同一套 CRDT 定义时，用户在手机上轻点一个按钮，墙上的面板立刻同步亮起——背后是一套无冲突的数学协议在悄悄工作。