深入学习 Redis - 分布式锁底层实现原理，以及实际应用

桃扇骨 2024-03-02 02:54 11阅读 0赞

**目录**

一、Redis 分布式锁

1.1、什么是分布式锁

1.2、分布式锁的基础实现

1.2.1、引入场景

1.2.2、基础实现思想

1.2.3、引入 setnx

1.3、引入过期时间

1.4、过期时间续约问题（看门狗 Watch Dog）

1.5、引入校验 id

1.6、引入 lua 脚本

1.6.1、引入 lua 脚本的原因

1.6.2、lua 脚本介绍

1.7、引入 redlock 算法

1.8、分布式锁扩展

--------------------

## 一、Redis 分布式锁 ##

--------------------

### 1.1、什么是分布式锁 ###

锁就是用来解决线程安全的，分布式锁又是什么呢？

之前所学过的 **synchronized 本质上都是只能在一个进程内部生效的**，而**在分布式系统中，是有很多进程的（每个服务器都是一个独立的进程），多个进程之间的执行顺序也是不确定的**（随机的 ），之前的锁，就很应对分布式系统中多个进程之间产生的制约.

因此，就需要引入 “分布式锁” 来解决上述问题.

**分布式锁本质上就是一个公共的服务器，用来记录锁的状态。**

> Ps：这个公共的服务器可以是Redis, 也可以是其他组件(比如 MySQL 或者 ZooKeeper 等), 还可以是我们自己写的⼀个服务

### 1.2、分布式锁的基础实现 ###

#### 1.2.1、引入场景 ####

想象这样一个场景：买车票.

**实现思路：先查询剩余票数，如果剩余票数 > 0，则设置剩余票数 -= 1.**

![f412c574cbc94376a76fde3812d2a415.png][]

在没有引入分布式锁之前，就有可能出现以下买票场景：

*客户端1 先执行查询余票，发现剩余 1 张，在即将执行 剩余票数 -= 1 过程之前，客户端2 也执行了查询余票，发现也是剩余 1 张，客户端2 也会执行 剩余票数 -= 1. 的过程.*

这里就出现了 “超卖” 的场景！！！1 张票，卖给了两个人.

#### 1.2.2、基础实现思想 ####

分布式锁的实现思路很简单，**本质上是使用一个/一组 单独的服务器程序，通过用一个键值对来标识锁的状态，来给其他服务器提供 “加锁” 这样的服务.**

对于上述场景，进行买票操作过程中，就需要先加锁.

![17cc210bbcb34c7b90b915a8d424eebc.png][]

具体的，往 redis 上设置一个特殊的 key - value，接着完成买票操作，再把这个 key - value 删除掉. 如果在 客户端1 买票的期间，客户端2 也想去买票，就也会尝试设置 key - value，如果发现 key - value 已经存在，就分为 “加锁失败”（是放弃还是阻塞，就要看具体的实现策略了）.

这样就保证了 第一个服务器执行 “查询 -> 更新” 过程中，第二个服务器不会执行 “查询” ，也就解决了上述 “超卖” 问题.

> Ps：买票的场景使用 mysql 的事务，也可以批量执行 查询 + 修改 操作. 但是分布式系统中，要访问的共享资源不一定是 mysql ....... 也可能是其他存储介质，没有事务. 也可能是执行一段特定的操作，是通过统一的服务器完成指定动作.

#### 1.2.3、引入 setnx ####

针对于刚刚买票的场景：“key 不存在就设置成功，不存在就设置失败”. 使用 setnx 就可以达到 “加锁” 的效果. 针对解锁，就可以使用 del 命令来完成.

> 如果某个服务器，加锁成功了（setnx 成功），执行后续逻辑中，还没来得及执行 “解锁” 程序就崩溃了，怎么办？

以前在一个进程中，为了保证解锁的操作能执行到，可以把解锁的操作放到 finally 中，但是这种做法，只是针对进程内的锁有效，针对分布式锁，无效！

*比如，服务器直接掉电，进程直接异常终止，这就会导致 redis 上设置的 key 无人删除，也就导致其他服务器无法获取到锁了.*

### 1.3、引入过期时间 ###

针对上述 “没来得及解锁，服务器宕机的情况”，我们可以给 key 设置一个过期时间.

**通过 set ex nx 这样的命令完成设置，一旦时间到了，key 就会自动被删除掉.**

*比如，设置 key 的过期时间，为 1000ms，那么即使出现极端情况，某个服务器挂了，没有真正释放锁，这个锁最多保持 1000ms，也就自动释放了.*

> 可以通过先 setnx ，再使用 expire 的方式设置过期时间么？

不可以！！！务必要使用 set ex nx 的方式来设置！

redis 上多个命令之间，无法保证原子性，即使使用 事务，也不能保证这两个操作都能成功（redis 的事务只能保证不被 “插队”，不能保证操作成功）. 此时就有可能出现 setnx 成功，expire 失败的场景.

### 1.4、过期时间续约问题（看门狗 Watch Dog） ###

加锁的时候，给 key 设定 过期时间，设置成多少合适？

*  如果设置的时间过短，就可能在 业务逻辑 还没有执行完，就释放锁了.
 *  如果设置的时间太长，就可能导致 “锁释放的不及时” 的问题.

最好的方式就是 “动态续约”.

**具体的，初始情况下，设置一个过期时间（比如 1s），在还剩 300ms 的时候（这里的时间不一定是 300ms，数据灵活调整），如果当前任务还没有执行完，就把过期时间续上 1s，等到时间快到了，任务还没执行完，就再续（无限续杯）~**

上述过程中，如何知道当前任务还没有执行完，要进行续杯呢？**实际上，服务器这边有一个专门的线程，负责续约这个事情，这个线程也叫做 “看门狗”**（这是一个比较广义的概念，很多涉及到过期时间的操作都会引入 “看门狗” ）.

这样，即使服务器中途崩溃了，没人负责续约了，锁也能在短时间内自动释放.

*这就好比，吃自助餐，老板都是鼓励大家，每次少拿点，少量多次~ 怕的就是你一次拿太多，吃不完，大部分都剩下了. 如果每次少拿点，即使吃不下了，浪费的也不多了.*

### 1.5、引入校验 id ###

所谓锁，就是 redis 上的普通键值对.

所谓加锁，就是给 redis 上设置一个 key - value.

所谓解锁，就是把 redis 上这个 key - value 删除掉.

> 是否可能出现 服务器1 执行了加锁，服务器2 执行了解锁？

正常来说，肯定不是故意的，但是代码总会有 bug，不小心执行了解锁操作，就让这锁形同虚设，带来严重后果（比如 超卖）.

为了解决上述问题，就需要引入一点校验机制.

具体的，如下步骤：

**1. 给服务器编号，让每个服务器都有一个自己的身份标识.**

**2. 进行加锁的时候，设置 key - value， key 就表示要针对哪个资源加锁，value 就表示服务器的编号.**

**后续在解锁的时候，就可以进行校验了. 解锁的时候，先查询一下这个锁对应的服务器编号，然后判定这个编号是否就是当前执行解锁的服务器编号，如果是，才真正执行 del，如果不是，就失效.**

通过上述操作，就可以有效避免 “误解锁”.

### 1.6、引入 lua 脚本 ###

#### 1.6.1、引入 lua 脚本的原因 ####

一个服务器内部，也可能是多线程的. 此时，就可能两个线程都在执行 “解锁” 操作.

例如如下场景：

首先我们知道，解锁的操作分为两步，先通过 GET 服务器编号进行校验，校验成功后在进行 DEL.

在 服务器1 中，线程A 执行 GET 后 线程 B 也执行 GET，然后 线程A 执行 DEL 解锁，此时 线程 B 也执行 DEL 解锁.

![61149a71fa9d45cbbaad0bde5ad31ae6.png][]

上述情况，看起来好像重复执行 DEL 好像问题不大？实则不然！

如果此时还有一个服务器，执行加锁，就可能出问题了.

在 线程A 执行完 DEL 之后，线程 B 执行 DEL 之前，服务器2 的 线程C 正好要执行 加锁(set ex nx)，此时，由于 A 已经解锁了，C 的加锁能成功，但是紧接着，线程 B DEL 就来了，就把 服务器2 刚刚的加锁操作给解除了.

![8e1102d9a3c54153b9c6ebd371efb1ed.png][]

归根结底，还是因为 get 和 del 不是一条原子操作产生的问题.

使用事务，虽然可以解决上述问题（redis 事务虽然弱，但是能够避免插队），但是实践中，往往使用更好的方案 —— lua 脚本.

#### 1.6.2、lua 脚本介绍 ####

lua 语言特别轻量（实现一个 lua 解释器，消耗的体积非常小），可以使用 lua 编写一些逻辑，把这个脚本上传到 redis 服务器上，然后就可以让客户端来控制 redis 执行上述脚本了.

最重要的一点就是，redis 执行一个 lua 脚本，就相当于在 redis 上执行一个命令一样，是原子的. 并且 redis 官方文档中也明确说，lua 就属于是 事务 的替代方案.

例如前面的 “买票” 案例.

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

ARGV\[1\]：表示调用脚本给定的参数，此处要传入一个服务器的 id.

如果 id 和 get 到参数匹配，就进行删除操作.

### 1.7、引入 redlock 算法 ###

使用 redis 作为分布式锁，redis 本身有没有可能挂了呢？

是很有可能的！

实际工作中的 redis 都是以集群的方式部署的（至少是主从，不会是单机），那么就有可能出现以下大冤种的情况：

*服务器1 向 master 节点进行加锁操作. 这个写⼊ key 的过程刚刚完成, master 挂了; slave 节点升级成了新的 master 节点. 但是由于刚才写⼊的这个 key 尚未来得及同步给 slave（主节点和从节点之间的数据同步，是存在延迟的）, 此时 就相当于服务器1 的加锁操作形同虚设了, 服务器2 仍然可以进行加锁.*

**为了解决以上问题，就提出了 redlock 算法（redis 作者给出的方案）**

![4dd8f19de9474d76ad2f857b0f2f8918.png][]

1.  此处加锁，就是按照一定的顺序，针对这组 redis 都进行加锁操作.
2.  如果某个节点加不上锁，没关系，可能是 redis 挂了，继续给下一个节点加锁即可.
3.  如果写入 key 成功的节点个数超过总数的一半，就视为 加锁成功.
4.  同理，进行解锁的时候，也会把上述节点都解锁一遍.

### 1.8、分布式锁扩展 ###

上面介绍的只是简单的 “互斥锁”.

锁这里还涉及到一些其他情况：

1. 读写锁.

2. 公平锁.

3. 可重入锁

........

基于 redis 也可以实现上述锁的特性，这里大家下来可以自己尝试实现以下~

![166adb84dd59471591e095699a581cdd.gif][]

[f412c574cbc94376a76fde3812d2a415.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/e98a705381f14d6bbb9889d509dccf93.png
[17cc210bbcb34c7b90b915a8d424eebc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/9c7f8a86d236450c97075acbc3f9b425.png
[61149a71fa9d45cbbaad0bde5ad31ae6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/796076754c864ae18a1c9f8dc9f17ec6.png
[8e1102d9a3c54153b9c6ebd371efb1ed.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/0c2eb020afc34439af197a3135635254.png
[4dd8f19de9474d76ad2f857b0f2f8918.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/a93e50f030a9450fb3a235b9d69fb8b1.png
[166adb84dd59471591e095699a581cdd.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/02/6128b79b25294ea49ab42d1eeacdfd5e.png