一致性问题

分布式系统中，为了保证数据的高可用。通常，会将数据保留多个副本放置在不同的物理的机器上。为了保证正确的增、删、改、操作，还需要保证这些放置在不同物理机器上的副本数据是一致的。

为了这样的分布式一致性问题，前人在性能和数据一致性衡过程中总结了许多典型的协议和算法。比较著名的有二阶提交协议（2PC）、三阶提交协议（3PC）。

分布式事务

分布式事务是指涉及到操作多个数据库的事务，目的是为了保证分布式系统中的数据一致性。分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）。

2PC

分布式系统中，各个节点之间在物理上相互独立，通过网络进行沟通和协调。由于存在事务机制，可以保证每个独立节点上的数据操作可以满足ACID。但是，相互独立的节点之间无法准确的知道其他节点中的事务执行情况。所以从理论上讲，两台机器理论上无法达到一致的状态。


如果想让分布式部署的多台机器中的数据保持一致性，那么就要保证在所有节点的数据写操作，要不全部都执行，要么全部的都不执行。但是，一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果。所以他也就不知道本次事务到底应该commit还是 roolback。所以，常规的解决办法就是引入一个“协调者”的组件来统一调度所有分布式节点的执行。

所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。

准备阶段

事务协调者给每个参与者发送Prepare消息，每个参与者要么返回失败，要么在本地执行事务，写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。

提交阶段

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。

当然，这样的模式分为两种情况。

1）协调者节点从所有参与者节点获得的相应消息都为”同意”时

2）任一参与者节点在第一阶段返回的响应消息为”中止”，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时

二阶段提交看起来确实能够提供原子性的操作，但是不幸的事，二阶段提交还是有几个缺点
1）数据不一致：二阶段提交的阶段二中，当协调者向参与者发送commit请求后，局部网络发生异常或者在发送commit请求过程中协调者发生了故障。这会导致只有部分参与者接受到了commit请求，其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。
2）单点故障：由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞。尤其在第二阶段，协调者发生故障，所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。

由于二阶段提交存在着诸如同步阻塞、单点问题等问题，所以，前人在二阶段提交的基础上做了改进，提出了三阶段提交。

3PC

三阶段提交（3PC）是二阶段提交（2PC）的改进版本，与两阶段提交不同的是，三阶段提交有两个改动点。

引入超时机制。同时在协调者和参与者中都引入超时机制。
在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

CanCommit

CanCommit 协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

PreCommit

协调者根据参与者的反应情况来决定是否可以记性事务的PreCommit操作。根据响应情况，有以下两种可能。

1）协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行
2）任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断

doCommit

该阶段进行真正的事务提交，可以分为以下两种可能

执行提交
1.提交请求，协调者向所有参与者发送doCommit请求
2.事务提交，参与者收到doCommit请求之后，正式提交事务。并在完成事务提交之后释放所有事务资源。
3.响应反馈，事务提交完之后，向协调者发送Ack响应。
4.完成事务，协调者接收到所有参与者的ack响应之后，完成事务。

中断事务

协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。

1.中断请求，协调者向所有参与者发送abort请求
2.事务回滚，参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
3.反馈结果，参与者完成事务回滚之后，向协调者发送ACK消息
4.中断事务，协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

结论

了解2PC和3PC之后，可以发现，无论是二阶段提交还是三阶段提交都无法彻底解决分布式的一致性问题。Mike Burrows说过， there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos。即世上只有一种一致性算法，那就是Paxos，其他所有一致性算法都是Paxos 算法不完整版。

最后

以上就是活泼洋葱为你收集整理的详谈 2PC 3PC一致性问题分布式事务2PC3PC结论的全部内容，希望文章能够帮你解决详谈 2PC 3PC一致性问题分布式事务2PC3PC结论所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。