文档协同常见方案
文档协同
文档协同，即多个人同时编辑同一份文档，允许多个用户在不同的设备对同一份文档进行编辑。
随着云计算和互联网技术的发展，文档协同逐渐成为了团队合作、远程办公、在线教育等领域中不可或缺的一部分。通过实时的同步和更新，协同编辑不仅能够提高团队的工作效率，还能够加强成员间的互动和沟通。
关键问题
如何有效地管理多个用户对同一文档的并发操作是文档协同系统需要解决的问题。
- 如何防止冲突?
- 如何保证数据的一致性?
- 如何实时同步文档的修改给其他用户?
常见方案
读写锁
读写锁是一种经典的同步机制，在文档协同场景中用于管理用户对同一份文档的访问权限。其基本思想是通过写锁(Write Lock)和读锁(Read Lock)的划分，控制文档的编辑与查看权限，从而避免冲突、提升协同效率。
- 写锁：当一个用户获取到文档的写锁时，表示该用户正在对文档进行编辑操作。在此期间，系统禁止其他用户对该文档进行修改。
- 读锁：当某个用户正在编辑文档(即文档处于写锁状态)时，其他用户虽然不能对文档进行修改，但仍然可以以只读的方式访问文档内容。系统在逻辑上视这些用户为持有只读访问权限，但不参与写锁的竞争。这种设计确保了数据的一致性，同时提升了并发读取的体验。
- 加锁：某个用户进入编辑状态的时候，系统会为该文档加上写锁。
- 释放：用户已经编辑完了，就会将写锁释放掉。
- 锁的争用：多个用户同时尝试编辑文档，一般来讲即便多个用户同时点击编辑，时间戳还是有细微区别的，可以根据时间戳来判断将写锁给谁。如果时间戳也一样，根据其他的判定条件，例如用户ID。
- 并发读取：多个用户可以并发的去访问文档，但仅仅只是读取，无法修改。
| 分类 | 点位 | 说明 |
|---|---|---|
| ✅ 优点 | 实现简单 | 逻辑清晰，基于互斥锁的方式开发难度较低，容易实现和维护。 |
| 避免冲突 | 通过写锁确保同一时间只有一个用户修改，避免编辑内容发生冲突。 | |
| 读取具备并发性 | 多用户可以同时读取，不影响系统性能。 | |
| ⚠️ 缺点 | 编辑阻塞 | 一个用户加写锁后，其它用户必须等待，无法同时编辑，容易造成“编辑饥饿”。 |
| 用户体验下降 | 编辑时频繁被阻塞或强制等待会降低协作效率，用户体验较差。 | |
| 扩展性有限 | 不适用于大规模用户同时在线编辑，扩展性差，难以满足复杂协同需求。 | |
| 🔧 优化策略 | 锁超时机制 | 如果用户在持锁状态下长时间没有操作，将自动释放锁，避免资源被长时间占用。 |
| 优先队列机制 | 根据请求时间或优先级安排编辑顺序，避免后请求用户长期等待。 | |
| 段级锁定 | 只锁定文档的某一部分(如段落或字段)，允许其他用户编辑未锁定部分，提高并发能力。 | |
| 📘 适用场景 | 对实时性要求不高 | 系统可以接受少量的等待时间或编辑延迟。 |
| 内容稳定、变动频率低 | 例如知识库、制度文档、技术手册等以查看为主，偶尔编辑的场景。 | |
| 强调强一致性 | 如审批流程或制度性文档等需严格保证一致性，读写锁机制能避免并发冲突。 |
读写锁作为一种简单而有效的协作控制机制，在许多文档协同系统的 早期阶段中被广泛采用。它通过在编辑期间对文档加锁，确保仅有一个用户可以进行修改，其余用户则处于只读状态，从而有效防止并发修改造成的数据冲突或内容覆盖。
然而，随着多人协同编辑需求的增强，传统的读写锁机制暴露出诸如编辑阻塞、锁争用、响应延迟等问题，难以满足高并发场景下的流畅体验。为了解决这些问题，现代协同编辑系统逐渐采用更先进的协同方式。
diff-patch
diff-patch 合并通过计算文档差异来合并不同用户的修改:
- diff：比较两个版本的文件之间的差异。
- patch：根据具体的差异来对文档进行更新。
类似于 Git 中合并冲突的过程，如果开发者提供的是增量的代码改动，Git 可以自动的合并，如果是有冲突的代码，那么需要开发者手动介入。
diff-patch 合并方案的工作原理类似于对比两份文档，找出它们之间的变化，然后把这些变化合并成一份最终的文档。
- diff：当多个用户同时编辑文档时，系统会把每个用户的编辑内容与当前的原始文档进行对比，找出这次修改与原文之间的差异。
- patch：在计算出差异之后，系统会生成补丁(patch)，即一种格式化的更新，告诉系统"如何将某个版本的文档更新为另一个版本"。
- 冲突检测与人工合并：对于一些无法自动合并的修改部分，系统会提示用户手动选择如何解决冲突。
| 分类 | 要点 | 说明 |
|---|---|---|
| ✅ 优点 | 实现简单 | 相比 OT 和 CRDT 更加简单，但相对读写锁稍复杂。 |
| 版本可追溯 | 所有更改都通过 diff 存储，可回溯版本变更历史。 | |
| 不阻止并发编辑 | 允许用户同时编辑，增量变更可自动合并，冲突需手动解决。 | |
| 带宽占用小 | 只传输差异内容（diff），节省网络带宽。 | |
| ⚠️ 缺点 | 冲突需人工处理 | 当两个 diff 存在冲突时，系统无法自动合并，需用户处理。 |
| 合并精度有限 | 对复杂结构内容的合并精度不高，易出错。 | |
| 冲突区域难以管理 | 多个用户修改相同区域时难以精确识别冲突位置。 | |
| 📘 适用场景 | 小范围协作编辑 | 如小团队协作、冲突概率低的文档编辑场景。 |
| 结构稳定内容更新 | 适合结构不常变、更新频率低的内容。 | |
| 异步协作 / 离线编辑 | 编辑过程无需实时同步，支持断网编辑后再合并。 | |
| 版本可追溯性要求高 | 注重变更历史可查、需保留操作记录的场景。 |
diff-patch 是一种轻量级、实现成本低的文档协同合并策略，尤其适用于修改频率适中、协同规模有限的非实时协作场景。它支持一定程度的并发编辑，并能清晰标记冲突区域以供人工解决。
尽管在高频编辑、实时性强的多人协同中，其人工干预成本和冲突处理负担较高，但作为"Git 风格"协作的核心组件，diff-patch 仍被广泛用于代码编辑器、版本管理平台、CMS 等工具中，是一种在合理边界内极具性价比的方案。
自动合并
随着协同编辑需求的复杂化，特别是对实时多人编辑的需求逐渐提升，上面两种解决方案无法满足真正意义上的协同编辑。
- 锁机制：限制同时只能一人编辑。
- diff-patch：虽然可行，但需要额外的操作步骤和成本，每次合并需要用户来处理，实时性很差，不适合高频同时修改的场景，特别是针对同一份文档。
于是出现了 OT 和 CRDT 这两种冲突合并算法，专门用于解决冲突，并且自动合并的核心技术，非常适用于文档协同的场景。
OT
英语全称为 Operational Transformation，即操作转换。
OT 是一种专门为多用户协作编辑设计的算法，其的核心思想是：每个用户对文档进行的修改都可以被转换为一系列操作，这些操作在传播给其他用户时，通过变换操作来保证最终的文档一致性。
OT 主要用于需要强实时同步的应用，像 Google Docs 就是基于 OT 实现的。它保证了不同用户的修改可以无缝地合并，而不需要人工干预。
CRDT
英语全称为 Conflict-Free Replicated Data Types，即冲突自由复制数据类型。
其的核心原则是：通过设计一种特殊的数据结构，使得多个副本之间的更新能够自动合并，而不必担心冲突。
在 CRDT 中，每个节点(用户)都会独立地修改文档，然后通过一种合并算法将这些修改同步到其他节点。
CRDT 适用于去中心化和分布式系统的场景，比如多端同步、离线编辑等。它的优势在于能在不依赖集中式服务器的情况下，自动处理文档的并发修改。
| 分类 | 要点 | 说明 |
|---|---|---|
| ✅ 优点 | 自动合并修改 | 减少锁竞争压力，提升用户体验，适用于多人协作避免冲突和阻塞。 |
| 📘 适用场景 | 高并发协同场景 | 如实时协作、去中心化编辑，OT 和 CRDT 是理想方案。 |