引言：2PC必须注意的问题算法
我们上文介绍了分布式事务的常见方案、类型划分、2PC的起源和流程。可是不幸的是2PC仍是存在几个问题：网络
一、全流程的同步阻塞：不论是第一阶段仍是第二阶段，全部参与节点都是事务阻塞型。当参与者占有公共资源时，其余第三方访问公共资源可能不得不处于阻塞状态。架构
二、TM单点故障：因为全流程依赖TM的协调，一旦TM发生故障。参与者会一直阻塞下去。尤为在第二阶段，TM发生故障，那么全部的参与者还都处于锁定事务资源的状态中，而没法继续完成事务操做。全部参与者必须等待TM从新上线(TM从新选举)后才能继续工做。app
三、TM脑裂引发数据不一致：在第二阶段中，当TM向参与者发送commit请求以后，发生了局部网络异常或者在发送commit请求过程当中TM发生了故障，这会致使只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求以后就会执行commit操做。可是其余部分未接到commit请求的机器则没法执行事务提交。因而整个分布式系统便出现了数据不一致性的现象。分布式
四、TM脑裂引发事务状态不肯定：TM再发出commit消息以后宕机，而接收到这条消息的参与者同时也宕机了。那么即便经过选举协议产生了新的TM，这条事务的状态也是不肯定的，没人知道事务是否被已经提交。翻译
一、3PC定义日志
2PC是CP的刚性事务，追求数据强一致性。可是经过咱们上面分析能够得知TM脑裂可能形成数据不一致和事务状态不肯定问题。没法达到CP的完美状态。所以业界就出现了3PC，用来处理TM脑裂引发的数据不一致和事务状态不肯定问题。事务
由于3PC是为完全解决的2PC的数据不一致和事务状态不肯定问题而出现。根据这一个前提，加上笔者对3PC的理解，总结出3PC的注释事项：资源
1）3PC确保任何分支下的数据一致性
2）3PC确保任何分支最多3次握手获得最终结果(超时机制)
3）RM超时后的事务状态必须从TM获取。2PC只有TM的超时机制，3PC新增了参与者(RM)的超时机制，一方面辅助解决了2PC的事务/事务问题，还能下降必定的同步阻塞问题。由于TM、RM双向超时机制，因此维基百科对3PC定义为“非阻塞”协议。同步
2、优雅的3PC流程
3PC 分红3个阶段：CanCommit(准备阶段)、PreCommit(对齐阶段)、DoCommit(提交阶段)；笔者根据资料对3阶段进行比较合适的翻译，非官方翻译。
准备阶段：跟2PC的表决阶段很相似，TM向参与者发送commit请求，参与者若是能够提交就返回Yes，不然返回No，询问超时默认参与者为No。惟一差异在于SQL层面：准备阶段只作了SQL处理，并未记录事务日志(Undo 和Redo)
对齐阶段：TM 和 各个参与者对齐事务状态，TM 通知各个参与者事务最终状态，各个参与者若是一致未收到事务对齐通知，会在超时后从TM反查事务状态实现事务状态对齐。在SQL层面：事务状态对齐后，记录事务日志(Undo 和Redo)
提交阶段：该阶段进行真正的事务提交。根据第二阶段获得的事务状态结果，各参与者根据TM的通知命令进行提交/abort或者超时后自动提交/abort。
下图是笔者根据资料和我的理解整理出来的一个自认为比较合理的3PC流程图：
3、总结
或许3PC也不完美，网上有好多各版本的3PC的流程图和解释。有的甚至还存在明显的问题，为3PC的理解带来了更大的苦难。身为架构师，就须要去追寻本质，了解3PC的前世此生，抓住3PC的本质，就很容易理解3PC了。
对于数据一致性，Google Chubby的做者Mike Burrows说过：“there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos。”
译文：世上只有一种一致性算法，那就是Paxos，全部其余一致性算法都是Paxos算法的不完整版。
- 做者介绍 -
林淮川
毕业于西安交通大学；奈学教育《百万架构师训练营》讲师及企业级源码内源负责人，前大树金融高级架构师；前大树金融技术委员会开创者；前大树金融供应链金融技术总监；前天阳宏业交易事业部技术主管；多年互联网金融行业（ToB）经验。