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

能够参考这篇文章：

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

 

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

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

 

两阶段提交的过程涉及到协调者和参与者。协调者能够看作成事务的发起者，同时也是事务的一个参与者。

第一阶段：

prepare

第二阶段：

若是有人不prepare，或者无响应，就取消；若是全都赞成，那么协调者会将Commit T日志写入磁盘，并向全部参与者发送一个Commit T信息，提交该事务。

 

2、可能出现的问题 
　　通常状况下，两阶段提交机制都能较好的运行，但可能出现下面三种问题： 
　　（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 日志 
数据库日志保证了事务执行的原子性和持久性。

 

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

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

（我博客里面有好几篇Paxos相关的文章）

 

（完）