Zookeeper的学习(含Redis分布式和一致性相关）

最新推荐文章于 2024-05-04 05:39:04 发布

七天晒网

最新推荐文章于 2024-05-04 05:39:04 发布

阅读量169

点赞数

分类专栏： Java 文章标签： 1024程序员节

本文链接：https://blog.csdn.net/CSL201816080304/article/details/109260907

版权

Zookeeper 分布式锁集群管理原子广播 Zab协议

关键词由CSDN通过智能技术生成

Java 专栏收录该内容

59 篇文章 0 订阅

订阅专栏

参考：Zookeeper入门
 rpc使用zk的例子1
rpc使用zk的例子2
添加链接描述

添加链接描述
 添加链接描述
 添加链接描述
 添加链接描述
 添加链接描述
 添加链接描述

三种实现分布式锁的方式–请点击

Zookeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。
Zookeeper 功能较多，能够配置维护、域名服务、分布式同步、组服务等，也有很多服务框架使用 Zookeeper 来做注册中心。

1.命名服务   2.配置管理   3.集群管理   4.分布式锁  5.队列管理

zookeeper注册中心（zookeeper的通知机制）

Zookeeper 用来做服务注册中心，主要是因为它具有节点变更通知功能，只要客户端监听相关服务节点，服务节点的所有变更，都能及时的通知到监听客户端，这样作为调用方只要使用 Zookeeper 的客户端就能实现服务节点的订阅和变更通知功能了，非常方便。
另外，Zookeeper 可用性还算是可以的，因为只要半数以上的选举节点存活，整个集群就是可用的。

zookeeper注册中心的实现机制

在zookeeper中进行服务注册就是在zookeeper创建了一个节点，结点存储该服务的IP端口号，调用方式（协议，序列化）等，由服务提供者去创建，以供消费者去获取信息，服务端启动服务时，会将服务名称，IP地址等信息注册到注册中心，服务消费者在第一次调用服务时，会通过注册中心找到相应的服务的IP地址列表，并缓存到本地，以供后续使用。
当消费者调用服务时，不会再去请求注册中心，而是直接通过负载均衡算法从IP列表中取一个服务提供者的服务器调用服务。当服务提供者的某台服务器宕机或下线时，相应的ip会从服务提供者IP列表中移除。同时，注册中心会将新的服务IP地址列表发送给服务消费者机器，缓存在消费者本机。

zookeeper提供心跳检测，会盯上想服务端发送一个请求（实际上建立的是一个 socket 长连接），如果长期没有响应，服务中心就认为该服务提供者已经“挂了”，并将其剔除）
服务消费者会去监听相应路径（/HelloWorldService/1.0.0），一旦路径上的数据有任务变化（增加或减少），zookeeper都会通知服务消费方服务提供者地址列表已经发生改变，从而进行更新。
zookeeper 与生俱来的容错容灾能力（比如leader选举），可以确保服务注册表的高可用性。

使用 zookeeper 作为注册中心时，客户端订阅服务时会向 zookeeper
注册自身；主要是方便对调用方进行统计、管理。但订阅时是否注册 client 不是必要行为，和不同的注册中心实现有关，例如使用 consul
时便没有注册。

Zookeeper工作原理 (zookeeper的核心：原子广播

Zookeeper的底层选举原理？如何保持zookeeper数据一致性？Zab原子广播协议

Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。
Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。
当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。
状态同步保证了leader和Server具有相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。
所有的提议（proposal）都在被提出的时候加上了zxid。
实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

在这里插入图片描述

zxid什么情况下会不一致？

在同步的时候一台突然宕机了

zab原子广播协议有两种模式

1、恢复模式：初次启动节点时，选举leader，从节点进入恢复模式同步主节点数据
2、广播模式：解决每个节点的数据同步问题

恢复模式

当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server完成了和leader的状态同步以后，恢复模式就结束了。
状态同步保证了leader和server具有相同的系统状态。

广播模式

一旦Leader已经和多数的Follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。
这时候当一个Server加入ZooKeeper服务中，它会在恢复模式下启动，发现Leader，并和Leader进行状态同步。待到同步结束，它也参与消息广播。
ZooKeeper服务一直维持在Broadcast状态，直到Leader崩溃了或者Leader失去了大部分的Followers支持。

Broadcast模式极其类似于分布式事务中的2pc（two-phrase commit 两阶段提交）：即Leader提起一个决议，由Followers进行投票，Leader对投票结果进行计算决定是否通过该决议，如果通过执行该决议（事务），否则什么也不做。
在这里插入图片描述

对于客户端发送的写请求，全部由 Leader 接收，Leader 将请求封装成一个事务 Proposal，将其发送给所有 Follwer ，然后，根据所有 Follwer 的反馈，如果超过半数成功响应，则执行 commit 操作（先提交自己，再发送 commit 给所有 Follwer）。

当超过半数成功回应，则执行 commit ，同时提交自己。同时每个事物都有一个zxid 还有一个消息队列解决异步，同时，针对各个节点的数据不一致性问题还有选举过程。

zookeeper分布式锁（与Redis分布式锁）

在这里插入图片描述

zookeeper分布式锁

在这里插入图片描述

Zk实现分布式锁思想：节点保持唯一、事件通知、临时节点（生命周期和session会话关联）
因为Zookeeper节点路径保持唯一，不允许重复且有临时节点特性，连接关闭后当前节点会自动消失，从而实现分布式锁。
在这里插入图片描述

zk实现分布式锁的落地方案：

使用zk的临时节点和有序节点，每个线程获取锁就是在zk创建一个临时有序的节点，比如在/lock/目录下。
创建节点成功后，获取/lock目录下的所有临时节点，再判断当前线程创建的节点是否是所有的节点的序号最小的节点
如果当前线程创建的节点是所有节点序号最小的节点，则认为获取锁成功。
如果当前线程创建的节点不是所有节点序号最小的节点，则对节点序号的前一个节点添加一个事件监听。
- 比如当前线程获取到的节点序号为/lock/003,然后所有的节点列表为[/lock/001,/lock/002,/lock/003],则对/lock/002这个节点添加一个事件监听器。
- 如果锁释放了，会唤醒下一个序号的节点，然后重新执行第3步，判断是否自己的节点序号是最小。
  -