# 前言
> **🍊作者简介：** 不肯过江东丶，一个来自二线城市的程序员，致力于用“猥琐”办法解决繁琐问题，让复杂的问题变得通俗易懂。
> **🍊支持作者：** 点赞👍、关注💖、留言💌~

随着分布式技术的不断发展以及广泛运用，目前大部分应用软件都采用了分布式架构。在分布式系统中，我们常常需要协调各个模块的动作，如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，这个时候，便需要使用到分布式锁。那么今天大聪明就和大家一起深入浅出的聊一聊分布式锁。

# 为什么要用到锁
在聊分布式锁之前，各位小伙伴可以先考虑一个问题：什么时候需要加锁？关于这个问题的答案也很简单：

 1. **有并发，多线程**：这里指的是资源的使用者多。也就是在多任务环境下才可能需要锁的存在，多个任务想同时使用一个资源才有竞争的可能。
 2. **有写操作：** 这里指的是使用资源的目的。如果是多个任务都是读请求的话，资源就在那里，不同任务来读取的结果都是一样的，也就无所谓谁先读谁后读了。
 3. **有竞争关系：** 这里指的是对资源的访问方式是互斥的。资源虽然是共享的，但同一时刻只能有一个任务占用它，不能同时共用，这个时候我们需要给它上锁。

可能上面的说的三个场景不方便各位小伙伴理解，俗话说 **“繁琐问题必有猥琐解法”** ，那么下面我们举一个“猥琐”的例子帮助大家加深印象 👇

> 比如家里只有一个卫生间，全家都可以使用，我们暂且称之为共享资源。 🍊情景一：如果现在家里只有你一个人，是不是你想什么时候用就什么时候用？想用多久都可以，想在里面睡觉也可以。这个时候就不存在竞争了，不锁门也没人闯进来。 🍊情景二：如果现在家里不止你一个人了，家里人也在了，但是呢，大家都不需要使用，可能只是都想来看看有没有人在测所里而已，看完就走了。 🍊情景三：如果家里有很多人，这个时候都需要使用卫生间，那就需要抢占了。先抢到的人，就需要先把门锁上了，免得其他人来干扰。 三个场景就分别对应了上面的三个回答，总结起来就是一句话：一多二写三竞争。

言归正传，我们继续说锁的问题。如果是传统单机项目（即单个JVM环境下多线程）对共享资源的并发更新处理，我们可以简单地使用 JDK 提供的 ReentrantLock 对共享资源进行加锁处理。

```java
ReentrantLock lock = new ReentrantLock();
try {
	//加锁
 lock.lock();
 //处理具体业务逻辑，即对共享资源进行操作
} finally {
	//释放锁
 lock.unlock();
}
```

如果是在微服务架构多实例的环境下，每一个服务都有多个节点，这个时候再用 ReentrantLock 就没办法控制了，因为在微服务架构下这些任务是跨 JVM 的，也就不再是简单的单体应用了，我们就需要协同多个节点信息，共同获取锁的竞争情况，那么这时候就需要用到分布式锁了。

# 如何实现分布式锁
## 基于数据库实现分布式锁
第一种方式，我们可以利用数据库来实现分布式锁。比如说我们创建一张表（暂且命名为 sys_lock），表中的每条记录代表一个共享资源的锁，其中有一个 status 字段代表锁的状态，1 代表已上锁，0 代表未上锁。

我们以商城系统为例，如果此时有用户在系统内下单，那么对应商品的库存就要进行减1操作。此时有一个线程要来更新，它先根据商品ID找到代表该共享资源的锁，然后执行下面这个语句 👇

```sql
update sys_lock 
 set t.status = '1' 
 where t.resource_id = 'xxxx'
 and t.status = '0';
```

如果这条语句执行成功了并且返回的影响记录数是1，那么说明了获取锁成功了，该线程就可以继续执行更新商品库存的操作，然后释放锁时，也就是将 status 从 1 改为 0 即可。

> 这个过程很简单，看起来也很正常，但是我们却面临着一个非常严重的问题：如果这个锁已经被其他线程占用了，也就是 status 的值为1，这个时候 sql 语句就无法正常执行，也就意味着获取不到锁，那么程序就只能以轮询的方式去尝试获取锁。这种类似自旋锁的阻塞方式对数据库资源消耗极大，而在分布式环境中，尤其需要使用分布式锁的场景，基本上都是要求支持高并发的，这就出现一个悖论了。正是因为这一点，通过数据库实现分布式锁的方式在大部分应用场景中都用不上。

## 基于单体 Redis 实现的分布式锁
既然数据库性能不够好，我们就该请出常用的缓存中间件 Redis 来帮我们实现分布式锁了。相信很多小伙伴都用 Redis 实现过分布式锁，实现的步骤也非常简单，首先我们会先向 Redis 获取锁，然后返回是否获取成功，如果获取成功了那就可以开始操作共享资源，那么这段时间这个锁就被占用了，当资源操作完毕后再释放锁。说白了也就是三个步骤：**获取锁**、**使用锁**、**释放锁**。

接下来我们具体的讲一下这三个实现步骤 👇

🍓 **第一步：获取锁**

获取锁的方式非常简单，我们只需要执行一条命令即可 👇

> SET key value NX PX|EX time 我们对命令中的各个参数做一个解释： **KEY：** 锁的唯一标识，用于获取和释放锁。 **NX：** 它是 Redis 的语义，表示这个 key 不存在的时候才能 set 成功，这里起到了互斥性的保证，满足一个锁最基本的特性。 **PX|EX：** 缓存的过期时间，表示多少毫秒或者多少秒过期。

🍓 **第二步：使用锁**

当我们成功获取到锁后，就可以对互斥资源进行操作了，此处省略两千字.... （我也不知道各位小伙伴都要对互斥资源干点啥，这里一笔带过😄）

🍓 **第三步：释放锁**

释放锁的时候，我们通常会使用 Lua 脚本，我们来看看下面这个语句块 👇

```lua
if redis.call("get", KEYS[1]) == ARGV[1] then
 return redis.call("del", KEYS[1])
else
 return 0
end
```

> **KEYS[1]**：它代表的是获取锁时输入的 key，也就是锁的唯一标识。 **ARGV[1]**：它代表的是获取锁时输入的 value，这个 value 的唯一性决定了使用者只能删除自身已经获取的锁，不会误删除别人的。 上述语句块的完整语义是：当输入的 KEYS[1] 键在 Redis 里面的 value 值等于输入的 AEGV[1] 时，则删除这个原有的 KEY，即代表释放锁操作。

下面我们深入思考几个问题 👇

🍊 **问题一：为什么在获取锁的时候要设置过期时间？**

> 我们想象一下这种场景，当一个使用者获取锁成功之后，系统崩溃了（应用发生 GC 把业务执行流程给阻塞住了，或者时钟发生变化导致系统无法和 Redis 节点进行通信），此时这个对应的锁就一直不会过期了，因为有互斥的机制所以其他使用者尝试获取锁都 set 不成功，由于释放时会判断使用者是否是锁的持有者，导致了锁也一直无法被释放。因此，获取锁一定要给它设置过期时间，也就是这个锁是有租期的，使用者必须在这个规定的租期内完成对共享资源的操作，租期一到，即便使用者没有主动释放，那么锁也会自动过期。

🍊 **问题二：为什么释放锁的时候要引入 Lua 脚本？**

> 其实这里是为了保证操作原子性。包括获取锁的 set 命令，也需要原子性的保障。

如果我们在不考虑原子性的情况下，可以把上面获取锁和释放锁的命令改造成下面这样👇
```lua
-- 获取锁
set key value; 
expire key time;

-- 释放锁
get key == value
del key
```
我们先看看获取锁的命令，使用者执行第一条成功了才会执行第二条，那如果执行第一条成功之后使用者崩溃了，当它再连上的时候是不是就变成了我们上面说的那种情况，没有设置锁的过期时间。

接下来我们看看释放锁的命令拆成两句又有什么问题。假如使用者A完成任务之后准备释放自己持有的锁，它先通过 get key 得到一个值，用来判断出这个锁确实是自己持有的锁，并且还没有释放。这时候A由于某种原因，它还是崩溃了，就阻塞了一段时间，在这段时间锁恰好因为超时自动释放掉了。然后，使用者B刚好来获取锁，也就是执行了上面的 set 命令。接下来使用者A恢复了，比如GC完成，然后就开始执行它的第二步操作，也就是 del key 操作，这也就导致把使用者B的锁给删除掉了。相当于锁的持有者和释放者就不一致了，从而导致了锁状态出现错乱。

🍊 **问题三：使用单体 Redis 实现分布式锁有什么风险？**

> 如果这个 Redis 实例挂了，那就意味着整个锁机制失效了，此时使用者无法获取和释放锁，进一步导致使用者无法正常使用共享资源，从而出现阻塞、访问失败或者访问冲突等异常，甚至可能因为共享资源失去了锁的保护 ，引起数据不一致，导致业务上一系列连锁反应。

🍊 **问题四：如何规避问题三中提到的问题？**

> 有些小伙伴第一反应就是想到将缓存持久化。这种方式其实是通过利用 Redis 本身的 AOF 持久化机制来保存每一条请求。如果 Redis 挂了，这个时候直接重新拉起，再通过 AOF 文件进行数据恢复。假如说我们把 AOF 的同步机制设置为每秒钟同步一次，那这种情况下 Redis 的 AOF 持久化机制并不能保证完全不丢数据，也就是可能恢复之后少了某个锁的数据，这样其他使用者就可以获取到这个锁，导致状态错乱。假如说我们把它设置为 Always，就是每个操作都要同步，这样的话会严重降低 Redis 的性能，发挥不出它的优势。还有一点就是 AOF 文件的恢复一般比较耗时，这个时间不可控，取决于文件的大小，也就是文件越大，所需要的恢复时间越长，那恢复期间锁就是不可用的状态。 那有些小伙伴又要说了，如果采用 Redis 集群的方式是不是可以完美规避上述的风险呢？使用主从（或者一主多从）进行高可用部署，当主节点挂了，从节点接手相关任务并保持锁机不变。其实这种方式也是存在一些问题的，首先主从复制它是异步的，所以这种方式也会存在数据丢失的风险。主从高可用机制发现主节点不可用，到完成主从切换也是需要一定时间的，这个时间跟锁的过期时间需要平衡好，否则当从节点接受之后，这个锁的状态及正确性是不可控的。


从上面的分析我们可以看到，单体 Redis 在高可用方面还是存在不少问题的。如果我们的应用场景需要支持高并发，并且对它在这些特殊情况下的问题可以容忍的话，那我们完全可以采用这种方式，它的实现起来相对简单，并且性能也比较好。那么有没有更具高可用的分布式锁实现方式呢？各位稍安勿躁，我们继续往下看...

## 基于 Redis 的高可用分布式锁——RedLock
RedLock 是 Redis 作者提出来的高可用分布式锁。它由多个**完全独立**的 Redis 节点组成，而不是主从关系或者集群关系，并且一般是要求各个节点分开部署。它利用分布式系统中**大多数存活即可用原则**来保证锁的高可用。针对每个单独的节点获取锁和释放锁的操作，完全采用我们上面描述的单体版 Redis 实现分布式锁的方式。

![c3607bfed073c324ba730fd9b1cdc4ed.jpeg](https://developer.qcloudimg.com/http-save/yehe-4287693/8dda6cd0ebcea8ac63f77d18c04890ed.png)

我们以上图为例（图片来自百度），讲解一下 RedLock 如何获取锁和释放锁 👇

 1. 生成随机值：当一个进程需要获取锁时，它首先会生成一个随机的字符串作为锁的值。
 2. 获取当前时间：进程获取当前的时间戳，用于计算锁的有效期限。
 3. 尝试获取锁：进程**依次**向多个 Redis 节点发送 SET 命令，尝试在每个节点上设置锁。设置锁时，需要指定锁的名称、值和过期时间。
 4. 统计成功设置锁的数量：进程统计成功设置锁的数量，如果大于等于设定的最小成功数（例如大多数节点），则认为成功获取到了锁。
 5. 判断是否获得锁：如果成功获取到了锁，则进程获得了互斥访问资源的权限；否则，进程需要释放已经设置的锁，并等待一段时间后再次尝试获取锁。
 6. 续约锁的有效期限：如果进程成功获取到了锁，在锁的有效期限内，进程会定期续约锁的过期时间，以确保持有锁的权限。
 7. 释放锁：当进程不再需要锁时，它会向所有的 Redis 节点发送 DEL 命令，将锁从每个节点上删除，从而释放锁。

在上述的步骤中，我们注意到了一个关键词 **“依次”**，也就是说我们在请求的时候，要按顺序去分别请求各个 Redis 节点。我们反过来思考一下，如果不按顺序会怎么样呢？假如有三个客户端同时来抢锁，客户端A先获取到1号和2号节点，客户端B先获取到3号4号节点，客户端C先获取到5号节点，那么这时候就满足不了多数原则，也就导致了三个客户端都无法获取到锁。

> RedLock 的主要操作流程就是这样，那么这个号称是真正的分布式锁，相比前面单机版的锁，很明显的一个点就是它不再是单点的，所以在高可用性上面，它是比单机版的锁有提升的。

以上就是常见的实现分布式锁的各种方式，每种实现方式都有自己的优点和缺点，无论使用那种方式，我们都需要结合系统的实际情况，适合自己的才是最好的~ 😊
# 小结
本人经验有限，有些地方可能讲的没有特别到位，如果您在阅读的时候想到了什么问题，欢迎在评论区留言，我们后续再一一探讨🙇‍

> 希望各位小伙伴动动自己可爱的小手，来一波点赞+关注 (✿◡‿◡) 让更多小伙伴看到这篇文章~ 蟹蟹呦(●'◡'●)

如果文章中有错误，欢迎大家留言指正；若您有更好、更独到的理解，欢迎您在留言区留下您的宝贵想法。

> *你在被打击时，记起你的珍贵，抵抗恶意；*
*你在迷茫时，坚信你的珍贵，抛开蜚语；*
**爱你所爱 行你所行 听从你心 无问东西**

🍊作者简介： 不肯过江东丶，一个来自二线城市的程序员，致力于用“猥琐”办法解决繁琐问题，让复杂的问题变得通俗易懂。 🍊支持作者： 点赞👍、关注💖、留言💌~

大聪明教你学Java | 深入浅出聊分布式锁

在分布式系统中，我们常常需要协调各个模块的动作，如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，这个时候，便需要使用到分布式锁。那么今天大聪明就和大家一起深入浅出的聊一聊分布式锁。

高级Java开发工程师

后端

数据库

架构设计

分布式锁是协调多系统共享资源访问的关键技术，本文深入解析其应用场景与实现方式。从单机锁到分布式环境，对比数据库、Redis单体和RedLock三种方案，分析优缺点及适用场景，帮助开发者选择适合的分布式锁方案，确保系统高并发下的数据一致性。

微服务架构

数据丢失

数据恢复

中间件

Redis

云数据库采购特惠，高性能、高可靠、高安全，超值优惠等你享！


AI驱动 智领未来

tencentdb-catalog

message-queue-catalog

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

大聪明教你学Java | 深入浅出聊分布式锁-腾讯云开发者社区-腾讯云

大聪明教你学Java | 深入浅出聊分布式锁

大聪明教你学Java | 深入浅出聊分布式锁

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐