知识要点:
ZAB协议
ZooKeeper Session会话
StaticHostProvider
Chroot命名空间
关于ZXID
ZXID是一个64位的数据结构。分为高32位,低32位。(由Leader产生, 而且它是自增唯-有顺序性)
高32位用来存储epoch (年号)。
低32位用来存储事务编号。
有2种情况导致高32位会变化:
■事务编号满了，触发Leader选举。
■Leader重新选举。
所有的事物性操作都是由Leader来进行的，即便这个请求是Follower接收到，Follower也会把这个事务性请求转发给Leader。
ZAB协议
什么是ZAB协议
ZooKeeper并没有完全采用Paxos算法，而是使用了一种称之为ZooKeeper Atomic Broadcat (ZAB,ZooKeeper原子消息广播协议)的协议作为其数据一致性的核心算法。
ZAB协议并不像Paxos算法那样，是一种通用的分布式一致性算法，它是一种特别为ZooKeeper设计的崩溃恢复的原子消息广播算法。ZooKeeper采用一 一个单-的主进程接受并处理客户端的所有事务请求，并将服务器数据的状态变更以事务Proposal的形式广播到所有的副本进程上去。
ZAB协议包含两种基本的模式:
■崩溃恢复
■消息广播
ZAB协议包含三个阶段:
阶段1:发现(Leader选举过程)
阶段2:同步(数据同步过程)
阶段3:广播(正式接受请求过程)
崩溃恢复
当整个服务器在启动过程中，或者当Leader服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB协议就会进入恢复模式并通过选举产生新的Leader服务器。
当选举产生了新的Leader服务器，同时集群中已经有过半机器与该Leader服务器完成状态同步之后,ZAB协议就会退出恢复模式。这里的状态同步指的就是数据同步，用来保证集群中存在过半的机器能够和L eader服务器的数据保持一致。
■当集群中有过半的Follower服务器完成和Leader服务器的同步，那么整个服务器集群就可以进入消息广播模式。
■当新的机器加入集群，由于集群已经存在一个Leader, 那么新加入的机器会进入数据同步模式，即找到Leader服务器，并与其进行数据同步。
■当Leader崩溃退出或者重启，或者及集群中不存在过半的服务器可以和Leader保持正常通信，那么在开始新一轮事务操作前所有机器会使用崩溃恢复协议来达到一个一致性的状态。
消息广播
消息广播类似于-个2PC提交过程。根据客户端的事务请求，Leader服务器会为其生成对应的事务投票(即Proposal)并将其发送给集群中其他服务器，然后在分表搜集各自的选票，最后进行事务提交。
与2PC不同的是，ZAB协议没有中断逻辑(所有Follower要么对Leader提成的事务Ack,要么就不回应)，而且当过半的Follower服务器反馈Ack之后就开始提交事务，不用等待所有Follower都反馈。
整个消息广播协议是基于FIFO特性的TCP协议来进行网络通信，因此能够很容易地保证消息广播过程中消息接受与发送的顺序性。
ZAB和Paxos
ZAB和Paxos的本质区别在于设计目标不同，ZAB用于构建一个高可 用的分布式数据系统，而Paxos则用于构建一个分布式一致性状态机系统。
数据同步
数据同步过程就是将Leader服务器上面的数据同步到其他给其他服务器的过程。
直接差异化同步
举例，某个时刻Leader服务 器的事务队列对应的ZXID依次是:
0x200000001, 0x200000002, 0x200000003，0x200000004，0x200000005
而需要数据同步的服务器最后处理的ZXID为:
0x200000003
这种场景就执行“直接差异化同步”,Leader会依次将02x00000004, 0x200000005同步给服务器，同步
过程中顺序如下:
StaticHostProvider
己实现了一种轮询机制
ZooKeeper Session会话
■CONNECTING (正在连接)
■CONNECTED (已经连接)
■RECONNECTING (重新连接)
■RECONNECTED (重新连接上)
■CLOSE (关闭)
