微服务实战系列之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提供了四种监听事件，当节点数据或结构变化时，即通知客户端：

1. 节点创建
2. 节点删除
3. 节点数据修改
4. 子节点变更

Q：如何实现分布式锁

通过以上对“分布式锁”的解剖，我们应该知道了它是如何运转的，其实核心是两个点：

1. 顺序排队
2. 加锁解锁

这不巧了，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

---