zookeeper学习

GoldXt

已于 2023-07-26 17:03:46 修改

阅读量315

点赞数 2

文章标签： zookeeper 学习 linux

于 2023-07-26 16:47:55 首次发布

本文链接：https://blog.csdn.net/GoldXt/article/details/131942880

版权

zookeeper介绍

zookeeper工作机制

zookeeper从设计模式角度来理解: 是一个基于观察者模式设计的分布式服务管理框架

zookeeper负责存储和管理大家都关心的数据, 然后接受观察者的注册, 一旦这些数据的状态发生变化, zookeeper就负责通知已经注册的观察者

特点

请添加图片描述

Zookeeper：一个领导者（Leader），多个跟随者（Follower）组成的集群。
集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。所以Zookeeper适合安装奇数台服务器。
全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
更新请求顺序执行，来自同一个Client的更新请求按其发送顺序依次执行。
数据更新原子性，一次数据更新要么成功，要么失败。
实时性，在一定时间范围内，Client能读到最新数据。

数据结构

ZooKeeper 数据模型的结构与 Unix 文件系统很类似，整体上可以看作是一棵树，每个节点称做一个 ZNode。每一个 ZNode 默认能够存储 1MB 的数据，每个 ZNode 都可以通过

其路径唯一标识。

请添加图片描述

应用场景

提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下

线、软负载均衡等。

看文档

zookeeper配置参数解读

配置地址
/opt/module/zookeeper-3.5.7/conf

//配置信息
# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial 
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between 
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just 
# example sakes.
dataDir=/opt/module/zookeeper-3.5.7/zkData
# the port at which the clients will connect
clientPort=2181
# the maximum number of client connections.
# increase this if you need to handle more clients
#maxClientCnxns=60
#
# Be sure to read the maintenance section of the 
# administrator guide before turning on autopurge.
#
#http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
#

#######################cluster##########################
server.2=hadoop102:2888:3888
server.3=hadoop103:2888:3888
server.4=hadoop104:2888:3888

tickTime = 2000：通信心跳时间，Zookeeper服务器与客户端心跳时间，单位毫秒
initLimit = 10：LF初始通信时限

Leader和Follower初始连接时能容忍的最多心跳数（tickTime的数量）
syncLimit = 5：LF同步通信时限

Leader和Follower之间通信时间如果超过syncLimit * tickTime，Leader认为Follwer死
dataDir：保存Zookeeper中的数据

注意：默认的tmp目录，容易被Linux系统定期删除，所以一般不用默认的tmp目录。
clientPort = 2181：客户端连接端口，通常不做修改。
server.A=B:C:D解读

A 是一个数字，表示这个是第几号服务器；集群模式下配置一个文件 myid，这个文件在 dataDir 目录下，这个文件里面有一个数据就是 A 的值，Zookeeper 启动时读取此文件，拿到里面的数据与 zoo.cfg 里面的配置信息比较从而判断到底是哪个 server。
B 是这个服务器的地址；
C 是这个服务器 Follower 与集群中的 Leader 服务器交换信息的端口；
D 是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口。

客户端向服务端写数据流程

直接发送给Leader节点

达到半数写入完成则可以返回给客户端,剩下的follower在继续写入

请添加图片描述

发送给follower节点

follower接收到请求先发给leader, leader先写入在发给folloer写入
达到半数写入完成则可以返回给客户端,剩下的follower在继续写入

请添加图片描述

zookeeper分布式锁实现原理

Zookeeper 分布式锁实现原理

写在开头:

来源:Zookeeper实战——分布式锁实现以及原理_zookeeper分布式锁实现_Kim_smile的博客-CSDN博客

先说结论：Zookeeper 是基于临时顺序节点以及 Watcher 监听器机制实现分布式锁的。

（1）ZooKeeper 的每一个节点都是一个天然的顺序发号器。

在每一个节点下面创建临时顺序节点（EPHEMERAL_SEQUENTIAL）类型，新的子节点后面会加上一个次序编号，而这个生成的次序编号是上一个生成的次序编号加一。

例如，有一个用于发号的节点 “/test/lock” 为父节点，可以在这个父节点下面创建相同前缀的临时顺序子节点，假定相同的前缀为“/test/lock/seq-”。第一个创建的子节点基本上应该为 /test/lock/seq-0000000001，下一个节点则为 /test/lock/seq-0000000002，依次类推。

在这里插入图片描述

（2）ZooKeeper 节点的递增有序性可以确保锁的公平。

一个 ZooKeeper 分布式锁，首先需要创建一个父节点，尽量是持久节点（PERSISTENT 类型），然后每个要获得锁的线程都在这个节点下创建一个临时顺序节点，该节点是按照创建的次序依次递增的。

为了确保公平，可以简单的规定：编号最小的那个节点表示获得了锁。所以，每个线程在尝试占用锁之前，首先判断自己是序号是不是当前最小，如果是则获取锁。

（3）ZooKeeper 的节点监听机制，可以保障占有锁的传递有序而且高效。

**每个线程抢占锁之前，先尝试创建自己的 ZNode。**同样，**释放锁的时候需要删除创建的 Znode。**创建成功后，如果不是序号最小的节点，就处于等待通知的状态。每一个等通知的 Znode 节点，**需要监视（watch）序号在自己前面的那个 Znode，以获取其删除事件。**只要上一个节点被删除了，就进行再一次判断，看看自己是不是序号最小的那个节点，如果是，自己就获得锁。就这样不断地通知后一个 ZNode 节点。

另外，ZooKeeper 的内部优越的机制，能保证由于网络异常或者其他原因，集群中占用锁的客户端失联时锁能够被有效释放。什么机制呢，就是临时顺序节点。一旦占用 Znode 锁的客户端与 ZooKeeper 集群服务器失去联系，这个临时 Znode 也将自动删除。排在它后面的那个节点，也能收到删除事件，从而获得锁。

也正是这个原因，zk 中不需要向 redis 那样考虑锁可能出现的无法释放的问题了，因为当客户端挂了，节点也挂了，锁也释放了。

（四）ZooKeeper 的节点监听机制，能避免羊群效应。

**ZooKeeper 这种首尾相接、后面监听前面的方式，可以避免羊群效应。**所谓羊群效应就是一个节点挂掉，所有节点都去监听，然后做出反应，这样会给服务器带来巨大压力。有了临时顺序节点以及节点监听机制，当一个节点挂掉，只有它后面的那一个节点才做出反应。

具体流程

一把分布式锁通常使用一个 Znode 节点表示；如果锁对应的 Znode 节点不存在，首先创建 Znode 节点。这里假设为 /test/lock，代表了一把需要创建的分布式锁。
抢占锁的所有客户端，使用锁的 Znode 节点的子节点列表来表示；如果某个客户端需要占用锁，则在 /test/lock 下创建一个临时顺序的子节点。比如，如果子节点的前缀为 /test/lock/seq-，则第一次抢锁对应的子节点为 /test/lock/seq-000000001，第二次抢锁对应的子节点为 /test/lock/seq-000000002，以此类推。
当客户端创建子节点后，需要进行判断：自己创建的子节点，是否为当前子节点列表中序号最小的子节点。如果是，则加锁成功；如果不是，则监听前一个 Znode 子节点变更消息，等待前一个节点释放锁。
一旦队列中的后面的节点，获得前一个子节点变更通知，则开始进行判断，判断自己是否为当前子节点列表中序号最小的子节点，如果是，则认为加锁成功；如果不是，则持续监听，一直到获得锁。
获取锁后，开始处理业务流程。完成业务流程后，删除自己的对应的子节点，完成释放锁的工作，以方面后继节点能捕获到节点变更通知，获得分布式锁。