探秘前端 CRDT 实时协作库 Yjs 工程实现

Posted 2022-01-28 前端瓶子君

基础库为前端应用带来了奇妙的可能性：只需要一个 API 与 backbone 几乎一样简单的 model 层，你的应用就能自然地获得对多人协作场景下并发更新的支持。这背后隐藏着怎样的黑魔法呢？本文希望以当下代表前端 CRDT 库性能巅峰的 为例，向大家直观地展示 how CRDT works。

（图为 Yjs 和其他前端主流 CRDT 库的性能对比，Yjs 对应底部的蓝线）

本文会从 Yjs 的工程实现出发，介绍一个典型的工业级 CRDT 库是如何实现以下能力的：

建模数据结构

解决并发冲突

回溯历史记录

同步网络状态

作为一份科普性的介绍，本文不会动辄甩出大段晦涩的源码，也不会涉及多少抽象的数学知识。阅读时只需了解数据结构方面的计算机基础即可。

在实际介绍 Yjs 内部概念前，我们该如何直观地了解 CRDT 库的使用方式呢？Yjs 对使用者提供了如 和 等常用数据类型（即所谓的 会被序列化编码后分发，而基于 CRDT 算法的保证，只要每个客户端最终都能接收到全部的 item，那么不论客户端以何种顺序接收到这些 item，它们都能重建出完全一致的文档状态。

基于上述手段实现的 CRDT 结构是 CRDT 流派中的一种，可以将其称为 的逻辑时间戳，可以认为这就是个从零开始递增的计数器。它的更新规则非常简单：

发生本地事件时，localClock += 1。

在接收到远程事件时，localClock = max(remoteClock, localClock) + 1。

这种机制看似简单，但实际上使我们获得了数学上性质良好的全序结构。这意味着只要再配合比较 clientID 的大小，即可令任意两个 item 之间均可对比获得逻辑上的先后关系，这对保证 CRDT 算法的正确性相当重要。但相关数学理论并非本文重点，在此不再展开。

我们可以借助文本编辑的例子来理解这种 list CRDT 的工作方式。在未经任何优化的朴素情况下，这种结构要求我们把每个字符插入操作都建模为一个 item，也就是每个字符都携带了一个逻辑时间戳 ID：

88BF2B75-CA88-4B67-86B6-F6E390C1C370.png

在上面的例子中，Y A T A ! 这几个字符每个都对应一个 item（或者说一次字符插入的 operation）。它们通过 left 和 right 字段连接在一起。在插入新字符 T 的时候，Yjs 就会根据 item 的 ID 在链表中查找合适的插入位置，将新字符对应的 item 接入链表中。另外同个用户持续追加的文字也会被合并成 length 很长的单个 item，避免大量碎片化对象的性能问题。

注意，在文档的高频增删过程中，并不是所有 item 都会持续存在于链表中。但由于 CRDT 的冲突解决需要依赖历史 item 的元数据，我们并不能直接将历史上的 item 硬删除，至多只能移除掉该 item 对应的 YModel 内容（为此 Yjs 特别设计了 对象来将废弃的 YModel 替换为空结构，相当于一种墓碑机制）。这就带来了下一个问题：该使用怎样的数据结构来存储文档内所有的 item 呢？

由于任意 item 均可用 ID 来排序，因此一种选择是使用 B 树这样具备对数级优良插入和删除时间复杂度的数据结构，将所有的 item 维护在一棵平衡二叉树中。但实践中 Yjs 选择了一种更简单直接的方案，即为每个 client 分配一个扁平的 item 数组，相应的结构被称为 / right / ID 等 CRDT 字段的容器，其中具体的 YModel（或者说 AbstractType）数据会存储在 item.content 字段中，另外还有 parent 和 parentSub 字段会用于辅助表达 YMap 等嵌套结构的父子关系。其整体结构如下所示：

ACC56D75-80BD-4D22-9967-C9E27834844B.png

由于 item.content 也能携带任意的 YMap 等 AbstractType 数据，这样就自然地支持了数据的嵌套。基于这种链式结构，此时一份 YMap 就对应于一系列的 entry，其中每个 key 都使用逻辑时间轴上最新的数据为当前状态，而这个 key 下其他更早的状态所对应的 item 都会被标记为删除。

为了优化本地插入的速度，Yjs 还设计了额外的缓存机制。如果在文档中任意位置随机插入新字符，这时新字符对应的 item 理论上需要 O(N) 的时间复杂度才能插入链表中。但实际上，大多数插入操作都会跟随在用户最后编辑的光标位置。因此 Yjs 默认会缓存 10 个最近的插入位置供快速匹配，在内部实现中这被称为 skip list（作者认为这一缓存机制是受到了跳表的启发）或 fast search marker。

在熟悉了基本的数据结构设计后，我们就可以进一步理解 Yjs 所设计的冲突解决机制了。

和 right 字段，还有这两个字段：

origin 字段存储 item 在插入时的左侧节点。

rightOrigin 字段存储 item 在插入时的右侧节点。

每个 item 在插入文档时都需要执行其 integrate 方法，核心的冲突解决算法就在这里用到了上述这些字段，一共仅有约 20 行：

来提供开箱即用的历史记录管理功能。在个人之前的知乎回答中，的 getter 来检查），但 item 中并没有记录关于删除操作的更多信息：
在 item 中不会记录它时何时被删除，或是被哪个用户删除了。
在 StructStore 中也不会记录删除操作。
在删除发生后，本地的 clock 不会递增。
那么，删除操作的信息是在哪里建模的呢？Yjs 引入了 的概念，可以记录逻辑时间轴上某段时间内（或者说某次 transaction 中）所有被删除的 item，这份数据也会独立于 item 分发。换句话说，Yjs 中的删除操作被设计成了独立于双向链表的结构。在前面关于 item 双向链表的介绍中，我们讨论的还是一个 operation-based CRDT。但在处理删除操作时，Yjs 的设计则相当于一种更简单的 的概念，这是 Yjs 中用于构建事件系统的抽象。每次更新对应的 transaction 都包括两份数据：
这次更新所插入的 item。
这次更新所删除 item 的 DeleteSet。
在网络上实际分发的二进制增量更新数据，就是序列化编码后的 transaction。可以认为 transaction 既会用于编码更新，也是撤销重做操作对应的粒度。基于上述数据结构，可以发现只要做两件事就可以撤销掉一次 transaction：
将这次 transaction 所插入的 item 标记为删除。
将这次更新所删除的 item 标记为恢复。
由于这个过程并不需要新增新的 item，因此这样一来，连续的撤销重做操作在理论上就相当于只需持续分发轻量级 DeleteSet 即可。由于 DeleteSet 的结构非常轻（例如在记录了真实用户 LaTeX 论文编辑过程的 benchmark 数据集中，18.2 万次插入和 7.7 万次删除后仅生成了 4.5KB 的 DeleteSet），这种设计就进一步贴近了「零开销抽象」，因为撤销重做时并没有创造出任何未知的新数据。
不过，个人认为这种设计虽然能起到更极致的优化效果，但也让维护变得更加困难了。如 UndoManager 之前一个难以修复的问题就是「连续撤销 3 次内可重做返回原始状态，4 次以上则可能丢失字段」。这一问题的根源在于当时的实现对 item 复原的逻辑有问题，可能无法连续右移找到应被恢复的正确 item 位置。虽然针对该问题个人已经提交修复 的 tuple。