分布式事务提交的一些想法

 

读JimGray和LeslieLamport的,之前也思考过类似的问题,于是针对分布式事务处理的思路做了一个总结。作为乐观派,深信不久后分布式事务这个高地一定会被拿下。...



随着人们对数据存储的需求越来越多,对数据库而言,扩展性变成了很重要的因素,近几年来,很多数据库通过分区技术解决了扩展性的问题,比如MySQL的Shard或者BigTable的Partition。分区技术带来了一个熟知的难题,就是跨分区事务特性的高可用和性能。今天读了Jim Gray和Leslie Lamport的的文章,加上之前也思考过这一块,还是总结一下,就是下文。因为并没有真正做过分布式事务,所以这些都是纸上谈兵,出错之处,欢迎交流。微信:teaworldvc20

经典的二阶段提交(2PC)如图1[1]而言,主要的角色包括事务协调器(Transaction Manager/Coordinator, TM)以及事务参与者(Resource Manager/ Participant),主要步骤图中已经写得很清楚了,这些步骤可以分为两个阶段:

1.第一阶段Prepare:TM发消息给各个RM,是否可以提交,各个RM根据自己的状态来判断,以转账为例,比如余额够不够,账号是否被锁定等,将判断结果写入stable storage(写本地盘或者共享存储),然后发消息给TM

2.第二阶段Commit:如果各个RM都认为可以提交,则TM写下Commit到stable storage,此时这个事务就算提交了;然后TM发消息给各个RM,而RM则Apply,并允许接下来的事务看到这些事务的修改结果

图1:基本的2PC流程[图片链接见下,侵删]


上面的2PC流程面临最大的挑战是可用性问题,比如

  1. TM挂:此时没有人知道该TM上活跃事务的状态,唯有等待其恢复才能继续,而该TM上的事务可能还在相关的RM上锁住了资源,这很容易导致整个系统没法运转,带来极大的运维代价,记得Percolator里面就提到了有时候需要人工处理这类问题,而Percolator[2]是用于处理网页的,对实时性要求并不高,如果是交易系统,基本不可接受
  2. RM挂:此时影响的是这个RM相关事务,典型情况下,某些用户不能操作了,只要分区做的合理,影响可控,当然,大家会希望即使RM挂系统也能照常运行
解决上面问题的思路主要有两个大方向:

  1. 思路一,使用共享存储存储状态+周期监测相关角色状态:共享存储的意义是可用性本来就很高,等于站在巨人的肩膀上,比如Google的BigTable已经做到了很好的容错(机器A挂了之后,A上服务的分区会被很快调度到其他机器上),那么我们将TM状态写入到BigTable中,这样任何时候我们都可以认为TM的状态是可用的。除此之外,还要让TM-1跟一个调度器进程保持心跳。当调度器发现TM-1一段时间没有心跳,就再启动一个TM-2,TM-2启动后首先拿到排它锁(防止网络分裂TM-1还在服务,使用类似Chubby[3]分布式锁服务),然后从BigTable里面加载TM-1的状态,这样整个系统就可以正常运转,如果做的好,这个不可用时间大概可以做到10s以内(每个TM的活跃事务要分配好,不要倾斜太严重)。RM的可用性可以如法炮制。可以看到,上述思路沿用了传统存储方案的共享存储思路,通过保障共享存储来提高可用性
  2. 思路二,使用一致性协议保证每个角色的高可用:一致性协议是Paxos或者其变种,抽象理解就是某个角色的多个参与者组成了Paxos group,只要这个group中的大多数参与者是可用的,则这个角色就是可用的。这种方案又细分两个思路:
  3. [list=1]
  4. 只有TM使用一致性协议:这样就保证了TM的可用性,RM如果挂了,因为只影响了部分,等待期恢复即可,这也是Lamport文中提到的方法,流程见图2。但是在繁忙的数据库中有时候RM几秒不可用也是不能接受的
  5. 文中思路推广开,所有TM、RM均使用一致性协议:这样保证了所有角色的高可用,这个猜测是Google Spanner[4]里面使用的策略,因为文中提到过可以通过增加参与者提高读性能,说明很可能RM使用了一致性协议。
 

图2:文中描述的Paxos Commit流程


最开始提到了,分布式事务要求事务系统的高可用和性能,上面两种思路三种做法各自的优劣如何呢?个人看法如下:

  1. 可用性天花板:思路1使用共享存储保证高可用相对容易实现,因为分布式存储的基础设施已经比较完备,各种理论和开源工程也很多。但是该方案在可用性方面有天花板,心跳检测是一个依赖时间的机制(心跳监测是一个比较复杂的话题,而不少系统心跳做的都不合理,典型的就是心跳还在但是不能服务),无论如何做,最好也就是做到几秒。思路2使用一致性协议,在碰到参与者挂的时候平均几百ms就可以完成错误切换。还有一个问题是当碰到网络延时抖动的时候,思路1的方案只能等待,思路2就可以迅速排除抖动网络所在的参与者(当然一致性协议实现要做的好,要让新的参与者迅速提供决策)
  2. 性能:主要考虑三个方面,发消息的次数、写盘次数以及commit的总时延,对比见图3,前面都是论文中的,最后一列是我加的
  3. 工程难度:思路2的工程实现复杂度比思路1大,思路2的第二种方案如果想实现的高效会更难,不过,如果让我做,我会选择第二种方案,可用性最好,且如果读压力大,可以灵活调节。


图2:文中描述的Paxos Commit流程


[1]. http://databaser.net/moniwiki/pds/2_2dPhaseCommit/two_phase_commit.jpg

[2].http://research.google.com/pubs/archive/36726.pdf

[3].http://research.google.com/archive/spanner-osdi2012.pdf

[4].http://research.google.com/archive/chubby-osdi06.pdf


    关注 NOSQL追随者


微信扫一扫关注公众号

0 个评论

要回复文章请先登录注册