zookeeper安装教程及其基本使用
目录
zookeeper下载：
zookeeper下载官网：
https://zookeeper.apache.org/
点击上述，下载3.5.7版本
本地安装配置：
下载到win机上，上传到linux上，再进行解压，修改配置文件（配置文件在conf目录下）
先修改zoo文件的名称：zoo_sample.cfg 修改为 zoo.cfg（sample是模板的意思）
进入zoo.cfg文件进行配置
需要修改dataDir的路径
在zookeeper的目录下自己创建一个目录作为zookeeper的数据与事务日志的存储目录
保存退出
启动zookeeper：
进入zookeeper的bin目录下可以找到下边两个脚本便是启动脚本文件（一个客户端，一个服务端，先启动服务端再启动客户端）
开启服务端：
bin/zkServer.sh start
启动客户端：
与服务端不一样，不需要start
进入后：
查看zookeeper的状态：
bin/zkServer.sh status
zoo.cfg文件解读：
tickTime=2000：
通信心跳时间，Zookeeper服务器与客户端心跳时间，单位毫秒
initLimit=10（首次连接时限）：
Leader和Follower初始连接时能容忍的最多心跳数（tickTime的数量）
syncLimit=5（非首次连接时限）：
Leader和Follower之间通信时间如果超过syncLimit * tickTime，Leader认为Follwer死掉，从服务器列表中删除Follwer。
clientPort=2181
客户端连接端口，通常不做修改。
dataDir=/opt/module/zookeeper-3.5.7/zkData
保存Zookeeper中的数据，一般默认temp,默认的目录容易被Linux定期删除
zookeeper的集群安装：
在上边我们已经安装好了本地模式，集群模式只需要我们修改一些配置进行分发到集群的其他服务器上即可。
（1）zkData 目录下创建一个 myid 的文件在文件中添加与 server 对应的编号（相当于唯一标识符）（注意：上下不要有空行，左右不要有空格）
（2）将配置好的文件进行分发
xsync zookeeper-3.5.7
（3）修改配置，分发到集群的其他服务器上后需要修改zkData 目录下的myid 的文件修改为自己的唯一标识符
(4) 修改zoo.cfg文件：
因为我们在本地模式的时候已经修改了部分配置文件，我们从本地模式转变成集群模式需要在zoo.fg文件下添加配置：
#######################cluster##########################
server.2=hadoop102:2888:3888
server.3=hadoop103:2888:3888
server.4=hadoop104:2888:3888
参数格式：
server.A=B:C:DA 是一个数字，表示这个是第几号服务器；
集群模式下配置一个文件 myid，这个文件在 dataDir 目录下，这个文件里面有一个数据 就是 A 的值，Zookeeper 启动时读取此文件，拿到里面的数据与 zoo.cfg 里面的配置信息比 较从而判断到底是哪个 server。
B 是这个服务器的地址；
C 是这个服务器 Follower 与集群中的 Leader 服务器交换信息的端口；
D 是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的
Leader，而这个端口就是用来执行选举时服务器相互通信的端口
再次分发文件
启动zookeeper（没有成功）
报错分析：
这里我一直启动不了，因为我以前运行过本地模式，当时怀疑是存储的日志问腿，就去zkdata文件夹下删除了version-2 文件夹重启还是不能启动zookeeper，有去看了配置文件zoo.cfg，后来发现是上边新加的配置信息后边结尾带空格了，删除之后重启，启动zookeeper成功
选举机制---第一次启动：
本机制是在5台服务器的前提下进行的
（1）服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING；
（2）服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的myid比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数为0票，服务器2票数为2票，没有半数以上结果，无法选举出leader，服务器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状态,进入follow状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；
（5）服务器5启动，同4一样当小弟。
总结：选举机制是一般都会先选举自己，发现不过半，则会转换自己的投票，转投myid比自己大的。当有服务器选票过半数后，则会选举出leader。后边的服务器就会进行比票，但是已经确定的leader与follow不会再进行改选。
部分概念：
SID：服务器ID。用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid一致。
ZXID：（客户端每次执行写操作都有事务id）事务ID。ZXID是一个事务ID，用来标识一次服务器状态的变更。在某一时刻， 集群中的每台机器的ZXID值不一定完全一 致，这和ZooKeeper服务器对于客户端“更 新请求”的处理逻辑有关。
Epoch：每个Leader任期的代号。没有
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选举。 SID为1、2、4的机器投票情况（分别为EPOCH，ZXID，SID ）： （1，8，1） （1，8，2） （1，7，4）
选举Leader规则： ①EPOCH大的直接胜出 ②EPOCH相同，（ZXID）事务id大的胜出
③（ZXID）事务id相同，(SID)服务器id大的胜出
ZK集群的启动与停止脚本：
注：start/stop/status不要换行，会让脚本失效，显示找不到
#!/bin/bash
case $1 in
"start"){
for i in hadoop102 hadoop103 hadoop104
do
echo ---------- zookeeper $i 启动 ------------
ssh $i "/opt/module/zookeeper-3.5.7/bin/zkServer.sh start"
done
};;
"stop"){
for i in hadoop102 hadoop103 hadoop104
do
echo ---------- zookeeper $i 停止 ------------
ssh $i "/opt/module/zookeeper-3.5.7/bin/zkServer.sh stop"
done
};;
"status"){
for i in hadoop102 hadoop103 hadoop104
do
echo ---------- zookeeper $i 状态 ------------
ssh $i "/opt/module/zookeeper-3.5.7/bin/zkServer.sh status"
done
};;
esac客户端命令行操作：
启动特定服务器的客户端：
bin/zkCli.sh -server hadoop102:2181
查看节点信息：
ls -s /
参数分析：
（1）czxid：创建节点的事务 zxid
每次修改 ZooKeeper 状态都会产生一个 ZooKeeper 事务 ID。事务 ID 是 ZooKeeper 中所 有修改总的次序。每次修改都有唯一的 zxid，如果 zxid1 小于 zxid2，那么 zxid1 在 zxid2 之 前发生。
（2）ctime：znode 被创建的毫秒数（从 1970 年开始）
（3）mzxid：znode 最后更新的事务 zxid
（4）mtime：znode 最后修改的毫秒数（从 1970 年开始）
（5）pZxid：znode 最后更新的子节点 zxid
（6）cversion：znode 子节点变化号，znode 子节点修改次数
（7）dataversion：znode 数据变化号
（8）aclVersion：znode 访问控制列表的变化号
（9）ephemeralOwner：如果是临时节点，这个是 znode 拥有者的 session id。如果不是 临时节点则是 0。
（10）dataLength：znode 的数据长度
（11）numChildren：znode 子节点数量
节点类型（持久/短暂/有序号/无序号）：
持久（Persistent）：客户端和服务器端断开连接后，创建的节点不删除
短暂（Ephemeral）：客户端和服务器端断开连接后，创建的节点自己删除
持久化顺序编号目录节点：
客户端与Zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
3）临时目录节点
客户端与Zookeeper断开连接后，该节点被删除
4）临时顺序编号目录节点
客户端与Zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号
（被删除后，会从该节点进行递增编号）
示例：
create /sanguo "diaochan" 在你创建节点的时候必须代值
create /sanguo/shuguo "liubei" 不要依/结尾
ls /sanguo上述代码“ls”只能查看当前节点是否有子节点，不能查看节点的值
get -s /sanguo上述命令可以查看节点的值
上述创建的为不带序号的永久节点
创建带序号的永久节点：
create -s /sanguo/weiguo/zhangliao "zhangliao"
可以看到节点zhangliao是带节点的
带序号的情况下，我再次执行上边语句：
会显示创建了002号节点 ，但是如果我们创建的是不带序号的已经存在的永久节点，那么就会报错节点已经存在
创建临时节点：
创建临时节点是加上 -e
create -e /sanguo/wuguo "sunquan"
这个语句是创建的不带序号的临时节点
下边我们再次创建带序号的临时节点：
创建的还是吴国
create -e -s /sanguo/wuguo "zhouyu"
断开客户端，查看临时节点是否还存在：
修改节点的值：
监听器原理：
监听器主要是监听 监听节点数据的变化 （get path [watch]）与 监听子节点增减的变化（ls path [watch]）
监听原理详解：
1）首先要有一个main()线程
2）在main线程中创建Zookeeper客户端，这时就会创建两个线
程，一个负责网络连接通信（connet），一个负责监听（listener）。
3）通过connect线程将注册的监听事件发送给Zookeeper。
4）在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中。
5）Zookeeper监听到有数据或路径变化，就会将这个消息发送给listener线程。
6）listener线程内部调用了process()方法。
节点的值变化监听：
在开启103，104两台服务器的本地客户端
在hadoop104主机上注册监听/sanguo节点数据变化：
get -w /sanguo 在hadoop103主机上修改/sanguo节点的数据：
set /sanguo "xisi" 观察hadoop104主机收到数据变化的监听：
但是，申请监听只能监听到一次它的修改,在hadoop103再多次修改/sanguo的值，hadoop104上不会再收到监听。因为注册一次，只能监听一次。想再次监听，需要再次注册。
节点的子节点变化监听（路径变化）:
在hadoop104主机上注册监听/sanguo节点的子节点变化
ls -w /sanguo 在hadoop103主机/sanguo节点上创建子节点
create /sanguo/jin "simayi"观察hadoop104主机收到子节点变化的监听:
注意：节点的路径变化，也是注册一次，生效一次。想多次生效，就需要多次注册。
节点删除与查看:
删除单个节点：
delete /sanguo/jin 递归删除节点：
deleteall /sanguo/shuguo 查看节点状态：
stat /sanguo