一、zookeeper概述
Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，zookeeper就将负责同志已经在zookeeper上注册的哪些观察者做出相应的反应。
Zookeeper = 文件系统+通知机制
二、特点
1）Zookeeper：一个领导者（Leader），多个跟随者（Follower）组成的集群
2）集群中只要有半数以上（大于半数）节点存活，Zookeeper集群就能正常服务。所以Zookeeper是和安装奇数台服务器
3）全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server。数据都是一样的。
4）更新请求顺序执行，来自同一个Client的更新请求按其发送顺序依次执行。
5）数据更新原子性，一次数据更新要么成功，要么失败
6）实时性，在一定时间范围内，Client能读到最新数据。
三、Zookeeper数据结构
Zookeeper数据模型的结构与Unix文件系统很类似，整体上可以看作一棵树，每个节点称作一个ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。
四、Zookeeper应用场景
1.数据发布/订阅
2.负载均衡
3.命名服务
4.分布式协调和通知
五、zookeeper的安装
（1）zookeeper的服务端启动 ./zkServer.sh start
（2）客户端的启动：./zkCli.sh
（3）服务端的状态查询：./zkServer.sh status
（4）退出客户端：quit
六、zookeeper配置文件参数
（1）ticktime=2000：通信心跳时间，Zookeeper服务器与客户端心跳时间，单位毫秒。
（2）initLimit=10：L(leader)F(fololwer)初始通信时间，Leader和fololwer 初始连接时能容忍的最多心跳数。（tickTime * initLimit为时间）
（3）syncLimit=5：LF同步通信时通信时限，Leader和fololwer 之间通信时间如果超过syncLimit * ticktime，Leader认为Follower死掉，从服务器列表中删除Follower。
（4）datadir:保存Zookeeper中的数据
（5）clientPort=2181：
七、集群操作
（1）奇数台服务器（最少三台）安装Zookeeper
（2）配置服务器编号
在zoo.cfg配置的datadir目录下创建一个myid的文件
在文件中添加与server对应的数字编号（注意上下不要有空行，左右不要有空格）
注意：添加myid文件，一定要在linux里面创建，在nodepad++里面很可能是乱码
（3）在集群中的zoo.cfg都增加服务器编号配置
server.1=127.0.0.1:2281:3281 server.2=127.0.0.1:2282:3282 server.3=127.0.0.1:2283:3283
配置参数解读：
server.A=B:C:D
A是myid中配置的服务器编号；Zookeeper启动时读取myid文件，拿到里面的数据与zoo.cnf里面的排至信息比较从而判断到底是哪个server。
B是这个服务器的地址
C:是这个服务器Follower与集群中的leader服务器交换信息的端口
D:是万一集群中的leader服务器挂掉了，需要一个端口来重新进行选举，选出一个新的leader，而这个端口就是用来执行选举时服务器相互通信的端口。
八、单服务器模拟多服务器部署zookeeper
tickTime=2000 initLimit=10 syncLimit=5 dataDir=/usr/local/zookeeper/zookeeper02/zkData dataLogDir=/usr/local/zookeeper/zookeeper02/log clientPort=2182 server.1=localhost:2281:3281 server.2=localhost:2282:3282 server.3=localhost:2283:3283
1. 记得修改dataDir，dataLogDir一定要一一对应，不能重复，要不然会因为冲突导致服务无法启动
2. myid的目录一定要配置在dataDir的目录下。
3.如果有报错，请查看logs目录下的日志。
九、Zookeeper选举机制-第一次启动、
假设5台服务器
（1）服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上(3票)，选举无法完成，服务器1的状态为LOOKING；
（2）服务器2启动，再发起一次选举。服务器1和2分别投自己一票交换选票信息：此时服务器1发现服务器2的myid比自己目前投票选举的更大，更改为选举服务器2.此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1,2状态保持LOOKING.
(3)服务器3启动，再发起一次选举。服务器1和2都会更改选票为服务器3.此次投票结果：服务器1为0票，服务器2位0票，服务器3的票数已经超过半数，服务器3当选Leader。服务器1,2更改状态为FOLLOWING，服务器3更改状态为LEADER。
（4）服务器4启动，再发起一次选举。服务器1和2,3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING;
（5）服务器5启动，同4一样当小弟。
十、Zookeeper选举机制-非第一次启动
10.1 概念
（1）SID：服务器ID。用来唯一 标志一台Zookeeper集群中的机器，每台机器不能重复，和myid一致。
（2）ZXID:客户端每次写操作都有事务id。ZXID是一个事务ID，用来表示一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和Zookeeper服务器对于客户端“更新请求”的处理逻辑有关。
（3）Epoch：每个Leader任期的代号。没有Leader时同一轮投票过程中的逻辑时钟是相同的。每投完一次这个数据就会增加。
10.2 Leader选举机制
（1）当Zookeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选举：
- 服务器初始化启动
- 服务器运行时无法和Leader保持连接。
（2）而当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态：
- 集群中本来就已经存在一个Leader
对于已经存在Leader的情况，机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可。
- 集群中确实不存在Leader。
假设Zookeeper由5台服务器组成，SID分别为1,2,3,4,5，ZXID分别为8、8、8、7、7，并且此时SID为3的服务器是Leader。某一时刻，3和5服务器出现故障，因此开始进行leader选举。
选举的规则为：（EPOCH,ZXID,SID）
1.EPOCH大的直接胜出
2.EPOCH相同，ZXID大的直接胜出
3.EPOCH和ZXID相同，SID大的直接胜出
