说说分布式事务(二)

3PC

以两阶段提交来讲，主持人收到一个提案请求，打电话跟每一个组员询问是否经过并统计回复，而后将最后决定打电话通知各组员。要是主持人在跟第一位组员通完电话后失忆，而第一位组员在得知结果并执行后老人痴呆，那么即便从新选出主持人，也没人知道最后的提案决定是什么，也许是经过，也许是驳回，无论你们选择哪种决定，都有可能与第一位组员已执行过的真实决定不一致，老板就会不开心认为决策小组沟通有问题而解雇。三阶段提交便是引入了另外一个步骤，主持人打电话跟组员通知请准备经过提案，以免没人知道真实决定而形成决定不一致的失业危机。为何可以解决二阶段提交的问题呢？回到刚刚提到的情况，在主持人通知完第一位组员请准备经过后两人意外失忆，即便没人知道全体在第一阶段的决定为什么，全体决策组员仍能够从新协调过程或直接否决，不会有不一致决定而失业。那么当主持人通知彻底体组员请准备经过并获得你们的再次肯定后进入第三阶段，当主持人通知第一位组员请经过提案后两人意外失忆，这时候其余组员再从新选出主持人后，仍能够知道目前至少是处于准备经过提案阶段，表示第一阶段你们都已经决定要经过了，此时即可以直接经过 --------<wiki百科-三阶段提交>

以上资料来自wiki百科,说明在2PC过程当中,在第二个阶段当协调者通知第一个客户端A,而且第一个客户端恰好执行完毕之后,这两台机器都Down掉了,而刚好这N-1台机器投的都是Yes票(都处于不肯定的状态),这个时候整个事务就会被Block,暂时称之为聋哑事件

1. 客户端A投的是Abort票,那么因为协调者和客户端A都Down掉,那么整个事务应该是abort

2. 客户端A投的是commit票,而且协调者决定commit,那么整个事务应该是commit

3. 客户端A投的是commit票,而且协调者因为自身的缘由决定abort,那么整个事务应该是abort

在3PC中引入了一个预提交的状态

1. 当在第二阶段出现聋哑事件,那么这N-1台机器能够根据超时机制直接abort掉,由于客户端A若是提交了事务,只是预提交,当该机器重启之后只要询问周边机器事务状态,简单的将事务回滚或者提交事务,就能保持事务的最终一致性

2. 当进行到第三阶段的时候,若是发生聋哑事件,那么其它处于「不肯定状态」的客户端会直接执行commit,而不会像2PC同样致使事务block,可是这样会有一个风险(进入到第三个阶段说明客户端在第一阶段投的都是Yes),由于在聋哑事件中,那台Down掉的机器在第二阶段中给协调者发送的不是prepared,这个时候协调者收到消息给客户端发送的是abort命令.因此3PC只是乐观的认为只要你第一阶段你们投的都是Yes,那么最后成功提交的概率很大

参考资料

关于分布式事务、两阶段提交协议、三阶提交协议