【zookeeper】第2篇：一致性协议

2PC

什么是2PC

2PC是Two-Phase Commit的缩写，即二阶提交协议。它是将事务的提交过程分成两个阶段来处理的，分别是提交事务请求阶段和执行事务提交阶段；二阶提交协议常用于保证分布式系统的数据一致性。

提交事务请求阶段

1. 事务提交询问

协调者向参与者发送事务内容，并询问是否可执行事务提交操作，等待参与者的应答结果。

2. 事务执行

参与者对询问的事务内容进行操作，并将Undo和Redo的信息记录到事务日志中。

3. 各参与者给协调者反馈响应结果

反馈结果包括可以执行事务或者不可以执行事务。

二阶提交的第一阶段也可以称作“投票阶段”，即各参与者投票表明是否要继续执行事务提交操作。

执行事务提交阶段

协调者根据参与者的反馈结果决定是否可以进行事务提交操作，一般有以下两种情况：

1. 正常执行事务提交

• 发送事务提交请求
  协调者向参与者发送事务commit请求。
• 执行事务提交
  参与者接受到commit请求后，正式执行事务，并在事务执行完成之后释放资源。
• 反馈事务提交执行结果
  参与者完成事务提交后，向协调者发送ack消息。
• 完成事务
  协调者接收到所有参与者的ack消息后事务完成。

2. 中断事务

• 发送事务回滚请求
  协调者向所有参与者发出rollback请求。
• 执行事务回滚
  参与者接受到rollback请求后，利用第一阶段记录的Undo信息执行事务回滚操，然后释放资源。
• 反馈事务回滚结果
  参与者向协调者发送ack信息。
• 事务中断完成
  协调者收到所有ack消息后表示完成事务中断。

2PC的优缺点

优点

简单易于理解，容易实现。

缺点

• 同步阻塞
  为什么说是同步阻塞呢？因为在执行过程各参与者在等待其他参与者时，将无法执行其他操作。
• 协调者单点
  协调者在整个二阶提交中起到了关键性作用，一旦协调者出现了问题，操作将无法执行下去。
• 存在数据不一致的可能性
  在二阶提交的第二阶段中，即执行事务提交操作时，如果出现网络异常或导致部分参与者接受到了commit请求，部分参与者没有接收到commit请求，此时就会导致数据不一致。

3PC

什么是3PC

3PC是Three-Phase Commit的缩写，即三阶提交，是对二阶提交的改进。

canCommit阶段

• 事务询问
  协调者向参与者发送一个包含事务内容的请求，询问是否可以执行事务提交，并等待参与者响应。
• 各参与者向协调者反馈事务询问结果
  参与者自身认为可以顺利执行事务，则反馈yes，并进入预备状态，否则反馈no。

preCommit阶段

根据阶段一种参与者的反馈结果来决定是否进行preCommit操作，一般有两种可能：

执行事务预提交

协调者从参与者得到的反馈结果都是yes，此时执行事务预提交。

• 协调者向所有参与者发送preCommit请求，并做好事务提交准备
• 事务预提交
  参与者受到preCommit请求，会执行事务预提交，并将Undo和Redo写进日志文件中。
• 参与者反馈执行结果
  如果所有参与者成功执行事务，那么会给给协调者ack响应，同时等待协调者最终的提交(commit)和中止(abort)命令。

中断事务

任何一个参与者反馈了no，或者等待超时，或者协调者无法接受到参与者的结果，那么都会执行事务中断。

• 协调者向参与者发送abort请求
• 中断事务

doCommit阶段

该阶段是事务真正的提交阶段，会存在一下可能性问题：

执行提交

• 发提交请求

协调者接收到了所有参与者的ack响应，它将总“预提交”状态转化为“提交”状态，并向所有参与者发送doCommit请求。

• 参与者执行事务提交，事务提交完成后释放事务占用资源。
• 参与者反馈结果
• 完成事务

中断事务

进入该阶段，假如协调者处于正常工作状态，并且有任意一个参与者反馈了no响应，或者等待超时，或者协调者无法接受反馈结果，那么就中断事务

• 协调者向参与者发送abort请求
• 事务回滚
  参与者收到abort命令后，利用阶段记录的Redo信息来执行事务回滚，完成后是否资源。
• 反馈事务回滚结果
• 中断事务

3PC的优缺点

存在的问题

• 协调者故障
• 协调者和参与者网络故障

无论哪种情况出现，最终会导致参与者无法及时接受到协调者的doCommit或者abort请求，针对这种情况，参与在等待超时后会继续执行相应的事务提交。

优点

• 能够在单点故障后继续达成一致

缺点

• 参与者接收到preCommit后，如果网络出现分区，部分网络无法通信，任然会出现数据不一致的可能