四、Zookeeper集群一致性协议ZAB解析和领导选举算法实现

前言：

之前第一部分讲解过CAP、BASE理论，基本上可以概述为：致力于打造一个，平时系统要求是基本可用，除开成功失败，运行有可容忍的延迟状 态，但是，无论如何经过一段时间的延迟后系统最终必须达成数据是一致的。

一、2pc : 两阶段提交

• 首先第一阶段叫准备阶段，事务的请求都发送给一个个的资源，这里的资源可以是数据库，也可以是其他支持事务 的框架，他们会分别执行自己的事务，写日志到 undo 与 redo，但是不提交事务。
• 当事务管理器收到了所以资源的反馈，事务都执行没报错后，事务管理器再发送 commit 指 令让资源把事务提交，一旦发现任何一个资源在准备阶段没有执行成功，事务管理器会发送rollback，让所有的资源都回滚。这就是 2pc，非常非常简单。

1、缺点

• 同步阻塞
  在二阶段提交的过程中，所有的节点都在等待其他节点的响应，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。
• 单点问题
  协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将 无法运转。更重要的是，其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成 事务操作。
• 数据不一致
  假设当协调者向所有的参与者发送 commit 请求之后，发生了局部网络异常，或者是协调者 在尚未发送完所有 commit 请求之前自身发生了崩溃，导致最终只有部分参与者收到了commit 请求。这将导致严重的数据不一致问题。
• 容错性不好
  二阶段提交协议没有设计较为完善的容错机制，任意一个节点是失败都会导致整个事务的失 败。

二、3pc : 三阶段提交

• 第一阶段 canCommit：确认所有的资源是否都是健康、在线的

就因为有了这一阶段，大大的减少了 2 段提交的阻塞时间，在 2 段提交，如果有 3 个数据库, 恰恰第三个数据库出现问题，其他两个都会执行耗费时间的事务操作，到第三个却发现连接 不上。3 段优化了这种情况

• 第二阶段 PreCommit
  如果所有服务都 ok，可以接收事务请求，这一阶段就可以执行事务了，这时候也是每个资 源都回写 redo 与 undo 日志，事务执行成功，返回 ack(yes),否则返回 no

• 第三阶段 doCommit

  这阶段和前面说的 2 阶段提交大同小异，这个时候协调者发现所有提交者事务提交者事务都正常执行后，给所有资源发送 commit 指令。

  和二阶段提交有所不同的是，他要求所有事务在协调者出现问题，没给资源发送 commit 指令的时候，三阶段提交算法要求资源在一段时间超时后回默认提交做 commit 操作。

  这样的要求就减少了前面说的单点故障，万一事务管理器出现问题，事务也回提交。

但回顾整个过程，不管是 2pc,还是 3pc，同步阻塞，单点故障，容错机制不完善这些问题都 没本质上得到解决，尤其是前面说得数据一致性问题，反而更糟糕了

三、Paxos 算法

• 第一阶段
  提议者对接收者吼了一嗓子，我有个事情要告诉你们，当然这里接受者不只一个，它也是个分布式集群

  相当于星期一开早会，可耻的领导吼了句:“要开会了啊，我要公布一个编号为 001 的提案， 收到请回复”。

  这个时候领导就会等着，等员工回复 1“好的”，如果回复的数目超过一半，就会进行下一 步。

  如果由于某些原因(接收者死机，网络问题，本身业务问题)，导通过的协议未超过一半，、这个时候的领导又会再吼一嗓子，当然气势没那凶残:“好了，怕了你们了，我要公布一个 新的编号未 002 的提案，收到请回复 1”【就其实和老师讲课很像，老师经常问听懂了吗? 听懂的回 1，没懂的回 2，只有回复 1 的占了大多数，才能讲下个知识点】

• 第二阶段
  接下来到第二阶段，领导苦口婆心的把你们叫来开会了，今天编号 002 提案的内容是:“由 于项目紧张，今天加班到 12 点，同意的请举手”这个时候如果绝大多少的接收者都同意， 那么好，议案就这么决定了，如果员工反对或者直接夺门而去，那么领导又只能从第一个阶 段开始:“大哥，大姐们，我有个新的提案 003，快回会议室吧。。”

四、ZK解决一致性的协议

1、集群中的角色

• Leader集群工作机制中的核心
  事务请求的唯一调度和处理者，保证集群事务处理的顺序性 集群内部个服务器的调度者(管理 follower,数据同步)
• Follower 集群工作机制中的跟随者
• 处理非事务请求，转发事务请求给 Leader 参与事务请求 proposal 投票
  参与 leader 选举投票
• Observer 观察者
  3.30 以上版本提供，和 follower 功能相同，但不参与任何形式投票处理非事务请求，转发事务请求给 Leader 提高集群非事务处理能力

2、Zookeeper 集群一致性协议 ZAB 解析

zab 协议核心是在整个 zookeeper 集群中只有一个节点既 leader 将所有客户端的写操作转化 为事务(提议 proposal).leader 节点再数据写完之后，将向所有的 follower 节点发送数据广 播请求(数据复制)，等所有的 follower 节点的反馈，在 zab 协议中，只要超过半数 follower 节点反馈 ok,leader 节点会向所有 follower 服务器发送 commit 消息，既将 leader 节点上的数 据同步到 follower 节点之上。

发现，整个流程其实和 paxos 协议其实大同小异。说 zab 是 paxos 的一种实现方式其实并不 过分。

Zab 再细看可以分成两部分。第一的消息广播模式，第二是崩溃恢复模式

2.1、消息广播模式

1. 客户端发起一个写操作请求
2. Leader 服务器将客户端的 request 请求转化为事物 proposql 提案，同时为每个 proposal 分 配一个全局唯一的 ID，即 ZXID。
3. leader 服务器与每个 follower 之间都有一个队列，leader 将消息发送到该队列
4. follower 机器从队列中取出消息处理完(写入本地事物日志中)毕后，向 leader 服务器发送 ACK 确认。
5. leader 服务器收到半数以上的 follower 的 ACK 后，即认为可以发送 commit
6. leader 向所有的 follower 服务器发送 commit 消息。

zookeeper 采用 ZAB 协议的核心就是只要有一台服务器提交了proposal，就要确保所有的服 务器最终都能正确提交 proposal。这也是 CAP/BASE 最终实现一致性的一个体现。

回顾一下:前面还讲了 2pc 协议，也就是两阶段提交，发现流程 2pc 和 zab 还是挺像的， zookeeper 中数据副本的同步方式与二阶段提交相似但是却又不同。二阶段提交的要求协调 者必须等到所有的参与者全部反馈 ACK 确认消息后，再发送 commit 消息。要求所有的参与 者要么全部成功要么全部失败。二阶段提交会产生严重阻塞问题，但 paxos 和 zab 没有这要 求。

为了进一步防止阻塞，leader 服务器与每个 follower 之间都有一个单独的队列进行收发消息， 使用队列消息可以做到异步解耦。leader 和 follower 之间只要往队列中发送了消息即可。如 果使用同步方式容易引起阻塞。性能上要下降很多.

2.2、崩溃恢复

新选举出来的 leader 不能包含未提交的 proposal，即新选举的 leader 必须都是已经提交了的 proposal 的 follower 服务器节点。同时，新选举的 leader 节点中含有最高的 ZXID。这样做的 好处就是可以避免了 leader 服务器检查 proposal 的提交和丢弃工作。

1. 每个Server会发出一个投票,第一次都是投自己。投票信息:(myid，ZXID)
2. 收集来自各个服务器的投票
3. 处理投票并重新投票，处理逻辑:优先比较ZXID,然后比较myid
4. 统计投票，只要超过半数的机器接收到同样的投票信息，就可以确定leader
5. 改变服务器状态