1、zab协议
分布式一致性协议包括proxy，但是 ZooKeeper并没有完全采用Paxos算法，而是使用了一种称为ZooKeeper Atomic Broadcast(ZAB,zookeeper原子消息广播协议)的协议作为其数据一致性的核心算法。
ZAB协议是为分布式协调服务ZooKeeper专门设计的一种支持漰溃恢复的原子广播协议。
所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器称为Leader服务器，而余下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal(提议)，并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。
1、简述ZAB协议
zab协议是一种支持崩溃恢复的原子广播协议，他能够保证集群中各个副本数据的一致，支持全局唯一的变更序列，支持崩溃恢复。
2、zab如何做个各个副本数据的一致？
在zab中只有leader可以处理事务请求，把数据变更的操作以事务proposal的形式广播给集群中所有的节点，然后等待反馈，如果超过半数节点都通过，再次发送commit请求完成数据变更。
3、zab如何保证数据变更的全局顺序？
通过zxid来保证，zxid是一个64位的数字，前32位是一个epoch编号，每次领导选举之后就会加1，后32位是一个自增的序列，每个事务请求自动加1，并且leader会为所有的follwer维护一个发送队列，将发送的proposal按照先后顺序存入队列中依次发送。
4、zab如何支持崩溃恢复？
集群中所有的服务器都以长连接的形式保持通信，如果集群中超过一半以上的follwer无法连接到leader，就会自动进入领导选举，进而选举出新的leader
5、zab的工作模式简介
zab有两种工作模式，一种是恢复模式，一种是广播模式。恢复模式下进行领导选举，广播模式处理事务请求。
6、简述领导选举过程
首先服务器将自身状态转换为looking，并向集群中所有的服务器发起投票（myid,zxid）
接收其他服务器发送的投票，并进行处理，按照zxid最大的作为leader，如果相同按照myid最大的作为leader，更新投票信息，再次向集群发送投票
统计投票结果，超过半数以上的投票即为leader
如果leader是自己，就把自己的状态变更为leading，否则变为follwing
7、简述事务请求的过程
只有leader可以处理事务请求，follwer接收到事务请求后要转发给leader
leader以proposal的形式发送给所有的follwer，等待响应
follwer接收到请求后首先记录事务日志，然后返回响应
如果超过半数以上的follwer都返回正确的响应，再次向所有follwer发送commit请求
follwer开始变更内存数据库
最后响应客户端
8、watcher机制简介
客户端使用watchmanager来存储注册节点和watcher对象的映射
客户端向服务端发送注册路径和状态信息，服务端会把路径和当前的连接servercnxn存储在内部的watchmanager中
一旦节点数据有变化就从watchmanager中查出servercnxn，并回调process
回调客户端，客户端从watchmanager中取出watcher，执行回调逻辑
9、zookeeper是如何保证原子更新的？
采用乐观锁，类似JDK中的cas操作，读取数据，校验，提交，使用version来校验数据从读取后有没有发送变化
10、sessionId是如何生成的，如何保证其全局唯一？
sessionId是64位的数字，前8位是myid，后56位是当前的时间戳
11、简述zookeeper会话管理
zk使用会话管理器sessiontracker来管理session。sessiontracker使用分桶策略来管理session，客户端创建或刷新session的时候会按超时时间来把session放到不同的桶里。后台有一个专门线程负责来在固定的时间点定时检查session，如果session在超时时间范围内已经刷新，就会被重新放到新的桶里，如果没有刷新就会被清理掉。
12、简述zk的数据存储
zk事务日志
zk dump，定期dump，可以配置日志记录数量超过多少次之后就可以把内存中的数据dump到快照文件中去。
