分布式事务中的2PC和3PC

 

分布式事务

    分布式事务是指会涉及到操作多个数据库的事务。其实就是将对同一库事务的概念扩大到了对多个库的事务。

    分布式事务中需要注意的是分布式系统中存在的一致性问题；

   CAP原则：在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼；

主要的典型的协议和算法：

    二阶提交协议（Two Phase Commitment Protocol）；

    三阶提交协议（Three Phase Commitment Protocol）；

    Paxos算法；

其中，二阶提交协议和三阶提交协议就是根据“XA规范”衍生出来的。

    XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。

    可以说二阶段提交其实就是实现XA分布式事务的关键（确切地说：两阶段提交主要保证了分布式事务的原子性：即所有结点要么全做要么全不做，也就是原子性）

2PC

    参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作；

所谓的两个阶段是指：

    第一阶段：准备阶段（投票阶段）；

    第二阶段：提交阶段（执行阶段）；（选择提交或者回滚）

2PC的缺点：1.同步阻塞；2.单点故障；3.数据不一致；4.宕机导致事务状态未知；

3PC

3PC：二阶段提交（2PC）的改进版本；

    1、引入超时机制。同时在协调者和参与者中都引入超时机制。

    2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段；

注意：在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交；

In order to, 成功提交的几率很大，因为已经进入doCommit阶段了；

补充

无论是二阶段提交还是三阶段提交都无法彻底解决分布式的一致性问题。

世上只有一种一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整版。

小记：MongoDB中不支持真正的事务，只能通过程序实现事务特性；也就是MongoDB官方所讲的2PC（Two Phase Commits两阶段提交），试图在一定程度上能保证数据最终的一致性，但是应用程序还是可能会读到提交或者回滚过程中的中间数据；

 

更详细的话，看这里：

http://www.hollischuang.com/archives/681