分布式事务 & 两阶段提交 & 三阶段提交

可以参考这篇文章:

http://blog.csdn.net/whycold/article/details/47702133

 

两阶段提交保证了分布式事务的原子性,这些子事务要么都做,要么都不做。

而数据库的一致性是由数据库的完整性约束实现的,持久性则是通过commit日志来实现的,不是由两阶段提交来保证的。

 

两阶段提交的过程涉及到协调者和参与者。协调者可以看做成事务的发起者,同时也是事务的一个参与者。

第一阶段:

prepare

第二阶段:

如果有人不prepare,或者无响应,就取消;如果全都同意,那么协调者会将Commit T日志写入磁盘,并向所有参与者发送一个Commit T信息,提交该事务

 

二、可能出现的问题 
  一般情况下,两阶段提交机制都能较好的运行,但可能出现下面三种问题: 
  (1)协调者不宕机,参与者宕机; 
  (2)协调者宕机,参与者不宕机; 
  (3)协调者宕机,参与者(可以是部分)也宕机; 

 

对于(1)当在事务进行过程中,有参与者宕机时,他重启以后,可以通过询问其他参与者或者协调者,从而知道这个事务到底提交了没有。当然,这一切的前提都是各个参与者在进行每一步操作时,都会事先写入日志。 (能解决

对于(2)协调者宕机后,可以起新的协调者,然后查询所有参与者的状态是否有commit的,如果有,则继续commit,如果都没有,则abort。 (能解决

对于(3)包含了唯一一个两阶段提交不能解决的困境:当协调者在发出commit T消息后宕机了,而唯一收到这条命令的一个参与者也宕机了。(这个时候这个事务就处于一个未知的状态,没有人知道这个事务到底是提交了还是未提交,从而需要数据库管理员的介入,防止数据库进入一个不一致的状态)

 

对于上面的困境,业界提出了三阶段提交的方法来此问题。

将二阶段提交的第二阶段再分为待定阶段(或预提交阶段)确定阶段,从而变为三阶段;

在待定阶段协调者log prepare_commit消息后向所有参与者发送prepare_commit消息, 待收到所有参与者回包(这里的回包结果只会成功)或超时时就进入第三段阶,log commit消息并向所有参与者发送commit消息。

如果在待定阶段和确定阶段出现协调者和部分参与者同时宕机(即上面的困境),只要存活的协调者或参与者里有prepare_commit或commit消息,新的协调者可以继续进行commit消息,如果没有,就不commit消息,从而保证数据的一致性。

 

3 日志 
数据库日志保证了事务执行的原子性和持久性。

 

4 总结 
二阶段提交和三阶段提交都是很好的分布式事务算法,三阶段提交是为解决二阶段提交未解决的问题(协调者宕机,参与者也宕机)而提出来的。

不过这两种算法都只考虑一个协调者(主节点)的情况,没有考虑多个协调者和如何选出协调者的问题。而另一种知名分布式事务算法pasox能解决多个协调者的情况,并提出了多数派的概念。

(我博客里面有好几篇Paxos相关的文章)

 

(完)

 

posted @ 2017-01-16 13:51 blcblc 阅读(...) 评论(...) 编辑 收藏