zookeeper-2 ZAB协议

zk如果是单点服务, 则不涉及到分布式同步协议的问题, 所有的数据都有一个节点处理即可, 该节点用来同步客户端分布式集群中的消息同步, 然而单点是不可靠的, zk本身也要实现分布式集群以保证高可用高并发的特性. 所以zk自身的分布式集群间的数据同步问题采用了ZAB协议实现, 而对客户端而言, 一个zk集群被视为一个稳定运行的单节点即可

简言之, zk的分布式数据一致性问题依靠ZAB协议实现, 而客户端的分布式一致性问题由zk来实现

关于ZAB协议:(zk只能有一个leader, 其用来负责广播事务请求)

1.ZAB协议包括两种基本模式:  崩溃恢复和广播模式. 其中奔溃恢复包括选举新leader和数据同步两个阶段

2.消息广播过程:

  1) leader服务器会为每个事务请求生成一个proposal, 并为其生成一个单调递增的唯一事务ID(ZXID)

  2) leader服务器为每一个follower生成一个单独的FIFO消息队列, 将proposal放入消息队列中

  3) 每个follower在接收到proposal后将其写入本地磁盘的事务日志中, 并在成功写入后给leader服务器一个ACK相应信号,此时在磁盘就已经存在了事务ID, 以此作为以后的leader选举标准

  4) leader在接收到超过半数的ACK信号后向follower发送一个commit信号, 同时完成自身事务提交

  5) follower在接收到commit信号后完成自身事务提交, (事务提交的意义:将写入到本地磁盘中的日志数据放入到内存数据库中, 客户端使用)

3. zk集群进入崩溃恢复模式的情况: leader崩溃或者由于网络原因导致leader与过半数follower通信联系

4.ZAB协议中保证的两个特性

   1) 确保已经在leader服务器上提交的事务最终被所有服务器提交(执行完2中的第三步)

   2) 确保丢弃那些只在leader服务器上提出的事务(执行完2中的第一步)

5.  针对ZAB协议执行的崩溃恢复过程

   1)选举出follower中具有最大事务ID的节点为新的leader, 对该最大事务ID生成新的事务ID

   2)选举出新的leader后将进行数据同步, 数据同步的过程包括数据更新(ZAB协议中第一特性)和数据回退(ZAB协议中的第二特性)

6.事务ID的生成策略