zookeeper 的核心知识点

一 zookeeper

Zookeeper 是一个开源的分布式协调服务框架，主要用来解决分布式集群中应用系统的 一致性问题和数据管理问题。

简而言之：zk是一个分布式的应用协调、数据同步的框架，保证数据的一致性。

 

二  zk的应用协调/通知

Zookeeper中特有的Watcher注册与异步通知机制，能够很好地实现分布式环境下不同机器，甚至不同系统之间的协调与通知，从而实现对数据变更的实时处理。

在绝大多数分布式系统中，系统机器间的通信无外乎 心跳检测、工作进度汇报和系统调 度 。

三   分布式锁

分布式锁用于控制 分布式系统之间同步访问共享资源的一种方式 ，可以保证不同系统访问一个或一组资源时的一致性，主要分为排它锁和共享锁。

排它锁又称为写锁或独占锁 ，若事务 T1 对数据对象 O1 加上了排它锁，那么在整个加锁期

间，只允许事务 T1 对 O1 进行读取和更新操作，其他任何事务都不能再对这个数据对象进行任

何类型的操作，直到 T1 释放了排它锁

① 获取锁 ，在需要获取排它锁时，所有客户端通过调用接口，在 /exclusive_lock 节点下创建

临时子节点 /exclusive_lock/lock 。 Zookeeper 可以保证只有一个客户端能够创建成功，没有成

功的客户端需要注册 /exclusive_lock 节点监听。

② 释放锁 ，当获取锁的客户端宕机或者正常完成业务逻辑都会导致临时节点的删除，此

时，所有在 /exclusive_lock 节点上注册监听的客户端都会收到通知，可以重新发起分布式锁获

取。

共享锁又称为读锁 ，若事务 T1 对数据对象 O1 加上共享锁，那么当前事务只能对 O1 进行读取操

作，其他事务也只能对这个数据对象加共享锁，直到该数据对象上的所有共享锁都被释放。

在需要获取共享锁时，所有客户端都会到 /shared_lock 下面创建一个临时顺序节点 。

四   zk的架构

Zookeeper 集群是一个基于主从架构的高可用集群

角色	描述
Leader	负责调度：它会发起并维护与各 Follwer及Observer间的心跳。 处理事务性写操作请求：所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。 参与投票，并负责投票选举。
学习者（learner）-跟随者（follower）	接收客户端的请求，并向客户端返回结果。 Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理，并且负责在Leader处理写请求时对请求进行投票。 3.参与集群投票
学习者（learner）-观察者（observer）	1.接收客户端的请求，并向客户端返回结果。 2.Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理，并且负责在Leader处理写请求时对请求进行投票。 3.不参与集群投票
客户端	请求发起方

五  zk的leader选举

Leader 选举是保证分布式 数据一致性 的关键所在。

1.服务器启动时期的 Leader 选举：

(1) 每个 Server 发出一个投票 。由于是初始情况， Server1 和 Server2 都会将自己作为

Leader 服务器来进行投票，每次投票会包含所推举的服务器的 myid 和 ZXID ，使用 (myid, ZXID)

来表示，此时 Server1 的投票为 (1, 0) ， Server2 的投票为 (2, 0) ，然后各自将这个投票发给集群中

其他机器。

(2) 接受来自各个服务器的投票 。集群的每个服务器收到投票后，首先判断该投票的有

效性，如检查是否是本轮投票、是否来自 LOOKING 状态的服务器。

(3) 处理投票 。针对每一个投票，服务器都需要将别人的投票和自己的投票进行 PK ， PK

规则如下

· 优先检查 ZXID 。 ZXID 比较大的服务器优先作为 Leader 。

· 如果 ZXID 相同，那么就比较 myid 。 myid 较大的服务器作为 Leader 服务器。

对于 Server1 而言，它的投票是 (1, 0) ，接收 Server2 的投票为 (2, 0) ，首先会比较两者的

ZXID ，均为 0 ，再比较 myid ，此时 Server2 的 myid 最大，于是更新自己的投票为 (2, 0) ，

对于Server2 而言，他的投票是（2，0），接收server1的投票为（1，0），首先会比较两者的zxid均为0，再比较myid，此是自己的myid最大，更新后的投票还是自己的投票（2，0）

(4) 统计投票 。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到

相同的投票信息，对于 Server1 、 Server2 而言，都统计出集群中已经有两台机器接受了 (2, 0) 的

投票信息，此时便认为已经选出了 Leader 。server2为leader。

(5) 改变服务器状态 。一旦确定了 Leader ，每个服务器就会更新自己的状态，如果是

Follower ，那么就变更为 FOLLOWING ，如果是 Leader ，就变更为 LEADING 。

（6）此时server3也刚好启动好，也最能做小弟的角色。因为server2已经为leader了。

2. 服务器运行时期的 Leader 选举

选举过程跟情况1相似。

按照上述初始化的情况，server3成为了leader，在运行期间处于leader的server3挂了，那么非Observer服务器server1、server2、server4、server5会将自己的节点状态变为LOOKING状态

1、开始进行leader选举。现在选举同样是根据myid和zxid来进行

2、首先每个server都会给自己投一票竞选leader。假设server1的zxid为123，server2的zxid为124，server4的zxid为169，server5的zxid为188

3、同样先是比较zxid再比较myid，当server1、server2、server4进行比较时，server4根据优先条件选举为leader。然后server5还是跟随server4，即使server5的zxid最大，但是当选举到server4的时候，机器数已经过半。不再进行选举，跟随已经选举的leader

原文链接：https://blog.csdn.net/ypp91zr/article/details/89409707

六 zk的Java api （了解）

Zookeeper的JavaAPI使用的是一套zookeeper客户端框架 Curator ，解决了很多Zookeeper客户端非常底层的细节开发工作 。

Curator包含了几个包：

• curator-framework：对zookeeper的底层api的一些封装

• curator-recipes：封装了一些高级特性，如：Cache事件监听、选举、分布式锁、分布式计数器等

七 zk的启动和查看

1.注意：Zk的启动需要到相应的一个个节点中手动启动。

#进入根目录下执行：sh bin/zkServer.sh start     配置环境变量后： zkServer.sh start

查看状态：sh bin/zkServer.sh status     配置环境变量后： zkServer.sh status

如果想要关闭： sh bin/zkServer.sh stop  配置环境变量后： zkServer.sh stop

因为配置了环境变量，所以任意目录下均可执行：

2.为了防止不必要的麻烦，关闭掉所有的防火墙： systemctl stop firewalld

确切的说所有节点一定要关闭防火墙，否则，启动不起来！！！

关闭：     systemctl stop firewalld 查看状态： systemctl status firewalld  开机禁用  ： systemctl disable firewalld 开机启用  ： systemctl enable firewalld

案例如下：