微服务实战系列之ZooKeeper(下)
前言
通过前序两篇关于ZooKeeper
的介绍和总结,我们可以大致理解了它是什么,它有哪些重要组成部分。
今天,博主特别介绍一下ZooKeeper的一个核心应用场景:分布式锁
。
应用ZooKeeper
Q:什么是分布式锁
首先了解一下,什么是锁。
1. 什么是锁
在我们日常开发中,可能会经常使用多线程并发,以提高系统性能,加速代码的处理效率。那么问题也就来了?当在有限的资源、网络环境下,如果一味追求并发,势必拖垮整个系统,甚至宕机。
所以,Java在推出之时,就提供了多种锁机制,以避免或降低上述问题的发生。
也就是一句话总结,什么是锁:
通过有序的处理手段,实现线程安全和数据准确,保障系统正常运转。
当然Java中的锁机制,已经很多介绍了,这里不再展开。
2. 什么是分布式锁
所谓分布式锁,无非是在分布式环境下,如何使用“锁”
的机制。所以在这里,我们重点讲一下分布式环境下,ZooKeeper
如何使用锁,保障线程安全和数据准确,避免并发带来的问题。
3. 基础概念
3.1 Znode-节点
Znode其实就是ZooKeeper文件节点,因为是多层树状结构,因此,每层节点可以理解为一个Node(节点)。ZooKeeper
提供了四类Node:
Znode类型 | Znode简介 |
---|---|
PERSISTENT | 永久节点,已持久化至存储,即使客户端断开,也存在 |
EPHEMERAL | 临时节点,客户端断开即删除 |
PERSISTENT_SEQUENTIAL | 永久节点,按序顺序编号 |
EPHEMERAL_SEQUENTIAL | 临时节点,按序顺序编号 |
3.2 Event-事件
ZooKeeper
提供了四种监听事件,当节点数据或结构变化时,即通知客户端:
- 节点创建
- 节点删除
- 节点数据修改
- 子节点变更
Q:如何实现分布式锁
通过以上对“分布式锁”
的解剖,我们应该知道了它是如何运转的,其实核心是两个点:
- 顺序排队
- 加锁解锁
这不巧了,ZooKeeper的树形数据结构,正好完美实现了以上2点。
1. 先来先加锁
首先,假如小张作为第一名,通过ZK
(ZooKeeper行业简称),创建了第一个
锁。这里所谓的“锁”
,其实一个全局唯一的文件(即ZNode
)。创建ZNode完成后,即可以通过锁定目标资源,进行后序操作。如果此刻小王来了,怎么办?
2. 后来等解锁
小王作为(按顺序)第二名前来索取资源,当然无法如愿以偿,那得先看小张答不答应了。但小张此刻正手忙脚乱,哪有闲功夫管什么小王小李…的事。所以ZK
想到了一个好办法:“你可以不主动,那我主动好了”
。通过给小王加“跟踪器”
,就可以随时随地知道小王的一举一动了。
如果小王拿完资源后,ZK
会通过事件通知小王,那么小王当然可以顺理成章的索取资源了。当然前提是小王退出竞争行列,如何退出? 简单一句话:“拿来什么,带走什么”
。ZNode乃身外之物,真正做到了“无痕访问”
了。
通过以上机制,ZK提供了一整套加锁解锁的方法,所以在分布式场景下,它自然能够合理有效地解决了资源竞争问题。
结语
在并发环境下,往往经常遇到资源竞争问题,当你考虑如何解决竞争时,ZooKeeper是一个合理的选择。当然集群部署是必要,唯一的考虑是成本是否足够。
好了,博主通过上中下三篇,揭秘ZooKeeper,从功能、内核、应用三个方向,分别对它加以说明。希望各位盆友可以学到,进而用到实际工作中。感谢捧场,欢迎订阅与分享!
历史回顾
- 微服务实战系列之ZooKeeper(中)
- 微服务实战系列之ZooKeeper(上)
- 微服务实战系列之MQ
- 微服务实战系列之通信
- 微服务实战系列之J2Cache
- 微服务实战系列之Cache(技巧篇)
- 微服务实战系列之MemCache
- 微服务实战系列之EhCache
- 微服务实战系列之Redis
- 微服务实战系列之Cache
- 微服务实战系列之Nginx(技巧篇)
- 微服务实战系列之Nginx
- 微服务实战系列之Feign
- 微服务实战系列之Sentinel
- 微服务实战系列之Token
- 微服务实战系列之Nacos
- 微服务实战系列之Gateway
- 微服务实战系列之加密RSA
- 微服务实战系列之签名Sign
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!