一、简介
Zookeeper 是一个开源的分布式的，为分布式框架提供协调服务的 Apache 项目。
从设计模式角度来理解：Zookeeper 是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经注册的那些观察者做出相应的反应。即：Zookeeper = 文件系统 + 通知机制
1.1 Zookeeper 主要特点
- Zookeeper 是由一个领导者（Leader），多个跟随者（Follower）组成的集群
- 集群中只要有半数以上节点存活，Zookeeper 集群就能正常服务。所以Zookeeper适合安装奇数台服务器
- 全局数据一致：每个 Server 保存一份相同的数据副本，Client 无论连接到哪个Server，数据都是一致的
- 更新请求顺序执行：来自同一个 Client 的更新请求按其发送顺序依次执行
- 数据更新原子性：一次数据更新要么成功，要么失败
- 实时性：在一定时间范围内，Client 能读到最新数据
1.2 数据结构
ZooKeeper 数据模型的结构与 Unix 文件系统很类似，整体上可以看作是一棵树，每个节点称做一个 ZNode。每一个 ZNode 默认能够存储 1MB 的数据，每个 ZNode 都可以通过其路径唯一标识。
1.3 应用场景
主要应用场景包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡、分布式锁等。
二、ZK基础
2.1 安装部署
下载地址：官方网站
安装部署：参考http://www.manongjc.com/detail/26-ivfmoclzffihdfz.html
Zookeeper 中的配置文件 zoo.cfg中参数含义解读如下:
- tickTime = 2000：通信心跳时间，Zookeeper 服务器与客户端心跳时间，单位毫秒
- initLimit = 10：Leader 和 Follower 初始连接时能容忍的最多心跳数（tickTime的数量）
- syncLimit = 5：Leader 和 Follower 之间通信时间如果超过 syncLimit * tickTime，Leader认为 Follwer 死掉，从服务器列表中删除 Follwer
- dataDir：保存 Zookeeper 中的数据。注意：默认的 tmp 目录，容易被 Linux 系统定期删除，所以一般不用默认目录
- clientPort = 2181：客户端连接端口，通常不做修改
2.2 主要api
| 命令基本语法 | 功能描述 |
|---|---|
| help | 显示所有操作命令 |
| ls path | 查看当前 znode 的子节点 [可监听] -w 监听子节点变化 -s 附加次级信息 |
| create | 普通创建 -s 含有序列 -e 临时(重启或者超时消失) |
| get path | 获得节点的值 [可监听] -w 监听节点内容变化 -s 附加次级信息 |
| set | 设置节点的具体值 |
| stat | 查看节点状态 |
| delete | 删除节点 |
| deleteall | 递归删除节点 |
2.3 节点类型
- 短暂/持久：客户端和服务器端断开连接后，创建的节点删除/不删除
- 有序号/无序号：创建节点时设置顺序标识，节点名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护。在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通 过顺序号推断事件的顺序
三、原理
3.1 选举机制
初次选举
如上图，5台机器组成的集群初次选举流程：
- 服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上(3票)，选举无法完成，服务器1状态保持为 LOOKING;
- 服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的 myid 比自己目前投票推举的服务器1大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持 LOOKING
- 服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服
务器3的票数已经超过半数，服务器3当选 Leader。服务器1，2更改状态为 FOLLOWING，服务器3更改状态为 LEADING; - 服务器4启动，发起一次选举。此时服务器1，2，3已经不是 LOOKING 状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING
- 服务器5启动，同4一样当小弟
非初次选举
非初次选举选举 Leader 规则:
- EPOCH 大的直接胜出
- EPOCH 相同，ZXID（事务id）大的胜出
- ZXID 相同，SID（服务器id）大的胜出
依然如上图，假设5台服务器 SID 分别为1、2、3、4、5，ZXID 分别为8、8、8、7、7，并且此时 SID 为3的服务器是 Leader。某一时刻，3和5服务器出现故障，因此开始进行 Leader 选举:
SID为1、2、4的机器投票情况（EPOCH，ZXID，SID）分别为 : (1，8，1)，（1，8，2），（1，7，4），因此服务器2当选为新的 Leader。
3.2 监听器原理
- 首先客户端会创建一个 main() 线程
- 在main线程中创建 Zookeeper 客户端，这时就会创建两个线程，一个负责网络连接通信（connet），一个负责监听（listener）
- 通过 connect 线程将注册的监听事件发送给 Zookeeper
- 在 Zookeeper 的注册监听器列表中将注册的监听事件添加到列表中
- Zookeeper 监听到有数据或路径变化，就会将这个消息发送给 listener 线程
- listener 线程内部调用了process() 方法
常见的监听方式
- 监听节点数据的变化：get path [watch]
- 监听子节点增减的变化：ls path [watch]
3.3 写数据流程
写入请求直接发送给 Leader 节点：
写入请求发送给 Follower 节点，Follower 会转发给 Leader 节点处理：
四、相关理论
- 拜占庭将军问题
拜占庭将军问题是一个协议问题，拜占庭帝国军队的将军们必须全体一致的决定是否攻击某一支敌军。问题是这些将军在地理上是分隔开来的，并且将军中存在叛徒。叛徒可以任意行动以达到以下目标：欺骗某些将军采取进攻行动；促成一个不是所有将军都同意的决定，如当将军们不希望进攻时促成进攻行动；或者迷惑某些将军，使他们无法做出决定。如果叛徒达到了这些目的之一，则任何攻击行动的结果都是注定要失败的，只有完全达成一致的努力才能获得胜利。 - Paxos算法
一种基于消息传递且具有高度容错特性的一致性算法，解决的问题就是如何快速正确的在一个分布式系统中对某个数据值达成一致，并且保证不论发生任何异常都不会破坏整个系统的一致性。 - ZAB协议
借鉴了 Paxos 算法，是特别为 Zookeeper 设计的支持崩溃恢复的原子广播协议。包括两种基本的模式：消息广播、崩溃恢复。基于该协议，Zookeeper 设计为只有一台客户端（Leader）负责处理外部的写事务请求，然后 Leader 客户端将数据同步到其他 Follower 节点（即 Zookeeper 只有一个 Leader 可以发起提案） - CAP理论
CAP理论是说，一个分布式系统不可能同时满足以下三种：
- 一致性(Consistency)：在分布式环境中，一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态
- 可用性(Available)：可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果
- 分区容错性(Partition Tolerance)：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障
这三个基本需求，最多只能同时满足其中的两项。因为P是必须的，因此往往选择就在CP或者AP中。ZooKeeper保证的是CP：
- ZooKeeper不能保证每次服务请求的可用性。在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果
- 进行Leader选举时集群都是短暂不可用
