在线协作编辑算法简介- OT算法

 

相信大家或多或少都有使用过在线文档，国内的像我们在做的腾讯文档还有其他家的很多类似产品。今天主要为大家揭开在线协作的神秘面纱，那就是OT算法。

0x01 背景

在线文档，抽象一下，这些产品的模式都是富文本编辑器+后台，富文本编辑器产生内容，展示内容，然后后台负责保存。
富文本编辑器现在业界已经有很多成熟的产品，像codeMirror，这一块本身也是很复杂的一块，也不是咱们这次关注的重点方向。
不知道大家平常在用这些产品的时候有没有思考过一个问题，在线文档编辑的时候产生冲突怎么办？

0x02 举个栗子

举个很简单的例子，现在大家的文本都是‘aaab’，A用户在第3个字符行后面插入了一个‘c’，B用户在第3个字符行后面插入了一个‘d’，这个时候A这边看到的是‘aaacb’，B这边看到的是‘aaadb’,我们假设A用户先提交了数据，那其实最后预期的数据其实应该是‘aaacdb’，这样就最大的保存了每个人的输入。
那我们现在来看看正常情况下这里会发生什么：
A用户：

A本地已经是‘aaacb’了，过一会儿，后台告诉它B也编辑了，编辑的行为就是第3个字符行后面插入了一个‘d’，那A这边执行了这个行为，最终变成了‘aaadcb’

B用户：

B本地已经是‘aaadb’了，过一会儿，后台告诉它A也编辑了，编辑的行为就是第3个字符行后面插入了一个‘c’，那B这边执行了这个行为，最终变成了‘aaacdb’

从上面的模拟过程可以看到，A用户最后的结果其实是不正确的，但是B是正确的。

这里先解释一下大家可能会疑惑的地方：为什么B是过一会儿后台告诉它A编辑了，不是说A先提交了数据吗？
其实这里针对的是冲突场景，这里如果B在提交之前，已经收到后台告诉它A编辑了，那其实就是顺序编辑了，也就不是冲突了。所以这里指的是A，B几乎同时提交，但是A到达后台还是快一点的，也就是A，B在编辑的时候是不知道彼此的存在的。

真实的冲突场景其实不是这种简单的时序问题，这里我后面再介绍。

0x03 尝试解决

这里可能有一些聪明的小伙伴有了一些想法。

解决方案一：丢了丢了

这可能是最简单粗暴的方法了，我发现有冲突，就告诉用户，主子，咱这里有冲突了，臣妾解决不了啊。但是显然这会经常出现，然后主子就把你打入冷宫了。

解决方案二：锁

有些小伙伴想到，上面出现问题，还不是因为大家编辑了都立即应用了，我们编辑后不立即应用不就好了，而且历史告诉我们，有冲突加锁应该可以解决。那我们看看假如不立即应用，咱有没有什么处理办法：
A用户：

A本地已经是‘aaab’了，A编辑了，但是不应用，先发后台

B用户：

B本地已经是‘aaab’了，B编辑了，但是不应用，先发后台

后台：

后台先收到A请求，然后加了一个锁，然后收到了B请求，这时侯应该是加锁的状态，所以接受了A，拒绝了B

A