zk集群分为3种角色：1个Leader,多个Follower,一个Observer,其各自的作用：
Leader:负责所有事务请求的处理，以及过半提交的投票发起和决策
Follower:负责接受客户端的非事务请求，而事务请求会转发给leader节点来处理，也就是说follower不处理事务。但它会参与leader选取的一个投票
Observer:负责接受客户端的非事务请求，而事务请求会转发给leader节点来处理，observer不参与投票过程。它只是为了分担zk集群的一个读压力
zk集群是一个中心化架构，由leader节点作为一个决策节点，它专门负责事务请求的处理以及集群各节点的数据同步。这样做的好处就是减少集群各节点之间数据同步的一个复杂度以及zk集群的管理变得更加简单稳定，但是当leader节点宕机会带来一个问题就是leader选举。所以zk集群在leader选举这个期间整个集群是短暂不可用的。leader选举一般出现2种场均，除了前面说的这种情况,还有一种情况就是集群刚启动的时候。接下来看一下leader选举的详细过程：
先看一下集群选举过程中用到的几个重要参数：
- 服务器 ID(myid)：编号越大在选举算法中权重越大
- 事务 ID(zxid)：值越大说明数据越新，权重越大
- 逻辑时钟(epoch-logicalclock)：同一轮投票过程中的逻辑时钟值是相同的，每投完一次值会增加
集群选择中各个机器节点的状态：
- LOOKING: 竞选状态
- FOLLOWING: 随从状态，同步 leader 状态，参与投票
- OBSERVING: 观察状态，同步 leader 状态，不参与投票
- LEADING: 领导者状态
1、服务器启动时的 leader 选举
每个节点启动的时候都 LOOKING 观望状态，接下来就开始进行选举主流程。这里选取三台机器组成的集群为例。第一台服务器 server1启动时，无法进行 leader 选举，当第二台服务器 server2 启动时，两台机器可以相互通信，进入 leader 选举过程。
-
（1）每台 server 发出一个投票，由于是初始情况，server1 和 server2 都将自己作为 leader 服务器进行投票，每次投票包含所推举的服务器myid、zxid、epoch，使用（myid，zxid）表示，此时 server1 投票为（1,0），server2 投票为（2,0），然后将各自投票发送给集群中其他机器。
-
（2）接收来自各个服务器的投票。集群中的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票（epoch）、是否来自 LOOKING 状态的服务器。
-
（3）分别处理投票。针对每一次投票，服务器都需要将其他服务器的投票和自己的投票进行对比，对比规则如下：
- a. 优先比较 epoch，如果不是本轮发出投票则丢弃【因为考虑到节点之间网络通讯的延迟】
- b. 检查 zxid，zxid 比较大的服务器优先作为 leader
- c. 如果 zxid 相同，那么就比较 myid，myid 较大的服务器作为 leader 服务器
-
（4）统计投票。每次投票后，服务器统计投票信息，判断是都有过半机器接收到相同的投票信息。server1、server2 都统计出集群中有两台机器接受了（2,0）的投票信息，此时已经选出了 server2 为 leader 节点。
-
（5）改变服务器状态。一旦确定了 leader，每个服务器响应更新自己的状态，如果是 follower，那么就变更为 FOLLOWING，如果是 Leader，变更为 LEADING。此时 server3继续启动，直接加入变更自己为 FOLLOWING。
2、运行过程中的 leader 选举
当集群中 leader 服务器出现宕机或者不可用情况时，整个集群无法对外提供服务，进入新一轮的 leader 选举。
- （1）变更状态。leader 挂后，其他非 Oberver服务器将自身服务器状态变更为 LOOKING。
- （2）每个 server 发出一个投票。在运行期间，每个服务器上 zxid 可能不同。
- （3）处理投票。规则同启动过程。
- （4）统计投票。与启动过程相同。
- （5）改变服务器状态。与启动过程相同。
3、zab协议
ZAB协议并不像Paxos算法那样 是⼀种通⽤的分布式⼀致性算法，它是⼀种特别为zookeeper专⻔设计 的⼀种⽀持崩溃恢复的原⼦⼴播协议 在zookeeper中，主要就是依赖ZAB协议来实现分布式数据的⼀致性，基于该协议，Zookeeper实现了 ⼀种主备模式的系统架构来保持集群中各副本之间的数据的⼀致性，表现形式就是 使⽤⼀个单⼀的主进 程来接收并处理客户端的所有事务请求，并采⽤ZAB的原⼦⼴播协议，将服务器数据的状态变更以事务 Proposal的形式⼴播到所有的副本进程中，ZAB协议的主备模型架构保证了同⼀时刻集群中只能够有⼀ 个主进程来⼴播服务器的状态变更，因此能够很好地处理客户端⼤量的并发请求。但是，也要考虑到主 进程在任何时候都有可能出现崩溃退出或重启现象，因此,ZAB协议还需要做到当前主进程当出现上述异 常情况的时候，依旧能正常⼯作
ZAB核⼼包括两种基本模式：
1.消息⼴播
ZAB协议的核⼼是定义了对于那些会改变zk服务器数据状态的事务请求的处理⽅。即：所有事务请求必须由⼀个全局唯⼀的服务器来协调处理，这样的服务器被称为Leader服务器，余下的服务器则称为Follower服务器，Leader服务器负责将⼀个客户端事务请求转化成⼀个事务Proposal（提议），并将该Proposal分发给集群中所有的Follower服务器，之后Leader服务器需要等待所有Follower服务器的反馈【过半机制】，⼀旦超过半数的Follower服务器进⾏了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前⼀个Proposal进⾏提交
2.崩溃恢复
也即是leader选举
