分布式事务

Posted 2022-12-03 suixinm

分布式一致性事务

为了解决分布式一致性问题，产生了不少经典的分布式一致性算法，本文将介绍其中的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消息后，即完成事务中断。
 
　　附如下示意图：
 

 

2PC的缺陷

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

3PC

 
　　3PC，三阶段提交协议，是2PC的改进版本，即将事务的提交过程分为CanCommit、PreCommit、do Commit三个阶段来进行处理。
 
　　阶段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请求后等待最终指令，如果此时协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致

 

注：

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

 

 

 

 

一致性协议：
在对一个分布式系统进行架构设计的过程中，往往会在系统的可用性和数据一致性之间进行反复的权衡，于是就产生一系列的一致性协议。最著名的是二阶段提交协议、三阶段提交协议。

➢2PC:
2PC是Two-Phase Commit 的缩写，即二阶段提交。是将事务的提交过程分成了两个阶段来进行处理。 
执行流程： 
阶段一：提交事务请求 
1、事务询问 
协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待个参与者的响应。 
2、执行事务 
各参与者节点执行事务操作，并将Undo和Redo信息记入事务日志中。 
3、各参与者向协调者返回事务询问的响应 
如果参与者成功执行了事务操作，那么就反馈给协调者Yes响应，表示事务可以执行；如果参与者没有成功执行事务，就反馈给协调者No响应，表示事务不可以执行。 
阶段二：执行事务提交 
在阶段二中，协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作，正常情况下，包含以下两种可能。 
Case1：执行事务提交 
记入协调者从所有参与者阔的的反馈都是Yes相应，那么就会执行事务提交。 
1、发送提交请求 
协调者想所有参与者节点发出Commit请求。 
2、事务提交 
参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。 
3、反馈事务提交结果 
参与者在完成事务提交之后，向协调者发送Ack消息。 
4、完成事务 
协调者接收到所有参与者反馈的Ack消息后，完成事务。 
 
Case：中断事务 
假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈相应，那么就会终端事务。 
1、发送回滚请求 
协调者向所有参与者节点发送Rollback请求。 
2、事务回滚 
参与者接收到Rollback请求后，会利用其在阶段一种记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。 
3、反馈事务回滚结果 
参与者在完成事务回滚之后，想协调者发送Ack消息。 
4、中断事务 
协调者接收到所有参与者反馈的Ack消息后，完成事务中断。 
 
二阶段提交将一个事务的处理过程分为了投票和执行两个阶段，其核心是对每个事务都采用先尝试后提交的处理方式，因此也可以将二阶段提交看作一个强一致性的算法。 
优缺点： 
优点：原理简单，是实现方便 
缺点：同步阻塞，单点问题，脑裂，太过保守

➢3PC
在二阶段提交协议的基础上进行了改进，提出了三阶段提交协议。 
3PC是Three-Phase Cpmmit的缩写，即三阶段提交，是2PC的改进版，形成了由CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。 
第一阶段：CanCommit阶段 

1.事务询问 
协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。 
2.响应反馈 
参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No。 

第二阶段：PreCommit阶段 
协调者根据参与者的反应情况来决定是否可以进行事务的PreCommit操作。根据响应情况，有以下两种可能。 
假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。 
Case1：执行事务预提交 
1.发送预提交请求 
协调者向参与者发送PreCommit请求，并进入Prepared阶段。 
2.事务预提交 
参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。 
3.响应反馈 
如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。 

Case2：中断事务 
1.发送中断请求 
协调者向所有参与者发送abort请求。 
2.中断事务 
参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。 

第三阶段：doCommit阶段 
该阶段进行真正的事务提交，也可以分为以下两种情况。 

Case 1：执行提交 
1.发送提交请求 
协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。 
2.事务提交 
参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。 
3.响应反馈 
事务提交完之后，向协调者发送Ack响应。 
4.完成事务 
协调者接收到所有参与者的ack响应之后，完成事务。

 
Case 2：中断事务 
协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。 
1.发送中断请求 
协调者向所有参与者发送abort请求 
2.事务回滚 
参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。 
3.反馈结果 
参与者完成事务回滚之后，向协调者发送ACK消息 
4.中断事务 
协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

优缺点： 
优点：降低了参与者阻塞范围，并且能够在出现单点故障后继续达成一致。 
缺点：在去除阻塞的同时引入了新问题，即参与者接收到preCommit消息后，如果网络出现分区，此时协调者所在的节点和参与者无法进行正常网络通信，这时，参与者依然会进行事务提交，这必然导致数据不一致。