一、两阶段提交的缺点
1.同步阻塞：执行过程中，所有参与节点都是事务阻塞型，占有公共资源，其他节点阻塞
2.单点故障：协调者故障，参与者一直阻塞（尤其第二阶段）（重新选举协调者，也无法解决因协调者宕机导致阻塞问题，没人知道事务是否提交）
3.数据不一致：阶段二中，协调者向参与者发送commit请求后，局部网络异常或发commit请求中协调者故障，导致只有一部分参与者接受到commit请求，执行commit，未接到无法提交，不一致性
二、三阶段的执行
协调者和参与者中都引入超时机制，两阶段一阶段拆成两步：询问再锁，最后提交。
1.CanCommit阶段：和2PC准备阶段很像，可以Yes，否则No
2.PreCommit阶段：协调者根据参与者反应决定是否PreCommit
-参与者yes，1）向Cohort发送PreCommit请求，进入Prepared。2）将undo和redo信息记录到事务日志中。3）成功执行事务，返回ACK响应，同时开始等最终指令
-No（或等待超），Coordinator没有接Cohort响应，中断事务：Coordinator向所有Cohort发送abort请求。
3.DoCommit阶段，分两种情况:
1）执行提交
A.Coordinator收到CohortACK响应，进入提交状态。向所有Cohort发送doCommit请求。
B.执行事务提交。提交后释放所有事务资源。向Coordinator发送ACK响应。
C.收到所有Cohort的ACK，完成
2）中断事务：Coordinator没收到Cohort发送ACK响应（响应超时），中断
三、和两阶段提交不同
1、超时机制（2PC中，一定时间内没有收到cohort消息默认失败）。
2、预提交阶段，是个缓冲，保证提交前各节点一致
缺点：PreCommit后，发出abort请求，只有一个Cohort收到abort，其他继续Commit，不一致性。
例：
2PC：主持人跟第一位组员通话后失忆，组员得知结果并执行后痴呆，重选主持人，没人知提案，老板解雇小组。
3PC：即使没知提案，全体决策组员重新协调或直接否决，不会不一致
主持人通知全体组员，大家再次确定，进入第三阶段
这时主持人通知第一位组员，请通过提案后两人失忆，重选出主持人，仍知提案
