Zookeeper概念原理实战

啥是Zookeeper？

Zookeeper是一个分布式的、提供协调服务的Apache开源软件。

基础概念

• Leader ：即Master节点。每个Zookeeper集群只能有一个Master节点，而Master是通过内部选举机制产生的。
• Follower ：即slave节点。每个Zookeeper集群有多个Slave节点。
• 半数机制 ：Zookeeper集群中半数以上机器存活，则集群可用。所以Zookeeper一般都是部署奇数个节点。
• 全局数据一致：每个节点保存一份数据副本，与Master保持一致。无论Client连接哪个节点，数据都是一致的。
• 数据更新顺序一致性：同一个Client的更新请求与发送顺序保持一致。
• 数据更新原子性：要么成功要么失败。
• 数据更新实时性：一定时间范围内，获取数据最新。
• ZNode：Zookeeper数据模型类似Unix文件系统，整体是棵树，每个分枝节点称为一个ZNode。一个ZNode最多存储1M数据。

使用场景

• 统一命名服务 ：在分布式环境下，对应用或服务进行统一命名。
• 统一配置管理 ：在分布式环境下，将数据写入一个ZNode，然后各个客户端监听这个ZNode，一旦这个ZNode数据被修改，zookeeper会通知每个客户端。
• 统一集群管理 ：在分布式环境下，某个节点将自身节点信息写入ZNode，其他节点或客户端可监听这个ZNode的实时状态变化来做出反应，以达到实时统一管理的效果。比如某节点宕机或者不知道死哪去了，Zookeeper将节点下线事件通知到注册监听的服务器，服务器收到通知做出反应。
• 负载均衡 ：为工作节点创建一个ZNode，其数据是访问该节点的请求数，找到访问请求数最少的工作节点来处理请求。

分布式安装

安装JDK

解压安装包在任一目录
下载

解压安装包并分发到其他节点

配置节点编号
假设当前解压目录下：/home/app/zookeeper-3.4.14
mkdir data
cd data
touch myid
vi myid

填入内容：2

其他节点编号依次递增

配置zoo.cfg
假设当前目录下：/home/app/zookeeper-3.4.14/conf
mv zoo_sample.cfg zoo.cfg
vi zoo.cfg

修改：
dataDir=/home/app/zookeeper-3.4.14/data

追加：
server.2=hadoop01:2888:3888
server.3=hadoop02:2888:3888
server.4=hadoop03:2888:3888

同步zoo.cfg到各个节点.

节点端口配置规则：server.A=B:C:D
A 集群节点编号，唯一标识一个zookeeper服务器。
B 集群节点ip地址
C Slave与Master通信端口
D 选举通信端口

ZNode类型

• 持久节点（Persistent）客户端与服务端断开连接后，创建的连接不删除。
• 临时（Ephemeral）客户端与服务端断开连接后，创建的连接自动删除。

这两种节点如果设置顺序标识，名称会附加一个顺序号，单调递增。这个顺序号由父节点维护，被用于对所有事件进行全局排序，根据顺序号可以得出事件的顺序。

实战操作

启动Zookeeper服务
./zkServer.sh start
停止Zookeeper服务
./zkServer.sh stop
查看Zookeeper状态
./zkServer.sh status

启动客户端控制台
./zkCli.sh
打开帮助文档
help
检索当前路径下节点
ls /
检索当前路径下节点，及当前节点信息
ls2 /
#创建节点。默认创建持久节点
create /anode “haha”
#获取节点数据
get /anode
#创建临时节点
create -e /anode/a “temp”
#创建带序号的持久节点
create -s /anode/aa “a data”
#设置节点数据
set /anode/aa0000000001 “no 1”
#监听/anode 这个节点的数据变化事件
get /anode watch
#监听/anode 这个节点的路径变化事件
ls /anode watch
#删除
delete /anode/a
#递归删除
rmr /anode
#节点状态
stat /anode

ZNode信息

• czxid-创建节点的事务zxid
  每次修改ZooKeeper状态都会收到一个zxid形式的时间戳，也就是ZooKeeper事务ID。
  事务ID是ZooKeeper中所有修改总的次序。每个修改都有唯一的zxid，如果zxid1小于zxid2，那么zxid1在zxid2之前发生。
• ctime - znode被创建的毫秒数(从1970年开始)
• mzxid - znode最后更新的事务zxid
• mtime - znode最后修改的毫秒数(从1970年开始)
• pZxid-znode最后更新的子节点zxid
• cversion - znode子节点变化号，znode子节点修改次数
• dataversion - znode数据变化号
• aclVersion - znode访问控制列表的变化号
• ephemeralOwner- 如果是临时节点，这个是znode拥有者的session id。如果不是临时节点则是0。
• dataLength- znode的数据长度
• numChildren - znode子节点数量

原理

选举机制

假设现在有5台服务器，每台服务器均是第一次启动，没有数据，它们的编号依次是1,2,3,4,5。
按编号依次启动，选择举过程如下：
1.服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking(选举状态)。
2.服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
3.服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
4.服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
5.服务器5启动，后面的逻辑同服务器4成为小弟。

监听原理

1.创建zookeeper客户端对象时，会创建两个线程，一个通信线程（connect），一个监听线程（listener）。
2.客户端对象创建好后，通过connect将注册监听事件发送给zookeeper。
3.zookeeper随后将注册监听事件加入到列表。
4.若被监听的数据或路径发生变化，则将这个变化消息发送给客户端的listener。
5.客户端的listener调用process()，处理辩护消息。