zookeeper集群中的节点共有三种角色：
- Leader：处理集群中的所有事务请求，包括读和写，集群中只有一个Leader
- Follower：只处理读请求，可以参与Leader选举
- Observer：只处理读请求，但是不能参与Leader选举
ZAB协议
介绍
zookeeper作为⾮常重要的分布式协调组件，需要进行集群部署，集群中通常会以一主多从的方式进行部署。zookeeper为了保证数据的一致性，使用ZAB（zookeeper atomic broadcast）协议，这一协议解决了zookeeper的崩溃恢复和主从数据同步的问题。
ZAB协议的四种节点状态
ZAB中协议定义了四种节点状态：
- Looking：选举状态
- Following：Follower节点的状态
- Leading：Leader节点的状态
- Observing：Observer节点的状态
Leader选举过程
集群上线时的Leader选举
若进行Leader选举，则至少需要两台机器，这里选取3台机器组成的服务器集群为例。在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下：
每个Server发出一个投票。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，其中myid为服务器的唯一标识，ZXID为事务号。此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。
接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。
处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下：
- 优先检查ZXID。ZXID比较大的服务器优先作为Leader。
- 如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。
对于对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时Server2的myid最大，于是更新自己的投票为(2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。
统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader。
改变服务器状态。一旦确定了Leader，每个服务器就会更新自己的状态。
崩溃恢复时的Leader选举
Leader建立完成后，Leader会周期性的不断向Follower发送心跳。当Leader崩溃后，Follower会进入Looking状态，重新进行Leader选举，此时集群不能对外服务。
主从服务器之间的数据同步
- 客户端向Leader节点写数据
- Leader节点把数据写到自己的数据文件中，并给自己返回一个ACK
- Leader把数据发送给Follower
- Follower将数据写到本地数据文件中
- Follower返回ACK给Leader节点
- Leader收到半数以上的ACK后，向Follower发送Commit
- 从节点收到Commit后把数据文件中的数据写到内存中
