协同编辑--OT算法之外的世界

协同编辑的三个问题是convergence, causal order and intention preservation.其中Operational transformation算法解决的主要是intention preservation的问题，但是，仅仅将OT算法做对，还远远不能完成一款协同编辑产品。

多人协同编辑时，必须支持客户端之间互相发送和接收编辑操作的消息。无论使用长连接还是Websocket等技术，都需要考虑在通信协议层面能否支持消息的顺序性。即，客户端接收的消息的顺序能否保证与发送时一致。并且，这里需要澄清，客户端的消息传递的顺序性跟后台系统的消息中间件的顺序性是两件事情。消息中间件的顺序性是保证消息中间件的消费者接收消息的顺序性，与客户端的通信协议的顺序性是保证客户端接收到的消息的顺序性。

考虑任意一条操作的消息传递路径如下：消息被后台通信服务收到后先经过OT服务转换，再经过DB服务持久化，最终作为ACK经通信服务广播给相关的客户端，相关的客户端就可以看到对方协同编辑的动作。

 

若定义一条消息从客户端发出到被其他相关客户端接收到的时间间隔为协同编辑的延迟，则协同编辑产品的可用性与延迟反相关。分析消息的处理的全过程，OT服务是CPU-bound的，DB服务是IO-bound，必然瓶颈在于DB服务。

以上是从单条操作的处理流程分析。对于OT算法而言，它要求对于单个文件的所有操作串行处理，所以后台负载的并行化最小粒度是文件级别。大规模用户使用产品编辑的不同文件数目越多，并发度就会越高。同时，对于多租户系统的角度而言，系统需要保证各个不同文件的操作尽量隔离，避免某个文件的操作阻塞其他文件的操作。

那么，能否对延迟进一步优化呢？公司的实践如下图：

在单条消息的处理流程中引入bypass（红色箭头）。既然DB服务的处理耗时，那么可以bypass这个流程，提前将OT服务处理完成的消息广播出去。荡然，最终作为ACK的消息还是会广播出去，以应对可能出现的exception(ACK可以提供消息最终执行结果或出错的相关信息)。

从单条操作的角度看，实践中引入了bypass。从消息驱动的模型出发，这种优化方案实际上是将单条消息流拆分成两个异步的流。

待OT的消息流的throughput必然会高于待写入的消息流，在实践中需要有足够的存储空间去buffer两个流之间的流量差。这个结构也可以生动的体现eventually-consistency的概念，即当第二个流drained-out后，数据库中的数据才会跟客户端的数据一致。

同时，该优化对OT算法，以及操作的设计提出了更高的要求。因为客户端会在本地对收到的消息做OT,而引入bypass后，客户端OT的必然是bypass过来的消息，而不是经数据库处理后的消息，如此，就依赖于bypass的消息中必须包含有支持OT的所有信息。操作设计时，一定要满足这个条件。