📌 OT（操作变换）通过服务器端对并发操作进行数学变换，调整操作位置使其在不同客户端执行顺序下产生相同结果，实现一致性。例如，当用户A在位置1插入文本，用户B删除位置2字符时，服务器会调整B的操作位置以适应A的影响。

🔄 CRDT（无冲突复制数据类型）利用数学可交换性，在数据结构层面保证不同节点上的操作任意顺序应用后仍能收敛到一致状态。以RGA为例，每个字符有唯一ID（时间戳+客户端ID），即使并发插入同一位置，也能通过ID排序确定最终顺序。

⚙️ OT的核心是Transform函数，需定义T(op1, op2)为调整op1以适配op2影响，但规则复杂且依赖中心服务器协调，离线冲突合并困难。CRDT则无需中心协调，客户端可离线编辑，同步时自动合并，但存储开销大且算法复杂。

📊 OT适合中心化架构的文本协作，如文档编辑（Google Docs、腾讯文档），性能好但Transform成本高。CRDT适合去中心化/离线场景（Figma、Notion），天然支持离线但元数据较多，内存开销大。

🔄 协同流程：客户端生成操作并本地应用 -> 同步到服务器 -> 服务器执行OT/CRDT合并 -> 广播结果。OT依赖服务器调度，CRDT客户端本地生效。新一代算法如Yjs、Automerge结合两者优势，支持P2P协同。

🚀 一、背景：协同同步问题是什么？

在多人协作（比如多人编辑文档、白板、会议笔记）中，多个客户端同时修改同一份数据。
这会带来典型的并发冲突问题：

A 和 B 同时编辑同一段文字：

A：插入「Hello」B：删除第 3 个字符

如果同步机制不合理，最终文档状态可能不一致。

这类场景要求系统满足以下目标：

为了解决这个问题，业界主要有两类核心算法体系：

✅ OT（Operational Transformation）
✅ CRDT（Conflict-free Replicated Data Type）

🧩 二、OT（Operational Transformation）操作变换

Google Docs、腾讯文档、飞书文档、石墨文档等广泛采用。

1️⃣ 思想核心

客户端在本地立即执行操作（实现“低延迟”）。同步到服务器后，服务器将该操作与其他并发操作进行变换（Transform） 。最终所有客户端应用同样的操作序列后，文档状态一致。

2️⃣ 基本机制

📘 举个例子：

假设文档初始内容为：

abc

用户 A：在第 1 个位置插入 “X” → 操作：Insert(1, "X")用户 B：删除第 2 个字符 → 操作：Delete(2)

两者同时发出操作。

🚦 如果服务器直接按顺序执行：

若先执行 A：文档变成 "aXbc"再执行 B：删除第 2 个字符（现在是 "X"）→ "abc" ✅若先执行 B：文档变成 "ac"再执行 A：插入第 1 个字符 → "aXc" ❌ 结果不一致！

✅ 解决方案：Transform 操作

OT 核心是定义一个 Transform 函数：

T(op1, op2) = 调整 op1 以适配 op2 的影响

例如：

若 B 在 A 之后删除的字符位置发生了偏移，则需要调整 B 的操作位置。

这样最终每个客户端都能在不同的操作顺序下，得到相同的最终状态。

3️⃣ 特点总结

🧮 三、CRDT（Conflict-free Replicated Data Type）

Figma、Notion、Peer-to-Peer 协同系统中广泛使用。

1️⃣ 思想核心

CRDT 是一种数学上可证明“无冲突”的数据结构。
不同节点上的操作可以 任意顺序应用，最终数据自动收敛一致。

换句话说：
每个客户端都可以独立编辑、离线修改，之后同步时系统自动合并结果，无需服务器参与 Transform。

2️⃣ 常见 CRDT 类型

3️⃣ 文本编辑中的 CRDT

以 RGA (Replicated Growable Array) 为例：
每个字符分配一个唯一 ID（时间戳+客户端ID） ，即使并发插入同一位置，也能通过 ID 比较确定顺序。

初始: [a][b][c]客户端 A 插入 X（在 b 后）客户端 B 插入 Y（在 b 后）A 插入位置ID: b.AB 插入位置ID: b.B合并后根据ID顺序排列:[a][b][X][Y][c]

无需服务器协调，自动保持一致。

4️⃣ 特点总结

⚙️ 四、OT vs CRDT 对比总结表

🔄 五、在文档/会议协同系统中的实际架构

典型协同架构示意图：

┌──────────┐│  Client A│───┐└──────────┘   │                ▼          ┌─────────────┐          │ Sync Server │          │  (OT / CRDT)│          └─────────────┘                ▲┌──────────┐   ││  Client B│───┘└──────────┘

协同流程：

1️⃣ 客户端生成本地操作（插入、删除、修改）
2️⃣ 客户端立即应用（乐观更新）
3️⃣ 同步到服务器（或直接 P2P 合并）
4️⃣ 服务器执行 OT / CRDT 合并逻辑
5️⃣ 广播给其他客户端
6️⃣ 所有端最终状态一致

💡 六、面试回答建议（高级开发视角）

面试官可能会问：「你了解协同编辑机制吗？OT / CRDT 有何区别？」

你可以这样答👇：

文档和会议类应用的协同同步机制主要有两类：

OT（Operation Transformation） ：通过服务器对并发操作做位置变换，使得最终结果一致。它实现相对简单，适合中心化架构，如 Google Docs。CRDT（Conflict-free Replicated Data Type） ：通过在数据结构层面内建可交换性，保证各节点操作最终一致，天然支持离线编辑，比如 Figma 和 Notion。

在协同产品中，通常选择 OT + 缓存合并实现在线协作，或者使用基于 CRDT 的新一代算法（如 Yjs、Automerge）支持 P2P 协同。

📘 七、推荐资料与开源实现