Operational Transformation算法图解

Operational Transformation算法解决的问题是如何merge基于相同的状态产生的不同的操作序列。如下图所示,从上往下看,基于相同的起点,左右有两个操作OP1和OP2.为了merge两个操作为一体,我们可以从两个方向入手,一个方向是从OP1入手,在执行完OP1后,执行OP2;另一个方向是从OP2入手,在执行完OP2后,执行OP1.但是,简单的将操作执行,并不正确,以OP1为例,在执行完OP1后,数据的状态发生了变化,而OP2是基于初始的状态,所以不能直接执行OP2,而需要将操作做一个变换,以OT(OPA,OPB)作为记号。使用OT算法后,必须保证,左边的执行序列OP1,OT(OP2,OP1)执行后的结果,与右边的执行序列OP2,OT(OP1,OP2)执行后的结果相同。

上图是对一个【元操作】的定义。真是的场景中,左边和右边不可能仅仅有一个操作,而是有多个操作。我们先考虑左边有两个操作,右边只有一个操作。如下图所示。


OP1和OP3最先merge。图中到达中轴线的节点。之后,需要将OP2merge进去,必须执行OT(OP2,OP3‘)== OT(OP2, OT(OP3, OP1))

再考虑左边有三个操作,右边只有一个操作。如下图所示。


按照左上-右下的辅助线,把merge过程切割成若干步骤。第一步是在右操作为OP4时mergeOP1,第二步是在右操作为OP4‘时mergeOP2.第三步是在右操作为OP4‘’时mergeOP3。以此类推,可以将merge【左N右1】过程理解成一个递归算法。


上文求解的是左边有若干操作,右边只有一个操作的情形。我们继续扩展,考虑左边有若干操作,右边也有若干操作的情形。如下图所示。



按照右上-左下的辅助线,我们可以将这种求解分割成若干步骤的merge【左N右1】。第一步,左N指的是OP1,OP2,右1指的是OP3.第二步,左N指的是OP1‘,OP2’,右1指的是OP4.以此类推,我们可以将merge【左N右M】的过程理解成一个递归算法。


至此为止,我们将最通用的merge【左N右M】的算法一步步分解下来。下面,我们再考虑一个基本问题,OT(OPA,OPB)指的是基于OPB,对OPA做转换,转换的结果是OPA‘。如果转换的结果不是一个操作OPA’,而是一个操作序列「OPA1,OPA2……」呢?如下图所示。



OT(OP4,OP1)的结果是「OP41,OP42」。求解步骤,首先是求解出OP1‘,将问题缩小为左边「OP2,OP3」,右边为「OP41,OP42」。然后将问题抽象为【左2右2】,先求解【左2右1】,得到「OP2’,OP3‘」;然后将问题缩小为【左2右1】,左为「OP2‘,OP3’」,右为OP42.最终求出结果。

现在,我们分析了所有的问题种类。我们可以分析一个具体问题。

在真实场景中,操作OPA和操作OPB可能是互斥的。因此,OT算法往往是biased OT,即以某一个方向为倾向,假设我们的OT是向右方向biased,为了保证对于互斥的操作,OT算法的正确性,我们可以定义如图所示的【元操作】。



因为现在的OT是向右方向倾斜的,所以对于互斥的操作,OP2更优先,所以,只能将OP1变换成空操作(null),而OT(OP2,OP1)必须撤销OP1的影响,并施加OP2的影响。所以我们引入Reverse()操作,即求一个操作的逆操作。

在merge【左N右M】的情形下,出现互斥的情况,就可以使用上述的元操作进行解决。

行文至此,我们通过引入Reverse()操作,解决了互斥操作的OT问题。我们继续加以引申,既然我们接受并引入了Reverse()操作,OT算法本身就变得足够灵活,可以应对更复杂的操作对的OT.考虑操作OPA和OPB。有属性如下:若OPA已执行,则OPB不可执行;若OPB已执行,则OPA可执行。正常的OT示意图如下图所示:



显然,该OT组合是错误的。为了使OT组合正确,我们可以使用Reverse()功能。


如图所示,我们可以发现,只要求出了右方向的OPA’,那么我们就可以通过Reverse()操作和该OPA',组合成操作序列{Reverse(OPA), OPB, OPA'},该序列就是左方向的OT(OPB, OPA)的结果.

将该结论推广开,我们完全只需要提供单个方向的OT变换方法,就可以自动得到另一个方向的OT变换方法。但是,代价也是高昂的,那就是,普通的OT变换结果还是一个操作,而上述方法的结果是三个操作,导致performance会有成倍的下降。实践中,这种tradeoff往往发生在某个OT方法过于复杂时。

OT算法自诞生以来已经超过了三十年,在协同编辑的产品中广泛应用,各种开源实现在GitHub上都能找到,Google spreadsheet也是基于这项技术。

先有Operation,再有Operational Transformation。OT算法实现的优劣,首先依赖于Operation设计的优劣。对于协同编辑产品的操作,我以为,应该是面向OT的设计,即在设计时,本着更有利于OT算法的实现的原则为第一,有利于减少网络传输量的原则为第二。当然,在设计时,更要遵从基本原则,即操作A与操作B应该是正交关系,要尽量避免操作定义中的冗余信息。

OT算法是一个计算密集型的算法,而应用在协同编辑产品中,协同编辑又讲究high responsiveness,这就造成了一个天然的矛盾。尤其在mobile的协同编辑产品中,mobile的计算能力相比桌面产品更加有限。所以,我以为,OT算法的实践尤其需要调优。我们测试了iOS版本的Google spreadsheet产品,在长度为8的操作序列与长度为8的操作序列merge时,就可以出现明显的UI卡顿。

另外,对Google spreadsheet的测试,还可以发现Google的优化思路。协同编辑产品都支持撤销与重做,而撤销与重做的操作也是需要进行OT变换的,这意味着需要一定的CPU消耗。Google spreadsheet 对于撤销操作的OT明显是onDemand,即在用户点击撤销按钮时,才会对于撤销操作执行OT,这样可以避免执行过多的OT操作,因为用户完全有可能并不执行任何撤销操作。





阅读更多

没有更多推荐了,返回首页