协同编辑的三个问题是convergence, causal order and intention preservation.其中Operational transformation算法解决的主要是intention preservation的问题,但是,仅仅将OT算法做对,还远远不能完成一款协同编辑产品。
多人协同编辑时,必须支持客户端之间互相发送和接收编辑操作的消息。无论使用长连接还是Websocket等技术,都需要考虑在通信协议层面能否支持消息的顺序性。即,客户端接收的消息的顺序能否保证与发送时一致。并且,这里需要澄清,客户端的消息传递的顺序性跟后台系统的消息中间件的顺序性是两件事情。消息中间件的顺序性是保证消息中间件的消费者接收消息的顺序性,与客户端的通信协议的顺序性是保证客户端接收到的消息的顺序性。
考虑任意一条操作的消息传递路径如下:消息被后台通信服务收到后先经过OT服务转换,再经过DB服务持久化,最终作为ACK经通信服务广播给相关的客户端,相关的客户端就可以看到对方协同编辑的动作。
若定义一条消息从客户端发出到被其他相关客户端接收到的时间间隔为协同编辑的延迟,则协同编辑产品的可用性与延迟反相关。分析消息的处理的全过程,OT服务是CPU-bound的,DB服务是IO-bound,必然瓶颈在于DB服务。
以上是从单条操作的处理流程分析。对于OT算法而言,它要求对于单个文件的所有操作串行处理,所以后台负载的并行化最小粒度是文件级别。大规模用户使用产品编辑的不同文件数目越多,并发度就会越高。同时,对于多租户系统的角度而言