Zookeeper-ZAB协议,角色,选举
Zookeeper-ZAB协议
ZAB协议，并没有使用Paxos算法，而是使用一种称为Zookeeper Atomic Broadcat 原子 消息广播协议，它是一种专为为Zookeeper设计的一种支持崩溃恢复的原子广播协议。
Zookeeper实现了一种主备模式的系统架构来保持集群中各副本之间的数据的一致性。表现就是使用一个单一的主进程秋接收处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器的数据的状态变更以事务 Proposal的形式广播到所有的副本进程中，ZAB协议的主备模型保证了同一时候集群中只能够有一个主进程来广播服务器的状态变更，因此很好的处理客户端大量的并发请求。但是，主进程在任何时候都有可能出现崩溃退出或者重启现象，因此ZAB协议还需要做到当前主进程出现异常情况的进修依旧正常工作。
ＺＡＢ核心
所有事务请求必须由一个全局唯一的服务器来协调处理，这个的服务器称为Leader服务器，余下的服务则称为Follower服务，Leader服务器负责将一个客户端事务请求转化成一个事务Proposal提议，并将该Proposal分发给集群中的所有Follower服务器，之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器时行正确的反馈后，那么Leader就会本地提交Commit，向所有Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。
介绍
包括2种基本模式：崩溃恢复和消息广播
- 崩溃恢复
当整个服务启动过程中，或者是Leader服务器出现网络中断、宕机、崩溃退出或者重启响等异常服务，进入崩溃恢复模式，同时选举产生新的Leader服务器，当前 选举产生新的Leader服务器，
同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式，其中，状态同步，就是数据同步，用来保证集群中过半机器能够和Leader的数据状态保持一致。
- 消息广播
当前集群中有过半的机器与该Leader服务器完成了状态同步之后，那么进行消息广播模式，当一个同样遵守ZAB协议的服务器启动后加入集群中，如果此时集群中已经存在一个Leader服务器在负责进行消息广播，那么新加入的服务器就会自觉进入数据恢复模式：找到Leader所在的服务，并与其时行数据同步，然后一起参数到消息广播中。Zookeeper中只允许唯一的一个Leader服务器来时行事务请求处理。Leader服务器在接收到客户端事务请求后，会生成对象的事务提交并发起一轮广播协议，而如果集群中的其他机器收到客户的事务请求后，那么这个非Leader的服务器会首先将个事务转发给Leader服务器
消息广播
崩溃恢复
ZAB与Paxos的联系和区别
服务器的角色
Leader
Leader服务是Zookeeper集群工作的核心，
- 事务请求的唯一调度和处理者，保证集群事务焉得的顺序性
- 集群内部各服务器的调度者
请求处理链
从PreRequestProcessor到FinalRequestProcessor一共7个请求处理器组成了Leader服务器的请求处理链
Follower
Follower服务器是Zookeeper集群状态中的跟随者。
- 处理客户端非事务请求（读取数据），转发事务请求给Leader服务器
- 参与事务请求ProPosal投票
- 参与Leader选举投票
和Leader一样，Follower 也采用了责任链组装的请求处理连接来处理每个客户端于请求，由于不需要对事务请求的投票处理，
Observer
服务器启动
- 整体结构
Zookeeper服务器的启动，大致可以分为五个步骤
- 配置文件解析
- 初始化数据管理器
- 初始化网络I/O管理器
- 数据恢复
- 对外服务