文章目录 一、Zookeeper概述1.1 概述1.2 工作机制1.3 特点1.4 数据结构1.5 应用场景1.5.1 统一命名服务1.5.2 统一配置管理1.5.3 统一集群管理1.5.4 服务器动态上下线1.5.5 软负载均衡 二、Zookeeper安装2.1 单机模式安装2.2 集群环境搭建 三、Zookeeper集群选举机制3.1 第一次启动3.2 非第一次启动 一、Zookeeper概述 1.1 概述
Zookeeper是Apache的一个开源的分布式项目，能作为微服务的注册中心
官网：https://zookeeper.apache.org/
1.2 工作机制Zookeeper从设计模式角度 来理解：
是一个基于观察者模式设计的分布式服务管理框架 ，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就 将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。
即：Zookeeper = 文件系统 + 通知机制
1.3 特点 Zookeeper集群有一个领导者（leader）和多个跟随着（follower）集群中有**半数以上**节点存活，集群就能正常服务。所以zookeeper适合安装奇数台服务器全局一致性 ：每个Server保存一份相同的数据副本，Client无论连接到哪个Server数据都是一致的更新请求顺序执行 ：来自同一个Client的更新请求按其发送顺序依次执行数据更新原子性 ：一次数据更新要么成功，要么失败实时性 ：在一定时间范围内，Client能读到最新数据 1.4 数据结构Zookeeper数据模型的结构与Unix文件系统类似 ，整体上可以看作一棵树，每个节点称作一个ZNode。
每一个 ZNode默认能够存储 1MB的数据，每个 ZNode都可以通过其路径唯一标识。
1.5 应用场景提供的服务包括：
统一命名服务统一配置管理统一集群管理服务器节点动态上下线软负载均衡等 1.5.1 统一命名服务在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。
例如：IP不容易记住，而域名容易记住。
1.5.2 统一配置管理分布式环境下，配置文件同步问题非常常见。 一般要求一个集群中，所有节点的配置信息是一致的，比如 Kafka 集群。所以希望对配置文件修改后，希望能够快速同步到各个节点上。
这时候可以把配置管理交给Zookeeper来实现，可以将配置信息写入ZooKeeper上的一个Znode。各个客户端服务器监听这个Znode。一 旦Znode中的数据被修改，ZooKeeper将通知各个客户端服务器
1.5.3 统一集群管理分布式环境中，实时掌握每个节点的状态是必要的。 可根据节点实时状态做出一些调整
ZooKeeper可以实现实时监控节点状态变化，可将节点信息写入ZooKeeper上的一个ZNode，监听这个ZNode可获取它的实时状态变化
1.5.4 服务器动态上下线客户端能实时洞察到服务器上下线的变化
1.5.5 软负载均衡在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求
二、Zookeeper安装下载页面：http://archive.apache.org/dist/zookeeper/
下载3.5.7版本，上传到Linux服务器
2.1 单机模式安装①安装前准备：
安装JDK
解压到指定目录
tar -zxvf apache-zookeeper-3.5.7-bin.tar.gz在zookeeper文件夹里建一个目录存放dataDir
②配置修改：
找到zookeeper/conf 路径下的zoo_sample.cfg，复制一份改名为zoo.cfg，并vim打开，修改里面的内容
dataDir： 修改为开始建的文件夹
**clientPort： ** 默认2181
admin.serverPort： zookeeper自带的管理客户端，如果不设置默认为8080，可能冲突
quorumListenOnAllIps： 是否可以被本机外的IP访问
tickTime = 2000： 通信心跳时间，Zookeeper服务器与客户端心跳时间，单位毫秒
initLimit = 10： LF初始通信时限
syncLimit = 5： LF同步通信时限
③操作ZK
启动Zookeeper，进入bin目录
./zkServer.sh start查看进程是否启动
[root@Bandit bin]# jps 210816 Jps 210777 QuorumPeerMain查看zk的状态
[root@Bandit bin]# ./zkServer.sh status /usr/bin/java ZooKeeper JMX enabled by default Using config: /myZk/zookeeper/bin/../conf/zoo.cfg Client port found: 2181. Client address: localhost. Mode: standalone #standalone 单机，没用集群启动客户端
./zkCli.sh退出客户端
quit停止zk服务
./zkServer.sh stop 2.2 集群环境搭建1）先把之前的zookeeper复制两份，搭建三台集群的集群
2）在之前的zkData目录下新增myid文件，添加对应server编号
其他两个的对应文件夹下也创建myid，分别为2，3
3）修改zoo.cfg文件，在zoo.cfg里追加如下语句
######################cluster#################### server.1=192.168.2.128:2888:3888 server.2=192.168.2.128:2889:3889 server.3=192.168.2.128:2887:3887配置文件解读：
server.A=B:C:DA 是数字，表示这是几号服务器，和myid文件相关，编号值就是myid文件内容。Zookeeper 启动时读取此文件，拿到里面的数据与 zoo.cfg 里面的配置信息比较从而判断到底是哪个 server
B 是这个服务器的地址
C 是这个服务器 Follower 与集群中的 Leader 服务器交换信息的端口
D 是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口
4）分别启动Zookeeper
在每个bin目录下
./zkServer.sh start然后查看状态：
./zkServer.sh status可以看到一主两从
三、Zookeeper集群选举机制每台服务器都有三个标志：
SID： ==服务器ID。==用来唯一标识一台 ZooKeeper集群中的机器，每台机器不能重复，和myid一致。
ZXID： 事务ID。ZXID是一个事务ID，用来标识一次服务器状态的变更。 在某一时刻， 集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关。
Epoch： ==每个Leader任期的代号。==没有 Leader时同一轮投票过程中的逻辑时钟值是 相同的。每投完一次票这个数据就会增加
3.1 第一次启动 服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为 LOOKING服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的myid比自己目前投票推举的（服务器1） 大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING服务器5启动，同4一样当小弟。 3.2 非第一次启动当ZooKeeper集群中的一台服务器出现以下两种情况之一 时，就会开始进入Leader选举
服务器初始化启动服务器运行期间无法和Leader保持连接(非第一次启动)服务器运行期间无法和Leader保持连接会首先默认集群中没有Leader 进行选举
而当一台机器进入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选举。
 1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，会注明原创字样,如未注明都非原创，如有侵权请联系删除！；3.作者投稿可能会经我们编辑修改或补充；4.本站不提供任何储存功能只提供收集或者投稿人的网盘链接。 |
