一致性问题

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

为了这样的分布式一致性问题，前人在性能和数据一致性衡过程中总结了许多典型的协议和算法。比较著名的有二阶提交协议（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相关推荐

有关2pc, 3pc,Tcc 的理解
对于分布式事务的概念,可能还会有很多同学不理解或者理解得不是很深刻的地方,在这篇文章中,作者打算重点给大家先介绍下分布式事务相关的基本概念,诸如2PC.3PC.TCC之类的基本问题. 1. 二阶段提交 ...
【分布式事务】内容较多CAP/BASE/2PC/3PC/TCC/Sega等等等等~，一次性捋清楚
分布式事务概述什么是分布式事务分布式事务就是指事务的资源分别位于分布式系统的不同节点之上的事务分布式事务产生的原因数据库分库分表当业务数据量达到单库单表的极限时,就需要考虑分库分表,跨多个 ...
2PC/3PC到底是啥
讨论提到2PC/3PC首先想到的是它是一致性协议,而且经常把它和Paxos协议放在一起比较,并且经常看到这样的说法"世上只有一种一致性算法,那就是Paxos",2PC/3PC并不 ...
事务 | Spring Cloud 分布式事务管理（二）2pc/3pc
Spring Cloud 分布式事务管理(二)2pc/3pc 上一篇 Spring Cloud 分布式事务管理上一章,讲到了微服务带来的优点和缺点以及分布式事务的不确定性.这节说一下2pc/3pc ...
2PC/3PC、paxos与ZAB协议
为什么80%的码农都做不了架构师?>>> 2PC 即Two-phase Commit,参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还 ...
什么是分布式事务(CAP原则、BASE理论、2PC|3PC协议、XA|AT等模式)
1.CAP原则 CAP原则是指:一致性©.可用性(A).分区容错性§,分布式系统一般进行三选二,比如: CA:保证一致性和可用性,在单机情况下实现: CP:保证一致性和分区容错性: AP:保证可用性和 ...
【分布式系统】分布式事务（2PC 3PC TCC 最终一致性）
目录问题场景 2PC:两阶段提交 3PC:三阶段提交 TCC(Try-Confirm-Cancel) 基于MQ的最终一致性
分布式理论二阶段提交 2PC 3PC 端到端一致性分布式事务
一.临界知识对我们学习的巨大帮助临界知识这个概念,是我上个月读<好好学习:个人知识管理精进指南>这本书学到的概念,真的有被启发到,现在觉得它对于我们深刻了解世界有着非常大的作用. 所谓临 ...
分布式事务:XA,2PC,3PC,TCC,SEATA(AT)
一.分布式事务产生原因 1.原本的数据是单库单表存储,随着业务的不断扩大数据量不断增多,单库性能支撑不了数据的更新与访问.为了解决数据库上的瓶颈,将数据库进行水平拆分,原来一个库里的事务操作,现在变成 ...

详谈 2PC 3PC