分布式架构之「 MVCC」

1,954 阅读7分钟

最近忙于填坑中,周末抽时间继续写分布式架构系列的文章。上一篇文章中讲了两阶段提交协议,它能指导我们如何应对分布式中数据强一致性、事务。前面的文章中提到的给数据带上版本号,版本号是递增的,它是类似MVCC的方式。对并发控制的手段有基于锁、时间戳协议、有效性检查、多粒度、多版本机制(MVCC)。


基于MVCC的分布式事务


实现分布式事务除了使用类似”两阶段提交”协议等方式外,另一种简单高效的方式就是使用MVCC(Multi-version Cocurrent Control,多版本并发控制)技术。MVCC技术最初也是在数据库系统中被提出,但这种思想并不局限于单机的分布式系统,在分布式系统中同样有效。


MVCC简介


顾名思义,MVCC即多个不同版本的数据实现并发控制的技术,其基本思想是为每次事务生成一个新版本的数据,在读数据时选择不同版本的数据即可以实现对事务结果的完整性读取。在使用MVCC时,每个事务都是基于一个已生效的基础版本进行更新,事务可以并行进行,从而可以产生一种图状结构。


如图所示,基础数据的版本号为1,同时产生了两个事务:事务A与事务B。这两个事务都各自对数据进行了一些本地修改(这些修改只有事务自己可见,不影响真正的数据),之后事务A首先提交,生成数据版本2;基于数据版本2,又发起了事务C,事务C继续提交,生成了数据版本3;最后事务B提交,此时事务B的结果需要与事务C的结果合并,如果数据没有冲突,即事务B没有修改事务A与事务C修改过的变量,那么事务B可以提交,否则事务B提交失败。


MVCC的流程过程非常类似于SVN等版本控制系统的流程,或者说SVN等版本控制系统就是使用的MVCC思想。


事务在基于基础数据版本做本地修改时,为了不影响真正的数据,通常有两种做法,一是将基础数据版本中的数据完全拷贝出来在修改,SVN即使用了这种方法,SVN check out即是拷贝过程;二是每个事务中只记录更新操作,而不记录完整的数据,读取数据时再将更新操作应用到基础版本的数据从而计算出结果,这个过程也类似SVN的增量提交。


分布式MVCC


分布式MVCC的重点不在于并发控制,而在于实现分布式事务。这里首先给出一个简化的分布式事务的问题模型,之后对MVCC的讨论基于该问题展开。假设在一个分布式系统中,更新操作以事务进行,每个事务包含若干个对不同节点的不同更新操作。更新事务必须具有原子性,即事务中的所有更新操作要么同时在各个节点生效,要么都不生效。假设不存在并发的事务,即上一个事务成功提交后才进行下一个事务。


例如,用(site,k,op,oprd)表示在site节点上对变量k进行op操作,操作数为oprd。那么一个典型的事务可能是{(site_A, var1, add, 10),(site_B, var2, sub, 1), (site_A, var3, set, 2)},这个事务在site_A上将变量var1加10,将变量var3设置为2,在site_B上将变量var2减1。


基于MVCC的分布式事务的方法为:为每个事务分配一个递增的事务编号,这个编号也代表了数据的版本号。当事务在各个节点上执行时,各个节点只需记录更新操作及事务编号,当事务在各个节点都完成后,在全局元信息中记录本次事务的编号。在读取数据时,先读取元信息中已成功的最大事务编号,再于各个节点上读取数据,只读取更新操作编号小于等于最后最大已成功提交事务编号的操作,并将这些操作应用到基础数据形成读取结果。


场景:假设系统中有两个节点A、B。节点A、节点B状态如下表

  1. 若此时全局元信息中的最大的生效事务序号为1,则在节点A上:var1=1,var2=2,在节点B上:var3=2;

  2. 若此时全局元信息中的最大的生效事务序号为2,则在节点A上:var1=1+2=3,var2=2,在节点B上:var3=2,var4=1;

从这个例子可以看出,每个节点上保存了对数据的更新操作,也就是数据的增量(delta),从而可以在读取数据时将应用不同的更新操作得出不同的数据版本。上例中,计算编号小于等于1的事务操作得出的数据即为版本号为1的数据,计算编号小于等于2的事务操作得出的数据即为版本号为2的数据。在新事务执行过程中,虽然更新操作已经逐步记录到各个节点,但只要全局元信息不修改,始终不会读到没有生效的事务数据,从而实现了全局一致性。另外,由于数据具有多个版本,可以自然实现对历史版本数据的读取。


上述方法的一个重要问题是,随着执行的事务越来越多,各个节点保存的更新操作会越来越多,读取数据时需要应用的更新操作也越来越多。工程中可以对此周期性的启动合并操作,将历史上不再需要的版本合并为一个更新操作。例如,对场景中事务序号小于等于2的操作进行合并,合并后的节点状态如下:

这里合并后事务序号设置为合并使用的事务序号。如果节点中存在序号大于2的操作,则需要保留这些操作不参与合并。



工程投影


Megastore中的MVCCMegastore中的MVCC

Megastore利用了Big Table中数据的多版本特性实现分布式的更新事务。每个事务更新的都是不同版本(timestamp)的Big Table的数据,在读取数据时利用timestamp过滤,从而不会读到正在进行的尚未生效的事务数据。其原理与本文中介绍完全一致,不再阐述。


Doris中的MVC

在Doris系统中,数据按批量进行更新,每个批量的数据都可以认为是一个事务,必须同时原子性的生效。为此,Doris将每条数据附带了一个导入的版本号,在读取数据时根据元数据中已生效的版本号与数据上的导入版本号做过滤,从而不读取正在更新的尚未生效的数据,实现了分布式事务更新。其详细流量与本节中介绍的一致。


参考资料:《分布式系统原理介绍》作者:刘杰

作者:井底知蛙,多年架构经验,倾囊相授

个人微信公众号:井底倁蛙(id:upgrade366)

(6)工程投影



做互联网时代适合的架构:开放、分享、协作

长按二维码即可关注我们

好看|求转发