为一个学习类应用设计离线同步：你如何解决冲突？

Question

IT Interview Practice · Accepted Answer

把这个应用当作**离线优先（offline-first）**来对待：每台设备都是一个本地**副本（replica）**。学习行为会写入**本地 DB**以及一个只追加的**op log**（outbox）；重新联网时，设备会**推送自己的 ops**，并**拉取自上次同步以来的服务端变更**。冲突**不是**用一条全局规则来解决，而是根据**每个数据字段的语义**来解决。

**心智模型：**把它想象成 **git**——每台设备在离线时于本地"commit"，而同步是一次**合并（merge）**，而不是覆盖。

## 架构

```text
Device (offline)                        Server = source of truth
┌──────────────────┐   on reconnect     ┌───────────────────────────┐
│ Local DB (SQLite)│  push ops (delta)  │ Sync API  /sync           │
│ + Op log (outbox)│ ─────────────────▶ │  • idempotent by op.id    │
│ cursor = lastSeen│ ◀───────────────── │  • merge by semantics     │
└──────────────────┘  pull changes>cursor└───────────────────────────┘
                                         Progress DB (Postgres)
```

- **本地 DB + op log：**每次变更都是一个**带有客户端生成 id 的不可变 op** + version，在离线期间排队。UI 在本地读写，因此无需网络也能保持流畅。
- **同步服务：**基于 cursor 的**增量（delta）**同步——推送客户端 cursor 之后的 ops，拉取比它更新的变更。每次同步只传输**增量（delta）**，而不是整个数据集 → 5M 用户也依然低成本。
- **冲突解决器：**按每个字段的含义进行合并（见下文）。**服务端是 source of truth**；客户端先解决以保持流畅，然后服务端再重新应用**相同的**确定性合并。

## 冲突解决（核心）

手机时钟**不可靠**，而且两台设备可以在离线时编辑同一条记录，因此**"最后写入者胜出"（LWW）会悄无声息地丢失数据**。要按语义来解决：

- **单调递增字段**（课程进度）→ 取**最大值（max）**。
- **累加计数器**（总学习时长）→ **加上增量（delta）**（CRDT 风格的只增计数器）。
- **真正的"最新状态"**（滚动位置）→ LWW 是可以接受的。

```js
// op 带有一个 id -> 幂等地应用（重试不会重复计数）。clientTs 不可信。
function mergeProgress(server, op) {
  return {
    // progress 只会增加 -> max：迟到的旧 op 永远不会把它往回拖
    progress: Math.max(server.progress ?? 0, op.progress),
    // studiedMs 是累加计数器 -> 加上增量，不要覆盖
    studiedMs: (server.studiedMs ?? 0) + op.studiedMs,
    completedAt: server.completedAt ?? (op.progress >= 1 ? op.clientTs : null),
  };
}
```

在这里，纯 LWW 会让一台迟到同步、携带 `progress: 0.3` 的过期设备**覆盖**服务端的 `0.9` → 进度丢失。取 `max` 并对 `studiedMs` 求和，使同步**与顺序无关（order-independent）**——当数百万台设备带着有偏差的时钟同步时，这样才安全。

## 面试视角

面试官在考察你是否知道**客户端时钟不可信**（所以不能用纯时间戳 LWW）、你是否让**同步具备幂等性（idempotent）**（op ids），以及你是否**按数据含义来合并**。一个**弱**答案："用时间戳，最后写入者胜出。"一个**强**答案：副本 + op log + 幂等性 + 按字段合并 + 服务端作为 source of truth——并且明确指出 LWW 的**数据丢失**故障。

## 权衡

LWW 便宜但会丢数据；语义合并需要针对每个字段思考，但**不会丢失任何东西**。只有当你需要真正的协同编辑（笔记、文档）时，才动用完整的 **CRDT/OT**——它成本很高，所以不要事事都用它。

架构

冲突解决（核心）

面试视角

权衡

相关问题