ZooKeeper 是 Apache 的一个顶级项目，为分布式应用提供高效、高可用的分布式协调服务，提供了诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知和分布式锁等分布式基础服务。由于 ZooKeeper 便捷的使用方式、卓越的性能（基于内存）和良好的稳定性，被广泛地应用于诸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系统中。
官方地址：https://zookeeper.apache.org
领导者（leader）：负责进行投票的发起和决议，更新系统状态。
跟随者（follower）：用于接收客户端请求并给客户端返回结果，在选主过程中进行投票。
观察者（observer）：可以接受客户端连接，将写请求转发给 leader，但是observer 不参加投票的过程，只是为了扩展系统，提高读取的速度。
ZooKeeper 节点的生命周期取决于节点的类型。在 ZooKeeper 中，节点根据持续时间可以分为持久节点（PERSISTENT）、临时节点（EPHEMERAL），根据是否有序可以分为顺序节点（SEQUENTIAL）、和无序节点（默认是无序的）。每个客户端连接zookeeper会产生一个session，客户端连接关闭时session也会消失。
持久节点一旦被创建，除非主动移除，不然一直会保存在 Zookeeper 中（不会因为创建该节点的客户端的会话失效而消失）。
层次化的目录结构，命名符合常规文件系统规范，类似于文件目录。
每个节点在 Zookeeper 中叫做 Znode，并且其有一个唯一的路径标识。
每个节点中数据存储不能超过1M（不要把Zookeeper当数据库用）。
顺序一致性。客户端的更新将按发送顺序应用。
原子性。要么成功要失败。没有中间状态（最终一致性）。
单个系统映像。由于zookeeper使用复制集群，无论客户端连接哪个节点都能看到相同的数据。
可靠性。即所有节点支持持久化。
及时性。存储在节点中的数据会在较短时间内及时同步。
任何分布式架构都不能同时满足C（一致性）、A（可用性）、P（分区容错性）。zookeeper集群在保证一致性的同时，在A和P之间做了取舍，最终选择了P，因此可用性差一点。
2 zookeeper集群搭建 2.1 网络拓扑
CentOS7 * 4
JDK8
Zookeeper3.6.3
在q101服务器中配置好后发送到其他服务器。q101操作如下：
wget https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/zookeeper-3.6.3/apache-zookeeper-3.6.3-bin.tar.gz --no-check-certificate
tar xf apache-zookeeper-3.6.3-bin.tar.gz
mv apache-zookeeper-3.6.3-bin /usr/local/zookeepe
cd /usr/local/zookeeper/conf
mv zoo_sample.cfg zoo.cfg
vi zoo.cfg
# 1. 修改dataDir路径为“/var/zookeeper”
# 2. 增加集群节点信息，信息如下
server.4=192.168.88.101:2888:3888
server.3=192.168.88.102:2888:3888
server.2=192.168.88.103:2888:3888
server.1=192.168.88.104:2888:3888
# 3. 保存退出
# 创建配置文件中设置的持久化目录
mkdir /var/zookeeper
# 将节点信息中的节点ID写如myid中
echo 4 > /var/zookeeper/myid
# 修改环境变量 增加zookeeper信息
# export ZOOKEEPER_HOME=/usr/local/zookeeper
# 在export PATH末尾追加 :$ZOOKEEPER_HOME/bin
vi /etc/profile
source /etc/profile
详细配置说明
# leader和follower心跳时间，用于维护节点是否存活。单位毫秒
tickTime=2000
# 初始延迟。当follower追随leader时，leader允许初始延迟时间。
# 用tickTime乘以initLimit，此处为2000*10即20秒
initLimit=10
# 数据同步时间，及超过时间数据同步失败。
# 用tickTime乘以syncLimit，此处为2000*5即10秒
syncLimit=5
# 持久化目录，不建议存在tmp下
dataDir=/var/zookeeper
# 客户端连接zookeeper端口号
clientPort=2181
# 允许客户端连接最大连接数
#maxClientCnxns=60
# dataDir中保留快照数量
#autopurge.snapRetainCount=3
# 清除任务时间间隔，单位小时。0表示禁用自动清楚功能
#autopurge.purgeInterval=1
# 自定义监控
#metricsProvider.className=org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider
#metricsProvider.httpPort=7000
#metricsProvider.exportJvmInfo=true
# 此处为自己添加的配置。集群信息,投票过半数量=（集群节点行数 除以 2）+1
# 数字1，2，3，4为节点ID，用于谦让出leader，投票过半后数字最大的为leader
# 端口说明：当leader挂掉后（或第一次启动没有leader时候）其他节点通过3888建立连接进行投票选出leader，
# 选中leader后，leader会通过2888端口来与follower进行工作
server.4=192.168.88.101:2888:3888
server.3=192.168.88.102:2888:3888
server.2=192.168.88.103:2888:3888
server.1=192.168.88.104:2888:3888
将q101相关文件传到q102并修改myid
scp -r /usr/local/zookeeper 192.168.88.102:/usr/local/
scp -r /var/zookeeper 192.168.88.102:/var/
scp /etc/profile 192.168.88.102:/etc
# 切换到q102服务器执行，数字与配置文件中的节点ID数据一致
echo 3 > /var/zookeeper/myid
# q102执行 使环境变量生效
source /etc/profile
将q101相关文件传到q103并修改myid
scp -r /usr/local/zookeeper 192.168.88.103:/usr/local/
scp -r /var/zookeeper 192.168.88.102:/var/
scp /etc/profile 192.168.88.103:/etc
# 切换到q103服务器执行
echo 2 > /var/zookeeper/myid
source /etc/profile
将q101相关文件传到q104并修改myid
scp -r /usr/local/zookeeper 192.168.88.103:/usr/local/
scp -r /var/zookeeper 192.168.88.102:/var/
scp /etc/profile 192.168.88.104:/etc
# 切换到q104服务器执行
echo 1 > /var/zookeeper/myid
source /etc/profile
为了测试我们采用前台启动，4台节点分别执行
zkServer.sh start-foreground
启动前3台的时候会发现报错，连接其他节点失败，属于正常情况，当启动最后一台的时候发现没有发错了。原因是启动前2台的时候没有leader。当第3台启动完成的时候，此时节点数量已经超过半数，所以开始根据zoo.cfg配置文件中的服务ID进行选举，因为q101服务器ID 设置的4，按节点谦让规则q101为leader。
启动错误信息如下：
节点角色验证
在q101执行
zkServer.sh status
启动关闭
后台启动：zkServer.sh start
前台启动：zkServer.sh start-foreground
停止：zkServer.sh stop
重启：zkServer.sh restart
查看版本：zkServer.sh version
查看状态：zkServer.sh status
连接与退出
连接zookeeper客户端：zkCli.sh -server 127.0.0.1:2181 连接本机可以直接输入zkCli.sh
退出zookeeper客户端：quit
操作命令
查看zookeeper所有命令：连接到zookeeper客户端后输入help
查看根目录下包含的节点：ls /
查看节点状态信息：ls2 / 或者使用 ls -s /
创建一个非顺序的持久化节点：create [-s] [-e] path data acl 比如 create /test test-1
创建一个临时节点：create -e /test/tmp tem-data
创建一个顺序节点：create -s /test/aaa aaa-data
删除一个节点：delete /test
[zk: localhost:2181(CONNECTED) 0] ls /
[zookeeper]
[zk: localhost:2181(CONNECTED) 1] create /abc
Created /abc
[zk: localhost:2181(CONNECTED) 3] ls /
[abc, zookeeper]
# 创建节点后默认数据为null
[zk: localhost:2181(CONNECTED) 9] get /abc
null
[zk: localhost:2181(CONNECTED) 4] create /abc/abcd
Created /abc/abcd
[zk: localhost:2181(CONNECTED) 15] set /abc/abcd hello
[zk: localhost:2181(CONNECTED) 16] get /abc/abcd
hello
Zookeeper每个znode都有一个与之关联的stat结构，类似于Unix/Linux文件系统中文件的stat结构。通过stat /xxx/xxx查看
[zk: localhost:2181(CONNECTED) 17] stat /abc/abcd
cZxid = 0x100000003
ctime = Wed Mar 02 23:41:34 CST 2022
mZxid = 0x100000006
mtime = Wed Mar 02 23:43:32 CST 2022
pZxid = 0x100000003
cversion = 0
dataVersion = 2
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 5
numChildren = 0
字段含义：
cZxid：创建节点znode时的事务ID由leader维护的递增计数器，共64位，其中前32为表示leader纪元，即leader革新换代次数，比如上面的0x1表示目前leader为做变更，如当前leader关闭后重新选举的leader此处会变成0x2，并且后32位的事务ID重新开始；后32为表示所有的增删改操作次数。
mZxid：修改节点znode更改的事务ID。
pZxid：添加或删除子节点znode更改的事务ID。
ctime：表示从1970-01-01T00:00:00Z开始以毫秒为单位的znode创建时间。
mtime：表示从1970-01-01T00:00:00Z开始以毫秒为单位的znode最近修改时间。
dataVersion：表示对该znode的数据所做的更改次数。
cversion：表示对此znode的子节点进行的更改次数。
aclVersion：版本号，即znode的ACL进行更改的次数。
ephemeralOwner：如果znode是ephemeral类型节点，则这是znode所有者的 session ID。 如果znode不是ephemeral节点，则该字段设置为零。
dataLength：这是znode数据字段的长度。
numChildren：这表示znode的子节点的数量。
临时节点伴随着session会话，当会话结束后临时节点销毁
- 通过q101连接zookeeper客户端查看日志
通过日志发现sessionID为：0x400000595cc0001
2. 创建临时节点 create -e /xxxx
create -e /aaa
- 通过stat查看发现刚创建的临时节点“bbbb”的ephemeralOwner正是连接时候的sessionID
当使用另一台服务器q102连接zkCli后查看aaa节点stat sessionID依旧是q101连接的sessionID。
通过create -s path data可以创建持久序列，znode被创建后，znode名称会自动添加一个编号，编号会自动递增。编号的递增和节点名称无关.
编号的递增不会因为断开而重置，也不会因为zookeeper重启而重置
它是一个基于消息传递的一致性算法，Leslie Lamport在1990年提出，近几年被广泛应用于分布式计算中，Google的Chubby，Apache的Zookeeper都是基于它的理论来实现的，Paxos还被认为是到目前为止唯一的分布式一致性算法，其它的算法都是Paxos的改进或简化。有个问题要提一下，Paxos有一个前提：Paxos只有在一个可信的计算环境中才能成立，这个环境是不会被入侵所破坏的。
关于Paxos的具体描述可以参考：https://baike.baidu.com/item/Paxos算法
4.2 ZAB协议ZAB(ZooKeeper Atomic broadcast)即ZooKeeper原子消息广播协议，类似于一个二阶段提交过程（2PC）属于最终一致性。是zookeeper基于Paxos算法的简化实现。
所有事务请求必须由一个全局唯一的服务器来协调处理,这样的服务器被称为 Leader服务器,而余下的其他服务器则成为 Follower服务器。 Leader服务器负责将一个客户端事务请求转换成一个事务 Proposal(提议),并将该 Proposal分发給集群中所有的Follower服务器。之后 Leader服务器需要等待所有 Follower服务器的反馈,一旦超过半数的 Follower服务器进行了正确的反馈后,那么 Leader就会再次向所有的 Follower服务器分发 Commit消息,要求其将前一个 Proposal进行提交。
上图说明：
1：Client向Follower发出写操作；
2：Follower将收到的写请求转发给Leader处理；
3：Leader收到请求后分配一个全局单调递增的唯一的事务ID(即ZXID，按其先后顺序来进行排序与处理)；
4.1：Leader服务器会为每一个 Follower服务器都各自分配一个单独的队列,然后将需要广播的事务Proposal依次放入这些队列中去,并且根据FIFO策略进行消息发送；每一个 Follower服务器在接收到这个事务 Proposal之后,都会首先将其以事务日志的形式写入到本地磁盘中去,并且在成功写入后反馈给 Leader服务器个Ack响应。Leader自己也会将事务日志写入磁盘；
4.2：当 Leader服务器接收到超过半数Follower的Ack响应后,就会广播一个Commit消息给所有的 Follower服务器以通知其进行事务提交（写入内存）,同时 Leader自身也会完成对事务的提交。
5：由Leader将结果返回给Client1
上图中4.1和4.2步骤，由于Leader自身也计一票，如果Follower2 由于网络等原因没有给Leader Ack响应，但Leader和Follower 1 两票已超过半数，所以结果依然会成功。此时Client2请求Follower2获取“/aaa”数据时，可以通过sync 让Follower 2向Leader同步后再返回数据。
4.3 选举机制 4.3.1 节点网络基于上面的第2章集群搭建，查看每台节点网络连接情况
yum install net-tools
netstat -natp | egrep '(2888|3888)'
查看结果如下：
# q101信息
[root@q101 ~]# netstat -natp | egrep '(2888|3888)'
tcp6 0 0 192.168.88.101:3888 :::* LISTEN 1924/java
tcp6 0 0 192.168.88.101:58052 192.168.88.102:3888 ESTABLISHED 1924/java
tcp6 0 0 192.168.88.101:39738 192.168.88.103:3888 ESTABLISHED 1924/java
tcp6 0 0 192.168.88.101:54174 192.168.88.102:2888 ESTABLISHED 1924/java
tcp6 0 0 192.168.88.101:47726 192.168.88.104:3888 ESTABLISHED 1924/java
# q102信息
[root@q102 ~]# netstat -natp | egrep '(2888|3888)'
tcp6 0 0 192.168.88.102:2888 :::* LISTEN 1661/java
tcp6 0 0 192.168.88.102:3888 :::* LISTEN 1661/java
tcp6 0 0 192.168.88.102:3888 192.168.88.101:58052 ESTABLISHED 1661/java
tcp6 0 0 192.168.88.102:2888 192.168.88.103:38244 ESTABLISHED 1661/java
tcp6 0 0 192.168.88.102:50104 192.168.88.104:3888 ESTABLISHED 1661/java
tcp6 0 0 192.168.88.102:2888 192.168.88.104:48034 ESTABLISHED 1661/java
tcp6 0 0 192.168.88.102:2888 192.168.88.101:54174 ESTABLISHED 1661/java
tcp6 0 0 192.168.88.102:37466 192.168.88.103:3888 ESTABLISHED 1661/java
# q103信息
[root@q103 ~]# netstat -natp | egrep '(2888|3888)'
tcp6 0 0 192.168.88.103:3888 :::* LISTEN 1415/java
tcp6 0 0 192.168.88.103:38244 192.168.88.102:2888 ESTABLISHED 1415/java
tcp6 0 0 192.168.88.103:3888 192.168.88.101:39738 ESTABLISHED 1415/java
tcp6 0 0 192.168.88.103:3888 192.168.88.102:37466 ESTABLISHED 1415/java
tcp6 0 0 192.168.88.103:58344 192.168.88.104:3888 ESTABLISHED 1415/java
# q104信息
[root@q104 ~]# netstat -natp | egrep '(2888|3888)'
tcp6 0 0 192.168.88.104:3888 :::* LISTEN 1333/java
tcp6 0 0 192.168.88.104:3888 192.168.88.101:47726 ESTABLISHED 1333/java
tcp6 0 0 192.168.88.104:3888 192.168.88.102:50104 ESTABLISHED 1333/java
tcp6 0 0 192.168.88.104:3888 192.168.88.103:58344 ESTABLISHED 1333/java
tcp6 0 0 192.168.88.104:48034 192.168.88.102:2888 ESTABLISHED 1333/java
通过上面的网络信息整体网络连接图如下
上图说明：
zookeeper Leader和Follower连接主要通过2888和3888，2888主要用于leader与follower进行工作，3888用于Leader选举。每个zookeeper节点都会与其他节点建立连接。
情况一：第一次启动
以上面我们搭好的4台节点为例，myid和zxid情况如下：
选举前提当投票数量超过半数时才有效，此处4台节点，当第一次启动时候zxid都为0。只要有3台节点启动就可以选举出Leader。虽然说q101的myid=4但是如果最后启动q101，那么第一次启动时一定是q102成为Leader。
情况二：zxid不为0时，当集群重启，或Leader挂了的时候
当Leader挂了后，zookeeper集群会进行推选制选举，会优先选举数据最全的节点作为Leader（通过比较zxid，zxid越大代表该节点数据最全），如果zxid相同再比较myid。
原Leader q102挂掉后无论哪个节点先发现Leader挂掉，都会推选zxid最大的节点，q103和q104 zxid 都为xxx10再比较myid。所以此处q103最终会被选为新的Leader。
5 watch6 zookeeper实现分布式锁 6.1 实现原理
- Watch是轻量级的，其实就是本地JVM的Callback，服务器端只是存了是否有设置了Watcher的布尔类型。
- 在服务端，在FinalRequestProcessor处理对应的Znode操作时，会根据客户端传递的watcher变量，添加到对应的ZKDatabase（org.apache.zookeeper.server.ZKDatabase）中进行持久化存储，同时将自己NIOServerCnxn做为一个Watcher callback，监听服务端事件变化
- Leader通过投票通过了某次Znode变化的请求后，然后通知对应的Follower，Follower根据自己内存中的zkDataBase信息，发送notification信息给zookeeper客户端。
- Zookeeper客户端接收到notification信息后，找到对应变化path的watcher列表，挨个进行触发回调。
多个节点同时在一个指定的节点下面创建临时会话顺序节点，谁创建的节点序号最小，谁就获得了锁，并且其他节点就会监听序号比自己小的节点，一旦序号比自己小的节点被删除了，其他节点就会得到相应的事件，然后查看自己是否为序号最小的节点，如果是，则获取锁。
