标签：传统 就是 事务处理 alt acl can 情况 ack 运行
上文提到过数据库中2PC如何实现的，今天就来好好画画2PC与3PC的流程图，以及对比它们之间的关系和区别。
分布式事务是为了解决微服务架构（形式都是分布式系统）中不同节点之间的数据一致性问题。这个一致性问题本质上解决的也是传统事务需要解决的问题，即一个请求在多个微服务调用链中，所有服务的数据处理要么全部成功，要么全部回滚。当然分布式事务问题的形式可能与传统事务会有比较大的差异，但是问题本质是一致的，都是要求解决数据的一致性问题。
而分布式事务的实现方式有很多种，最具有代表性的是由Oracle Tuxedo系统提出的XA分布式事务协议。XA协议包括两阶段提交（2PC）和三阶段提交（3PC）两种实现，接下来我们分别来介绍下这两种实现方式的原理。
两阶段提交又称2PC（Two-Phase Commit）,2PC是一个非常经典的强一致、中心化的原子提交协议。这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和N个参与者节点（partcipant）。顾名思义，二阶段提交协议是将事务的提交过程分成了两个阶段来进行处理，其执行流程如下。
2.1 正常流程
假设阶段一所有的参与者都回复了Yes响应，则执行正常流程，正式提交事务。如下图绿色线条标识。
2.2 异常流程
假设阶段一有任何一个参与者回复了No响应或者无反应协调者等待超时，则执行异常流程，回滚中断事务。如下图橙色线条标识。
以上就是两阶段提交的基本过程，我们再分析下其优缺点。
优点：原理简单，实现方便。
缺点: 同步阻塞、单点问题、脑裂、太过保守。
同步阻塞
视为最明显最大的一个问题，主要是以上过程中，任何逻辑步骤都需要等待，即同步阻塞，极大的影响分布式系统的性能。各个参与者在等待其他参与者响应过程中，无法进行其他任何操作；协调者也需要等待所有的参与者都回复才能进行下一步的动作。当然在2PC中，协调者有超时处理。
单点问题
从以上可以看出，协调者只有一个，如果协调者出现异常和故障，那么所有参与者可能都会被阻塞，整个流程将无法运行。
数据不一致
而第二阶段中，如果只有部分执行了commit而另一部分可能网络原因没有收到commit命令，将会导致数据不一致。
太过保守
只有协调者有自己的超时处理，而参与者并没有。而第二阶段中，提交或者回滚如果存在没有执行的情况，没有任何应对措施；所以没有完善的容错机制，任何一个节点失败导致整个事务的失败。
针对2PC的一些缺点，人们提出了3PC协议，即Three-Phase Commit，引入了超时机制。在流程上将二阶段的准备阶段一分为二，形成由CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。
该阶段主要是协调者询问所有参与者是否已经准备好了吗？
2.1 正常流程
如果阶段一中所有的参与者都准备好了回复了Yes，则执行预提交。
2.2 异常流程
如果阶段一中任一参与者没有准备好回复的No或者等待超时，则终止流程。
3.1 正常流程
如果阶段二中所有的参与者进行了预提交，并且回复了Ack，则进行正式提交。
3.2 异常流程
如果阶段二中任一参与者进行了预提交失败或者超时协调者没有收到其反馈响应，则需要回滚之前的预提交。
3.3 注意事项
一旦进入阶段三，可能会出现以下两种故障。
（1）协调者出现问题。
（2）协调者和参与者之间的网络出现故障。
无论出现哪种情况，最终都会导致参与者无法及时接收到来自协调者的doCommit或是abort请求，针对这样的异常情况，参与者都会在等待超时之后，继续执行事务提交。
相比较2PC而言，3PC对于协调者（Coordinator）和参与者（Partcipant）都设置了超时时间，而2PC只有协调者才拥有超时机制。这解决了一个什么问题呢？这个优化点，主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。
另外，通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。
以上就是3PC相对于2PC的一个提高（相对缓解了2PC中的前两个问题），但是3PC依然没有完全解决单点故障和数据不一致的问题。
参考资料：
《从Paxos到Zookeeper：分布式一致性原理与实践》
标签：传统 就是 事务处理 alt acl can 情况 ack 运行
原文地址：https://www.cnblogs.com/orange-CC/p/13321438.html
