【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后，若是网络出现分区，部分网络没法通讯，任然会出现数据不一致的可能