Zookeeper 2PC and 3PC

以你之姓@ 2023-09-27 12:12 112阅读 0赞

**目录**

2PC----二阶段提交

阶段一：提交事务请求/投票

阶段二：执行事务提交

二阶段提交协议优缺点：

3PC----三阶段提交

阶段一：canCommit

阶段二：preCommit（有两种情况）

阶段三：doCommit（有两种情况）

三阶段提交协议优缺点：

--------------------

### 2PC----二阶段提交 ###

> 二阶段提交会**统一决定事务的提交或回滚**，从而能够有效地保证分布式数据一致性。
> 
> 二阶段提交将一个事务的处理过程分为了**投票和执行两个阶段**，其核心是对每个事务都采用**先尝试后提交**的处理方式，因此也可以将二阶段提交看作一个**强一致性的算法**。

![9e8ce296843341cdb57b35803a68d27b.jpeg][]

#### 阶段一：提交事务请求/投票 ####

阶段一有3小步：1.首先是事务咨询，协调者会向所有参与者发送事务内容，询问是否可以执行事务提交操作，并且等待各参与者的响应。2.然后执行事务，各参与者节点执行事务操作，并将undo 和 redo信息记入事务日志中，（便于阶段二时的回滚，因为回滚要根据日志信息）。3.最后各参与者向协调者反馈事务询问的响应，如果参与者成功执行了事务操作，就反馈YES，表示事务可以执行；如果参与者没有成功执行事务，就反馈NO响应，表示事务不可以执行。

#### 阶段二：执行事务提交 ####

**有两种可能，一种是执行，一种是中断**

**（1）执行事务提交：**所有参与者都向协调者反馈YES

执行事务提交有4小步：1.首先协调者给所有参与者节点发送Commit请求。2.参与者接收到Commit请求后会执行事务并且提交后会释放在整个事务执行期间占用的事务资源。3.参与者完成事务提交后向协调者发送Ack消息。4.协调者接收到所有参与者反馈的Ack消息后，完成事务。

**（2）中断事务：**任何一个参与者向协调者反馈No，或者等待超时后，协调者无法接收到所有参与者的反馈响应就会中断事务。

中断事务同样有4小步：1.首先协调者给所有参与者节点发送Rollback请求。2.参与者接收到Rollback请求后会利用其在阶段一中记录的事务日志来执行事务回滚操作，并且完成回滚后会释放在整个事务执行期间占用的事务资源。3.参与者完成事务回滚后向协调者发送Ack消息。4.协调者接收到所有参与者反馈的Ack消息后，完成事务中断。

#### 二阶段提交协议优缺点： ####

**优点：**原理简单、实现方便

**缺点：**同步阻塞、单点问题、数据不一致、太过保守

> **同步阻塞：**协调者要等到所有参与者都返回结果才进行下一步操作，这时已经返回结果的参与者就要等待其他所有参与者响应完成，这期间将无法进行其他任何操作，导致同步阻塞，极大地限制了分布式系统的性能。
> 
> **即：1.参与者需要等待协调者操作才能进行下阶段操作 2.协调者需要等待所有参与者的响应。**
> 
> **单点问题：**协调者是二阶段提交协议中的重要角色，一旦它出现问题，整个二阶段提交流程都无法运转。要是在阶段二出现问题的话，那所有参与者都将会一直处于锁定事务资源的状态中，无法继续完成事务操作。
> 
> **数据不一致：**在协调者给所有参与者发送Commit请求后，由于局部网络异常或者协调者没有发送完Commit请求之前自身发生了崩溃的话，只有部分参与者接收到了Commit请求，这部分参与者会进行事务的提交，而没有接收到Commit请求的参与者无法进行事务提交，最后导致整个分布式系统出现数据不一致的情况。
> 
> **即：网络原因造成一部分参与者收到消息，一部分参与者没有收到消息。**
> 
> **太过保守：**当协调者指示参与者进行事务提交询问的过程中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，这是协调者只能依靠自身的超时机制来判断是否需要中断事务，这种策略就比较保守。
> 
> 换句话说，二阶段提交协议没有设计较为完善的容错机制，任意一个节点的失败都会导致整个事务的失败。

### 3PC----三阶段提交 ###

![544015fd1bb84a79a5319f5e4a654e17.jpeg][]

**三阶段提交分为三个阶段，分别是canCommit、preCommit、doCommit**

#### 阶段一：canCommit ####

1.首先是事务询问，协调者向所有参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并等待各参与者的响应。2.各参与者向协调者反馈事务询问的响应，参与者接收到协调者的canCommit请求后，若判断自己可以顺利执行事务，则向协调者反馈YES响应，否则反馈No响应。

#### 阶段二：preCommit（有两种情况） ####

（1）执行事务预提交：所有参与者反馈都是YES响应

1.发送预提交请求，协调者向所有参与者节点发送preCommit请求并进入Prepared阶段。2.事务预提交，参与者接收到preCommit请求后，会执行事务操作并将Undo和Redo信息记录到事务日志中。3.各参与者向协调者反馈事务执行的响应，如果参与者成功执行了事务操作，会向协调者反馈Ack响应，同时等待最终指令：提交（Commit）或者终止（abort）。

（2）中断事务：第一阶段的反馈中有 NO，或者协调者等待超时，则向所有的参与者发送中断请求。

#### 阶段三：doCommit（有两种情况） ####

**（1）执行提交**

1.如果协调者收到第二阶段的所有参与者的 ack 请求，则向参与者发送 docommit 请求，执行事务的提交。2.参与者收到 docommit 请求后执行事务的提交，成功后释放事务资源，3.并向协调者发送 ACK 反馈。4.协调者收到所有的参与者反馈后，完成事务的提交。

**（2）中断事务**

1.若协调者等待超时，或者第二阶段中有参与者发送 NO 反馈，则向所有参与者发送中断请求。2.参与者收到后执行事务回滚，回滚结束后释放事务资源。3.参与者向协调发送 ACK 响应，4.协调者收到所有的 ACK 响应后中断事务。

> **需要注意的是，一旦进入阶段三，可能会存在以下两种故障：**
> 
> （1）协调者出现问题
> 
> （2）协调者和参与者之间的网络出现故障
> 
> 无论出现那种情况，最终都会导致参与者无法及时接收到来自协调者的doCommit或是abort请求，针对这样的异常情况，参与者都会在等待超时之后，继续进行事务提交。

#### 三阶段提交协议优缺点： ####

**优点：**解决了同步阻塞问题（超时提交策略，第三阶段参与者等待超时后会提交事务），并且能够在出现单点故障后继续达成一致。

**缺点：**数据不一致

> **数据不一致：**参与者接收到preCommit消息后，如果网络出现分区，此时协调者所在的节点和参与者无法进行正常的网络通信，这种情况下该参与者依然会进行事务的提交，这必然出现数据不一致的情况。

[9e8ce296843341cdb57b35803a68d27b.jpeg]: https://img-blog.csdnimg.cn/9e8ce296843341cdb57b35803a68d27b.jpeg
[544015fd1bb84a79a5319f5e4a654e17.jpeg]: https://img-blog.csdnimg.cn/544015fd1bb84a79a5319f5e4a654e17.jpeg