实时协同编辑架构设计

今天和大家聊一聊协同编辑的设计" title="架构设计">架构设计。

什么是协同编辑

协同编辑是指多人同时对同一份文档进行编辑。

例如我们熟悉的wiki，百度百科，以及办公产品腾讯文档，乃至我们的代码管理工具git，都可以算作是协同编辑产品。

随着大家在家办公，异地办公的情况普及，实时协同编辑工具也变得更加引人注目。

实施协同编辑会面临几个问题：

但是这三个问题会形成一个不可能三角

即任意方案只能满足其中2个点，牺牲第3个点。

有的同学可能对这个三角形不是很理解。

我们可以这样类别，将协同编辑的文档类比为分布式数据库，编辑者类别为数据库的读写服务，那么我们的这个三角形就可以转换为CAP不可能三角

关于CAP定理，可以参见我的博客2020-3-15-一文看懂CAP定理 - huangtengxiao

架构抉择第一件要做的事情是挑出哪些点是必须要满足的，哪些点是可以妥协的。

这里我们会选择实时性和容错性：

那为什么一致性可以妥协呢？

首先我们要基于这一个假设:

在实时协同编辑的场景下，冲突是小概率事件。

就是说大部分情况下，协同编辑的参与者都会在文档的不同部分进行操作，而很少会同时对同一区域进行操作。

因此我们需要处理一致性问题的情况较少。

另外，我们只是放弃强一致性，在各端同步之后，能够较快的恢复到完全一致的状态，实现最终一致性。

如果熟悉Git的同学，就会发现diff-patch和git的版本管理基本一致。

当出现版本冲突时，会通过diff算法计算出，两个版本之间的差异值，然后生成一个patch，将两个版本的内容合并。

这样就能让服务器端和本地端的文档内容重新保持一致。

但是diff-patch这种方式是基于文档内容比较的，那就意味着一旦出现对同一行的操作冲突，就需要人工介入，选择其中一个版本的内容。

例如git，出现合并冲突时，需要开发者对所有冲突部分进行人工处理。否则很容易出现无法运行的代码。

这种方式适用于“编辑——保存——解决冲突”的交互方式，比如kb文档。

但是要处理googledoc或者腾讯文档这样的交互就不合适了。

Operational Transformation方法是将所有的编辑行为封装成一个个的操作。

各个编辑者执行单个操作后，会将操作信息同步到各个协作端。

协作端根据操作的执行时间戳，调整文档状态，保持各端操作顺序的一致性。

注意的一点，Operational Transformation只是一种操作思想，具体的操作实现可以按照业务情况处理。

下面是我思考的两种操作方式：

操作回滚法
在每个操作执行的同时，生成对应的undo，redo方法。
如果发现需要执行更早的操作，那么就先回滚已有晚于新操作时间戳的操作。
然后再按顺序执行新操作，和刚刚回滚的操作。
这种方式对于有全局状态管理的应用来说实现会比较方便，而且服务器的工作量也比较小，只需要进行时间戳的添加，以及消息的转发。