Zookeeper的应用和ZAB协议简单总结

1.zookeeper

Zookeeper是Apache Hadoop旗下的一款开源的分布式协调框架，它是一个分布式的kv存储系统，他类似于文件系统的目录的方式存储数据，还可以对数据进行监听和管理。

2.zk的数据结构

zk的目录节点可以按照两个维度来划分：是否有序、是否持久。

  - `顺序持久节点`：创建后便持久化，且节点名具有顺序性。
  - `顺序临时节点`：client断开或者timeout后节点消失，有顺序。
  - `持久节点`
  - `临时节点`
  - `Container节点`：zk3.5.3版本新加入的一种节点类型，当容器中没有用任何子节点，该容器节点会被zk定期删除(后台有任务检测)
  - `TTL节点`：节点带有过期时间，一般是禁用的。

3.zk的监听机制

zk的Watch事件机制是一个一次性的触发器，当被设置了watch监听的节点发生了任何变动就会通知加监听事件的客户端。多个客户端可以同时watch同一个节点。
Watch机制支持的类型有：

  - 连接事件
  - 节点创建事件
  - 节点删除事件
  - 节点数据变动事件
  - 子节点变动事件
  - 节点or子节点的监听移除事件

Watch机制的特点：

  - 一次性，一旦事件触发就会移除，需要再次watch。
  - watcher回调是串行化执行。
  - 事件消息小，轻量级。
  - watcher具有时效性，只有当会话彻底失效才会失效。在会话断开后，如果重连成功也是不会失效的。

4.zk的集群

zk集群的节点一共分为三种角色：leader领导者、fllower跟随者、observer观察者。

  - Leader 领导者：写请求的唯一处理者和调度者，保证集群事务处理的顺序性，调度集群内部各个角色。对于所有的创建、修改、删除等写操作都要转发给Leader处理，同时Leader也有处理读请求的能力。
  - Fllower 跟随者：可以处理客户端的读请求，遇到客户端的写请求就转发写请求给Leader；还负责集群的Leader选举投票。
  - Observer 观察者：不参与选举投票，负责读请求的处理。目的是增强集群的读请求能力。

4.1 选举原理

选举过程中有几个重要的参数：

     - 服务器ID：编号越大则在选举中权重越大。
     - 事务ID：值越大说明数据越新，选举权重越大。
     - 逻辑时钟：同一轮投票过程中的逻辑时钟值是相同的，每一轮结束后这个值就会增加。

选举过程大致如下：

     1. 每台服务器都将自己作为leader服务器进行投票，然后将投票信息同步给集群中其他的节点。
     1. 收到其它服务器的节点，首先判断该投票是否是本论的投票等。
     1. 投票信息的对比：事务ID、服务器ID等。
     1. 投票的统计，如果集群中过半数的节点比较出的leader节点一致就代表新的leader产生。
     1. 改变服务器节点的状态，各自安好。

5.ZAB协议

ZAB全称：Zookeeper Atomic Broadcast （zookeeper原子广播协议）。zk没有采用Paxos一致性算法来保证他的一致性特征，而是采用其变种和简化版本ZAB协议来实现。
ZAB协议定义：ZAB协议是为分布式协调服务zookeeper专门设计的一种支持原子广播、崩溃恢复的协议。

2.1 消息广播

ZAB的消消息原子广播类似一个2PC 二阶段提交的过程。客户端的写事务请求，都转交给Leader接受，Leader将该写事务请求发送给所有的Follower，然后根据集群内Follower的反馈来决定是否执行事务提交的命令发放(过半原则：如果Follower超过半数得到ack回应就认为这次写事务可以做提交准备了)。

2.2 崩溃恢复

当Leader宕机或者产生了分区，zk集群就会进入崩溃恢复模式暂停对外提供服务。ZAB提出了2个原则：

     - ZAB协议确保丢弃那些只在Leader提出，但是还没有提交的事务。
     - ZAB协议确保那些已经在Leader提交事务的数据。

ZAB算法能够确保提交已经被Leader提交的事务，同时丢弃已经被跳过的事务。ZAB算法能够保证新选举出来的Leader服务器拥有集群中所有机器事务ID最大。