ZAB协议

概述

Zookeeper Atomic Broadcast(原子广播协议)是专门为Zookeeper设计的协议。

这套协议在设计过程中，基于2PC算法来设计，利用PAXOS算法进行了改进

作用：原子广播和崩溃恢复。

原子广播

原子广播是为了保证所有节点数据的一致性。

原子广播基于2PC算法进行改进。

2PC-2 Phase Commit(二阶段提交)，核心思想是“一票否决”。

a.分发阶段：协调者收到请求之后，将请求发送给每一个参与者，然后让参与者去将这个请求进行记录。

b.提交阶段：如果每一个参与者都记录成功，并且协调者收到了所有参与者的成功信号，那么协调者就会要求所有的参与者执行这个请求。

c.中止阶段：如果有一个或者多个参与者返回no，那么协调者就会认为这个请求不可执行，那么协调者就会要求所有的参与者删除这个请求的记录。（如果协调者没有收到参与者的返回信号，也会认为返回的是no）

lead在接收到请求之后，先将这个请求记录到本地的日志文件中（日志文件的位置是由dataDir来决定）.

如果记录成功，leader节点就会将这些请求放入 队列中，然后将队列发送给每一个follower。

follower接收到请求之后，就会将这些请求从队列中依次取出，再写到本地的日志文件中。

如果记录成功，则follower会给leader返回一个成功信息，如果失败则返回失败信号。

如果leader收到一半及以上的follower返回成功信号，那么leader就会认为这个请求可以执行。就会要求所有的follower执行这个请求。如果没有收到一半节点的成功信号，那么leader就会认为这个请求不能执行，会要求所有的follower节点删除对应的记录。

如果某个follower记录失败，而又接收到leader要求执行的命令，这个时候follower就会向leader发送请求重新申请这个任务。

崩溃恢复

1.当集群中的leader因为某些原因产生丢失。集群中会自动去选举出一个新的leader，这个过程就称之为崩溃恢复。

2.崩溃恢复是为了避免Zookeeper集群中出现单点故障。

3.每举出一个leader，就会给leader一个编号，这个编号称之为epochid。每一个leader都会将epochid发送给每一个follower。follower接收到epochid之后存储在zcceptedEpoch中。

4.每一个follower接收到请求之后，都会先比较epochid.

5.在集群中，Zookeeper的事务id实际上是64位二进制数字组成，其它高32位表示的是epochid,低32位才是真正的事务id；

6.当一个节点重新连入集群 之后，这个节点会拿着自己的事务id和当前集群中的事务id进行比较。在比较完成之后，leader就会将确实的操作放入一个队列中发送给这个节点。这个节点在更新过程中不对外服务

观察者

观察者的特点：既不参与投票也不参与选举，但是监听投票和选举结果，然后根据结果来执行任务。

适用场景：集群节点数量多的时候可以将一部分节点设置为观察者。

observer的存活与否并不影响集群是否对外服务。例如一个集群中有21个节点，14个节点是observer,那么即使这14个observer节点全部宕机，该集群也会正常对外提供服务 。

扩展：

Zookeeper如何动态增删节点

Zookeeper的容灾性