ZooKeeper 典型应用:命名服务&分布式锁|学习笔记

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 快速学习 ZooKeeper 典型应用:命名服务&分布式锁

开发者学堂课程【大数据 ZooKeeper 快速入门 ZooKeeper 典型应用:命名服务&分布式锁】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/549/detail/7575


ZooKeeper 典型应用:命名服务&分布式锁


内容介绍

一、命名服务(Naming Service)

二、分布式锁

三、控制时序

 

一、命名服务(Naming Service)

在分布式系统中,通过使用命名服务,客户端应用能够根据指定名字来获取资源或服务的地址,提供者等信息。

被命名的实体通常可以是集群中的机器,提供的服务地址,远程对象等等,这些都可以统称为名字(Name)。

其中较为常见的就是一些分布式服务框架中的服务地址列表。

通过调用ZK提供的创建节点的 API,能够很容易创建一个全局唯一的 path,这个path 就可以作为一个名称。

阿里巴巴集团开源的分布式服务框架 Dubbo 中使用 ZooKeeper 来作为其命名服务,维护全局的服务地址列表。

一个服务的提供者发布服务的时候,Dubbo 会把相应的地址注册到 ZooKeeper 中,因为在 ZooKeeper 中路径是全局唯一的。

比如不可能创建一摸一样的节点在两个路径下或者在同一路径下节点不可能重复。

因为全局路径的唯一性,所以导致路径和发布的服务形成一对一的映射,这样通过路径就可以找到发布的服务,就完成了服务的注册,服务使用者通过API就可以获取到路径,从而获取到对应的服务地址,这样就完成了命名服务。

 

二、分布式锁

锁主要体现在比如多个线程,人们同时在获取一个数据,这时如果没有锁的控制,势必会造成紊乱现象。

在分布式状态下也会造成这种情况,比如在分布式应用,人们都想要操作一块数据,如果两个人同时进行,这时候问题就出现了。

分布式锁,这个主要得益于 ZooKeeper 保证了数据的强一致性。

锁服务可以分为两类一个是保持独占,另一个是控制时序。

所谓保持独占,就是所有试图来获取这个锁的客户端,最终只有一个可以成功获得这把锁。

通常的做法是把 zk 上的一个 znode 看作是一把锁,通过

createznode 的方式来实现。所有客户端都去创建 /distribute_lock 节点,最终成功创建的那个客户端也即拥有了这把锁。

比如在集群中有很多的应用,这些应用要同时去操纵一些数据,如果没有所谓的锁控制,都去操作这个文件,势必造成文件紊乱性,如下:

比如应用a对数据做删除操作,应用c修改,应用 b 获取,数据就会出现章数据的发生。

这时用 ZooKeeper 就可以完成分布式锁的功能,在获取之前要求所有应用先去 zk 上指定目录创建节点/aaa

都去创建节点,但只能有一个创建成功,比如应用 b 因为网络关系,连接比较快,连上后先创建了一个 a,这时候其他应用再去创建结点的时候,因为现在节点已经存在,所以就会报错。节点要求:要求是临时节点并且是非序列化。

比如这时,b 应用连接到zk集群创建了节点,这时在路径下就有了一个/aaa 节点,这时其他应用创建节点就会失败,相当于谁创建成功,谁就获得访问数据文件的权限,如下:

image.png

因为应用b获得了目录创建的权限,因此应用b就有权限去获得数据文件的相关操作,操作完成后需要将锁释放,所以操作完成后断开跟 zk 的链接。

一旦断开连接,临时节点就会被删除,其他应用如果需要操作这个文件的话,就去监听这个目录是否存在。

因为可以设置监听目录是否存在,就会造成比如应用a发现节点已经存在了,那么就设置一个监听,当节点删除的时候应用 a 可以获取到监听,之后再去创建。

这样就完成了保持在同一时刻只有一个应用可以获取到目录的创建能力,哪个应用创建成功,就拥有了一把锁,这是一个抽象地表示。

 

三、控制时序

控制时序,就是所有试图来获取这个锁的客户端,最终都是会被安排执行,只是有个全局时序了。做法和上面基本类似,只是这里 /distribute_lock 已经预先存在,客户端在它下面创建临时有序节点(这个可以通过节点的属性控

制:CreateMode.EPHEMERAL_SEQUENTIAL来指定)。

Zk的父节点(/distribute_lock)维持一份sequence,保证子节点创建的时序性,从而也形成了每个客户端的全局时序。

比如从大到小、从小到大,还是在路径下创建节点,开启序列化特性就会出现应用 a 创建第一个编号为00000,下一个应用 c 创建编号为00001,再下一个应用b是00002,要想控制时序就可以根据编号进行排版。

比如谁的编号最小谁优先访问,那么应用 a 先访问,接着是应用c、应用b,通过序列化特性就完成了时序性,在时间上有先后的顺序。

创建节点如果想满足于使用完成后就消除的话,那么就要把节点创建成序列化短站,比如应用 a 访问之后断开连接,那么节点就消除,如果应用 a 想再次访问,再次创建节点,这时就变为了00003,就排在这些节点的后面。

通过这两种方式可以在 ZooKeeper 中实现分布式锁的应用,前提是要把 ZooKeeper 核心,节点类型以及机制搞清楚。

相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
相关文章
|
12天前
|
监控 负载均衡 Cloud Native
ZooKeeper分布式协调服务详解:面试经验与必备知识点解析
【4月更文挑战第9天】本文深入剖析ZooKeeper分布式协调服务原理,涵盖核心概念如Server、Client、ZNode、ACL、Watcher,以及ZAB协议在一致性、会话管理、Leader选举中的作用。讨论ZooKeeper数据模型、操作、会话管理、集群部署与管理、性能调优和监控。同时,文章探讨了ZooKeeper在分布式锁、队列、服务注册与发现等场景的应用,并在面试方面分析了与其它服务的区别、实战挑战及解决方案。附带Java客户端实现分布式锁的代码示例,助力提升面试表现。
30 2
|
1月前
|
人工智能 Serverless 测试技术
nacos常见问题之Serverless 应用引擎2.0不支持 MSE nacos如何解决
Nacos是阿里云开源的服务发现和配置管理平台,用于构建动态微服务应用架构;本汇总针对Nacos在实际应用中用户常遇到的问题进行了归纳和解答,旨在帮助开发者和运维人员高效解决使用Nacos时的各类疑难杂症。
23 0
|
1月前
|
SpringCloudAlibaba Java 网络架构
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(二)Rest微服务工程搭建
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(二)Rest微服务工程搭建
52 0
|
1月前
|
消息中间件 分布式计算 负载均衡
ZooKeeper应用案例
【2月更文挑战第24天】
|
1月前
|
安全 大数据 Go
Go语言在分布式系统中的应用
【2月更文挑战第20天】Go语言,以其独特的语言特性和出色的性能,逐渐成为分布式系统开发领域的热门选择。本文将深入探讨Go语言在分布式系统中的应用,分析其优势及实际应用案例,旨在为开发人员提供有价值的参考与启示。
|
26天前
|
消息中间件 算法 Java
【亿级数据专题】「分布式服务框架」 盘点本年度我们探索服务的保障容量的三大关键方案实现
【亿级数据专题】「分布式服务框架」 盘点本年度我们探索服务的保障容量的三大关键方案实现
183 0
|
1月前
|
SpringCloudAlibaba Java 网络架构
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(七)Spring Cloud Gateway服务网关
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(七)Spring Cloud Gateway服务网关
98 0
|
30天前
|
消息中间件 Cloud Native 网络安全
云原生最佳实践系列 3:基于 SpringCloud 应用玩转 MSE
该文档介绍了基于云原生应用的产品构建的微服务架构实践。
|
1月前
|
SpringCloudAlibaba 负载均衡 Java
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(目录大纲)
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(目录大纲)
65 1
|
1月前
|
消息中间件 SpringCloudAlibaba Java
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(八)Config服务配置+bus消息总线+stream消息驱动+Sleuth链路追踪
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(八)Config服务配置+bus消息总线+stream消息驱动+Sleuth链路追踪
783 0

热门文章

最新文章