Zookeeper浅析常见的问题

Zookeeper工作机制

从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关系的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知Zookeeper上的那些观察者做出相应的反应。

Zookeeper = 文件系统 + 通知机制

Zookeeper特点

一个领导者（Leader），多个跟随者（Follower）组成的集群。
集群中只要有半数以上的节点存活，Zookeeper就能正常服务。
全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
更新请求顺序进行，来自同一个Client的更新请求按其发送顺序依次进行。
数据更新原子性，一次数据要么全部更新成功，要么全部失败。
实时性，在一定时间范围内，Client能读到最新数据。（文件内容小）

选举机制（面试重点）

半数机制：集群中半数以上的机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。
Zookeeper配置文件中并没有声明Leader与Follower，是通过内部的选举机制选举出来的。
假设有五台服务器组成的 Zookeeper 集群，它们的 id 从 1-5，同时它们都是最新启动的，

也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来

看看会发生什么：

（1）服务器 1 启动，发起一次选举。服务器 1 投自己一票。此时服务器 1 票数一票，

不够半数以上（3 票），选举无法完成，服务器 1 状态保持为 LOOKING；

（2）服务器 2 启动，再发起一次选举。服务器 1 和 2 分别投自己一票并交换选票信息：

此时服务器 1 发现服务器 2 的 ID 比自己目前投票推举的（服务器 1）大，更改选票为推举

服务器 2。此时服务器 1 票数 0 票，服务器 2 票数 2 票，没有半数以上结果，选举无法完成，

服务器 1，2 状态保持 LOOKING

（3）服务器 3 启动，发起一次选举。此时服务器 1 和 2 都会更改选票为服务器 3。此

次投票结果：服务器 1 为 0 票，服务器 2 为 0 票，服务器 3 为 3 票。此时服务器 3 的票数已

经超过半数，服务器 3 当选 Leader。服务器 1，2 更改状态为 FOLLOWING，服务器 3 更改

状态为 LEADING；

（4）服务器 4 启动，发起一次选举。此时服务器 1，2，3 已经不是 LOOKING 状态，

不会更改选票信息。交换选票信息结果：服务器 3 为 3 票，服务器 4 为 1 票。此时服务器 4

服从多数，更改选票信息为服务器 3，并更改状态为 FOLLOWING；

（5）服务器 5 启动，同 4 一样当小弟。

节点类型

持久（Persistent）：客户端与服务端断开连接后，创建节点不删除
短暂（Ephemeral）：客户端与服务端断开连接后，创建节点自动删除

监听器原理

首先要有一个main()主线程
main线程内有一个connect线程，一个watch监听器线程
connect负责连接到zookeeper集群，注册相关的监听器信息
当zookeeper集群被监听的节点发送了变动，就会回调给监听器线程，监听器线程调用process()方法进行业务处理

写数据流程

client向一个zookeeper集群server1发起一个写数据请求，server1向leader发送写入的数据，leader再分发给所有的follower，当有半数以上的follower接受成功了的时候，就代表数据写入成功了，leader再返回成功的信息给server1，server1再返回给client。