本文主要是介绍分布式事务实现，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

CAP理论

• 一致性（Consistency）
• 可用性（Availability）
• 分区容错性（网络分区）Partition tolerance

CAP理论的特点，就是CAP只能满足其中2条

CA(放弃P)：将所有的数据放在一个节点。满足一致性、可用性。

AP(放弃C)：放弃强一致性，用最终一致性来保证。

CP(放弃A)：一旦系统遇见故障，受到影响的服务器需要等待一段时间，在恢复期间无法对外提供服务。

一致性算法问题：

为了解决分布式一致性问题，产生了不少经典的分布式一致性算法，本文将介绍其中的2PC和3PC。2PC即Two-Phase Commit，译为二阶段提交协议。3PC即Three-Phase Commit，译为三阶段提交协议。

分布式系统和分布式一致性问题

  分布式系统，即运行在多台不同的网络计算机上的软硬件系统，并且仅通过消息传递来进行通信和协调。

分布式一致性问题，即相互独立的节点之间如何就一项决议达成一致的问题。

2PC

    2PC，二阶段提交协议，即将事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段。事务的发起者称协调者，事务的执行者称参与者。 

阶段1：准备阶段

1、协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。

2、各参与者执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）。

3、如参与者执行成功，给协调者反馈YES，即可以提交；如执行失败，给协调者反馈NO，即不可提交。

阶段2：提交阶段

此阶段分两种情况：所有参与者均反馈YES、或任何一个参与者反馈NO。

所有参与者均反馈YES时，即提交事务。
任何一个参与者反馈NO时，即中断事务。

提交事务：（所有参与者均反馈YES）
1、协调者向所有参与者发出正式提交事务的请求（即Commit请求）。
2、参与者执行Commit请求，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务提交。
　　附如下示意图：

中断事务：（任何一个参与者反馈NO）

1、协调者向所有参与者发出回滚请求（即Rollback请求）。
2、参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务中断。

附如下示意图：
 

备注：ACK (Acknowledge character）即是确认字符。

2PC的缺陷

1、同步阻塞：最大的问题即同步阻塞，即：所有参与事务的逻辑均处于阻塞状态。
2、单点：协调者存在单点问题，如果协调者出现故障，参与者将一直处于锁定状态。
3、脑裂(数据不一致)：在阶段2中，如果只有部分参与者接收并执行了Commit请求，会导致节点数据不一致。

数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。

举个例子：插入10w数据到分布式数据库中。怎么处理呢？参照

由于2PC存在如上同步阻塞、单点、脑裂问题，因此又出现了2PC的改进方案，即3PC。

3PC

   3PC，三阶段提交协议，是2PC的改进版本，即将事务的提交过程分为CanCommit、PreCommit、do Commit三个阶段来进行处理。

3pc与2pc的区别

与两阶段提交不同的是，三阶段提交有两个改动点。

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

也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

阶段1：CanCommit

1. 协调者向所有参与者发出包含事务内容的CanCommit请求，询问是否可以提交事务，并等待所有参与者答复。
2. 参与者收到CanCommit请求后，如果认为可以执行事务操作，则反馈YES并进入预备状态，否则反馈NO。
    

阶段2：PreCommit

此阶段分两种情况：
1、所有参与者均反馈YES，即执行事务预提交。

2、任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务。
 

事务预提交：（所有参与者均反馈YES时）
1、协调者向所有参与者发出PreCommit请求，进入准备阶段。
2、参与者收到PreCommit请求后，执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）。
3、各参与者向协调者反馈Ack响应或No响应，并等待最终指令。
    

中断事务：（任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈时）
1、协调者向所有参与者发出abort请求。
2、无论收到协调者发出的abort请求，或者在等待协调者请求过程中出现超时，参与者均会中断事务。
 

阶段3：do Commit

此阶段也存在两种情况：
1、所有参与者均反馈Ack响应，即执行真正的事务提交。
2、任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务。
 
　　提交事务：（所有参与者均反馈Ack响应时）
1、如果协调者处于工作状态，则向所有参与者发出do Commit请求。
2、参与者收到do Commit请求后，会正式执行事务提交，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务提交。
 
　　中断事务：（任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈时）
1、如果协调者处于工作状态，向所有参与者发出abort请求。
2、参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。
3、各参与者向协调者反馈Ack完成的消息。
4、协调者收到所有参与者反馈的Ack消息后，即完成事务中断。
 
　　注意：进入阶段三后，无论协调者出现问题，或者协调者与参与者网络出现问题，都会导致参与者无法接收到协调者发出的do Commit请求或abort请求。此时，参与者都会在等待超时之后，继续执行事务提交。
 
　　附示意图如下：
 

3PC的优点和缺陷

优点：降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段3中协调者出现问题时，参与者会继续提交事务。

缺陷：脑裂问题依然存在，即在参与者收到PreCommit请求后等待最终指令，如果此时协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。
 

分布式数据库类型

DRDS属于2pc,

　无论2PC或3PC，均无法彻底解决分布式一致性问题。
　解决一致性问题，唯有Paxos，后续将单独总结。

2pc与3pc的区别

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

2pc与3pc存在问题

了解了2PC和3PC之后，我们可以发现，无论是二阶段提交还是三阶段提交都无法彻底解决分布式的一致性问题。

这篇关于分布式事务实现的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！