微服务实战系列之ZooKeeper(下)

前言

通过前序两篇关于ZooKeeper的介绍和总结,我们可以大致理解了它是什么,它有哪些重要组成部分。

今天,博主特别介绍一下ZooKeeper的一个核心应用场景:分布式锁

微服务实战系列之ZooKeeper(下)_第1张图片

应用ZooKeeper

Q:什么是分布式锁

首先了解一下,什么是锁。

1. 什么是锁

在我们日常开发中,可能会经常使用多线程并发,以提高系统性能,加速代码的处理效率。那么问题也就来了?当在有限的资源、网络环境下,如果一味追求并发,势必拖垮整个系统,甚至宕机。

微服务实战系列之ZooKeeper(下)_第2张图片
所以,Java在推出之时,就提供了多种锁机制,以避免或降低上述问题的发生。
也就是一句话总结,什么是锁:

通过有序的处理手段,实现线程安全和数据准确,保障系统正常运转。

当然Java中的锁机制,已经很多介绍了,这里不再展开。

2. 什么是分布式锁

所谓分布式锁,无非是在分布式环境下,如何使用“锁”的机制。所以在这里,我们重点讲一下分布式环境下,ZooKeeper如何使用锁,保障线程安全和数据准确,避免并发带来的问题。

微服务实战系列之ZooKeeper(下)_第3张图片

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点。
微服务实战系列之ZooKeeper(下)_第4张图片

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

在这里插入图片描述

你可能感兴趣的:(架构设计,微服务,zookeeper,架构,分布式锁)