Zookeeper快速掌握

1、Zookeeper是什么

Zookeeper类似Eureka。

Zookeeper负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper负责通知已经在Zookeeper上注册的观察者做出相应的反应。

类似医院挂号平台的挂号提醒功能，患者（观察者）点击挂号提醒，医生出号后通知患者，Zookeeper提供的就是挂号提醒功能。（或者上课老师无法上课，由班长通知到学生，班长也是类似Zookeeper）

所以Zookeeper是一个协调者的角色，没有具体的业务，主要功能就是存数据和变化通知。

2、Zookeeper的特点

• 一个Leader，多个Follower组成集群；
• 集群中只要一半以上节点存活，就能正常工作；
• 全局数据一致，每个节点保存一份完成的相同数据；
• 数据更新原子性，要么所有节点全部成功，要么全部失败

3、Zookeeper的数据结构

这里需要注意的是/znode1-2并不是真实代表Zookeeper的节点，而是每个Zookeeper节点都有一套相同的命名。

4、Zookeeper安装

Zookeeper分为本地模式和分布式模式。

本地模式安装步骤比较简单，如下：

1. 下载
2. 解压
3. 复制zoo_sample为zoo.cfg，并修改配置文件zoo.cfg（修改dataDir不能为tmp）
4. 执行/bin/zkServer.sh start，启动
5. 执行/bin/zkServer.sh status，查看状态

分布式模式安装步骤比本地模式稍复杂一些，如下：

• 下载
• 解压
• 复制zoo_sample为zoo.cfg，并修改配置文件zoo.cfg（修改dataDir不能为tmp）
• 配置文件zoo.cfg新增zk集群配置（所有节点都一样，拥有全套配置，2888为节点间通信端口，3888为节点选举端口）

server.2=hadoop102:2888:3888

server.3=hadoop103:2888:3888

server.4=hadoop104:2888:3888

• 创建myid，里面的值与上面配置server后的数字一致
• xsync zookeeper，向各节点分发安装包，并修改各节点的myid
• 所有节点执行/bin/zkServer.sh start
• 执行/bin/zkServer.sh status，查看状态

5、Zookeeper命令

Zk的命令操作主要针对节点的增删改查。

首先执行zkCli.sh，进入命令行，执行quit退出命令行。

增-创建节点：create /1 abcdef，在根目录/下创建节点1,存储内容为abcedf；

删除-删除节点 delete /1;

删除-递归删除节点 rmr /1;

改-设置节点的值：set /1 efg，将/1的值设置为efg；

查-查看节点的值：get /1获取节点1的值，加watch表示注册节点变化观察，监控set造成的变化，只监控1次；

查-查看当前节点所包含的内容：ls /查看根目录的子节点，加watch表示观察者注册，监控create造成的变化；

增删改查命令，其中删和查都有两个命令，总共6个。

6、Zookeeper的API

Zookeeper的API跟命令内容基本一致。

1.创建Maven工程；

2.添加pom文件，名字就叫zookeeper；

3.创建客户端，Zookeeper zkcli = new Zookeeper(“CDH01:2181”,2000, new Watcher(){…})；

4.查接口(ls): List<String> children = zkcli.getChildren(“/”,new Watcher(){});

5.增接口(create): zkcli.create(…);

6.查接口(get): zkcli.getData(…);

7.改接口(set): zkcli.setData(…);

7、Zookeeper的原理

Zookeeper在安装时没有配置过leader，使用时却有leader和follower之分，就是使用选举机制产生。

• 监听器原理

Zookeeper通过ZAB（ZK原子广播）协议保证全局一致和读写顺序的。ZAB协议的设计参考了Paxos算法。ZAB主要两部分内容：选举leader和顺序读写。

• 选举机制

（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一样当小弟。

• 写数据流程：（类似议院处理提议机制）

以上是正常写入的流程。如果server1同意，server2不同意，投票结果为server2为少数，则server2自认为有问题，会重启并从leader同步数据。

同意与否的判断标准是已写入数据的编号和发来数据编号对比，如果新发来数据编号还小于已写入数据编号，则不同意。