1、Zookeeper总体架构
应用使用Zookeeper客户端库使用Zookeeper服务。Zookeeper客户端负责和Zookeeper的集群交互。
Zookeeper集群可以有两种模式：standalone模式和quorum模式。
处于standalone模式的Zookeeper集群中只有一个独立运行的Zookeeper节点。
处于quorum模式的Zookeeper集群中包含多个Zookeeper节点。
2、session
Zookeeper客户端库和Zookeeper集群中的节点创建一个session。
客户端可以主动关闭session。
如果Zookeeper节点没有在session关联的timeout时间内收到客户端的数据的话，Zookeeper节点也会关闭session。
另外Zookeeper客户端库如果发现连接的Zookeeper出错，会自动和其他Zookeeper的节点建立连接。
3、Quorum模式
处于Quorum模式的Zookeeper集群包含多个Zookeeper节点。例如下图的Zookeeper集群有三个节点，其中节点1是leader节点，节点2和节点3是follower节点。
leader节点可以处理读写请求，follower节点只可以处理读请求。fllower在接到写请求时会把写请求转发给leader来处理。
4、数据一致性
- 可线性化（Linearizable）写入：先到达leader的写请求会被先处理，leader决定写请求的执行顺序。
- 客户端FIFO顺序：来自给定客户端的请求按照发送顺序执行。
5、底层分布式选举算法
ZAB（ZooKeeper Atomic Broadcast）选举算法是为 ZooKeeper 实现分布式协调功能而设计的。相较于 Raft 算法的投票机制，ZAB 算法增加了通过节点 ID 和数据 ID 作为参考进行选主，节点 ID 和数据 ID 越大，表示数据越新，优先成为主。相比较于 Raft 算法，ZAB 算法尽可能保证数据的最新性。所以，ZAB 算法可以说是对 Raft 算法的改进。使用 ZAB 算法选举时，集群中每个节点拥有 3 种角色：
Leader，主节点；
Follower，跟随者节点；
Observer，观察者，无投票权。
选举过程中，集群中的节点拥有 4 个状态：
Looking 状态，即选举状态。当节点处于该状态时，它会认为当前集群中没有 Leader，因此自己进入选举状态。
Leading 状态，即领导者状态，表示已经选出主，且当前节点为 Leader。
Following 状态，即跟随者状态，集群中已经选出主后，其他非主节点状态更新为 Following，表示对 Leader 的追随。
Observing 状态 ，即观察者状态，表示当前节点为 Observer，持观望态度，没有投票权和选举权。
投票过程中，每个节点都有一个唯一的三元组 (server_id, server_zxID, epoch)，其中 server_id 表示本节点的唯一 ID；server_zxID 表示本节点存放的数据 ID，数据 ID 越大表示数据越新，选举权重越大；epoch 表示当前选取轮数，一般用逻辑时钟表示。
ZAB 选举算法的核心是“少数服从多数，ID 大的节点优先成为主”，因此选举过程中通过 (vote_id, vote_zxID) 来表明投票给哪个节点，其中 vote_id 表示被投票节点的 ID，vote_zxID 表示被投票节点的服务器 zxID。ZAB 算法选主的原则是：server_zxID 最大者成为 Leader；若 server_zxID 相同，则 server_id 最大者成为 Leader。
接下来，以 3 个 Server 的集群为例，此处每个 Server 代表一个节点，介绍 ZAB 选主的过程。
第一步：当系统刚启动时，3 个服务器当前投票均为第一轮投票，即 epoch=1，且 zxID 均为 0。此时每个服务器都推选自己，并将选票信息 <epoch, vote_id, vote_zxID> 广播出去。
第二步：根据判断规则，由于 3 个 Server 的 epoch、zxID 都相同，因此比较 server_id，较大者即为推选对象，因此 Server 1 和 Server 2 将 vote_id 改为 3，更新自己的投票箱并重新广播自己的投票。
第三步：此时系统内所有服务器都推选了 Server 3，因此 Server 3 当选 Leader，处于 Leading 状态，向其他服务器发送心跳包并维护连接；Server1 和 Server2 处于 Following 状态。
总结：
ZAB 算法性能高，对系统无特殊要求，采用广播方式发送信息，若节点中有 n 个节点，每个节点同时广播，则集群中信息量为 n*(n-1) 个消息，容易出现广播风暴；且除了投票，还增加了对比节点 ID 和数据 ID，这就意味着还需要知道所有节点的 ID 和数据 ID，所以选举时间相对较长。但该算法选举稳定性比较好，当有新节点加入或节点故障恢复后，会触发选主，但不一定会真正切主，除非新节点或故障后恢复的节点数据 ID 和节点 ID 最大，且获得投票数过半，才会导致切主。
6、三个节点quorum模式Zookeeper集群（伪集群）构建
1）准备三个配置文件，其中dataDir和clientPort配置项要配置不同的值。三个配置文件的server.n部分都是一样的。同时在每个节点的dataDir目录下，需要创建myid文件，三个节点的myid文件内容分别为1、2和3
node1节点的配置内容:
2）通过以下命令启动集群
zkServer.sh start-foreground /usr/local/apache-zookeeper-3.6.0-bin/conf/zoo-quorum-node1.cfg
zkServer.sh start-foreground /usr/local/apache-zookeeper-3.6.0-bin/conf/zoo-quorum-node2.cfg
zkServer.sh start-foreground /usr/local/apache-zookeeper-3.6.0-bin/conf/zoo-quorum-node3.cfg
说明：start-foreground 选项，让zkServer.sh在前台运行，把日志直接输出到console.如果日志输出到日志文件的话，因为是伪集群模式，会把日志输出到同一个文件。
-
在启动第一个节点的时候，会报一下错误信息：
这是因为我们集群设置的是3个节点，在其他节点还没有启动的情况下，它是无法跟其他节点建立连接的：
05-07启动第一个节点.png -
启动第二个节点，那么现在集群中就存在两个节点了，并且第二个节点为leading状态，即为主节点
05-08启动第二个节点.png
第一个节点为following状态，即跟随者状态:
05-09第一个节点的状态.png -
启动第三个节点，触发选主
第二个节点是主节点：
05-10启动第三个节点.png
第一个和第三个都是跟随者节点：
05-11跟随节点.png
05-12跟随节点.png
其他说明：
启动zookeeper失败提示8080端口被占用，这是zookeeper3.5的特性
Zookeeper AdminServer，默认使用8080端口
05-13AdminServer异常.png
解决方法：
修改zoo.cfg文件的配置，添加如下配置
admin.serverPort=8888
或者在启动脚本中增加 -Dzookeeper.admin.serverPort=端口号.
修改后再次启动zookeeper，查看启动日志，启动成功。
- 使用 zkCli客户端进行连接
zkCli.sh -server 127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183
根据日志，说明跟第一个节点建立了连接，并且也能够正常使用
如果此时杀掉第一个节点，来查看客户端是否能够重连：
此时可以看到，客户端重新连接到了第三个节点，而且也能够正常使用：
