real time cooperative editing system

google doc 支持concurrent editing. 多人同时在线编辑同一个文件。本文简单分析一下这种real time cooperative editing system的设计。

首先，这个问题是一个研究领域的热点问题（至少曾经是热点问题）。ACM 有专门的Conference ComputerSupportedCooperativeWork(CSCW). 当然，这是从应用的角度看这个问题。从底层基础的角度看，这是一个distributed replicated system。在各个浏览器中有共同编辑的文件的replica, 后台数据库中有持久化的数据。系统目标是各个浏览器看到的文件是一样的，并且各个浏览器的用户可以随时编辑，replica还需要高响应性，当然，所有的编辑是会保存到后台数据库的。

在分布式中，这个系统目标非常困难。目前实际的系统，会选择实现eventually consistency. 在某个任意的时间点，不保证所有的浏览器上的view是一致的，但是，保证，eventually, 各个浏览器中的数据会是一致的。

基于这样的一致性要求，应该怎么解决这个问题呢？我们从历史上看。80年代有一个很经典的replicated system叫Bayou,当然他不是为了解决上述问题的， 不过他有一个很经典的概念应用，叫做operational transformation. 使用该技术，后续有很多研究就在解决coorperative editing system的问题。

有一篇文章讲的很好，Achieving Convergence, Causality Preservation, and Intention Preservation in Real-Time Cooperative Editing Systems, CHENGZHENG SUN, 1998， 他把达成最终一致性的困难组织成三个， 即如何达到convergence, 如何保持因果序，以及如何达成intention preservation.

这三个问题中最重要的是intention preservation.这也是Operational Transformation 的用武之地。简单讲，对文件的编辑使用的是当前replica view的相对位置（即index）,操作一：在第一行第一列的cell里写1；操作二：在第一行之上添加一行。如果操作二先做，操作一后做，那么操作一的intention被破坏了， 操作一应该改成第二行第一列的cell里写1. OT就是来解决这个问题的，概念上是一种分布式一致性解决方案。读者可以参考wiki. github上有一个介绍很好，https://operational-transformation.github.io/ 。

OT的方案有什么tradeoff呢？我谈谈自己的看法。首先，基于OT的方案把一个分布式系统的运行通过串行的方式改造啦。所有用户的并发的操作最终会串行化成一个顺序的history queue. OT就是一个新操作对history queue的所有较新操作的一一transformation.

从数据库的角度讲，这个方式很自然，即对外支持高并发的系统最终还是要有一个在内部一一处理的过程（欢迎指正）。事实上，问题的困难不在于串行化本身，而在于如何达成串行化。在对一个新操作做OT时， 会读取history queue， 但是要注意的是，理论上，一个操作从开始OT到OT完执行，是需要一个过程的，在OT并执行时，可能history queue本身会有新成员添加。这可能会造成冲突。所以，完成OT甚至需要锁住history queue

也就是说，在具体实现OT时，为了正确性，系统的并发性会大大下降。这就是代价。

关于具体实现的细节，可以参考google自己的文档https://drive.googleblog.com/2010/09/whats-different-about-new-google-docs.html

当然，目前有很多开源的产品可以使用，比如https://github.com/share/ShareJS, https://togetherjs.com/等等。

参考google realtime api( https://developers.google.com/google-apps/realtime/overview), 有两个基本功能：

• Functions to load and work with Realtime documents.
• Events for detecting changes to the collaborative model or collaborators joining or leaving the document.

根据上文分析，协同编辑的产品在后台最终会被串行化并OT以preserve intention。但是，另一方面，各replica需要高响应性。这就意味着，replica呈现的，可能是未被后台确认的操作结果。这就引入了一个operation on the fly的概念。从replica的角度看，它的当前数据，是operation acked和operation on the fly共同作用的结果，并且随着后台传递的ack，不断演进，直到完成eventual consistency。

editing system 一般支持undo.在cooperative editing system中，用户只能undo自己的操作。在做undo操作时，依旧需要使用OT. operation stack会保存本地以及remote的所有操作。undo时，walk down the stack,找到本地的操作，取反，walk up做OT, 最后再执行。

最后，我谈一下OT的局限性－－－数据丢失。假设存在以下情况：在某一共同版本下，网页和tablet同步了。之后，tablet掉线，在掉线的情况下，对worksheet 1 做操作。而同时，网页把worksheet 1 删除了，并且发现失误后undo；这时，在网页看来，什么都没变；在tablet看来，已经对worksheet 1 做了操作；之后，tablet重新连线，并且执行sync， 后台会做Operational Transformation， 先与删除操作OT， 这时，tablet本地的操作在OT后就丢失啦。再与undo操作做Operational Transform， tablet的数据已经丢失，于事无补。