详解Redis分布式锁（图文并茂，手把手搭建服务，一文轻松搞定

最新推荐文章于 2024-06-16 15:00:00 发布

彩虹的颜

最新推荐文章于 2024-06-16 15:00:00 发布

阅读量1.1k

点赞数 18

分类专栏： 2024年程序员学习文章标签： redis 分布式 wpf

本文链接：https://blog.csdn.net/m0_74931167/article/details/137615471

版权

2024年程序员学习专栏收录该内容

195 篇文章 0 订阅

订阅专栏

分布式知识是考验一个程序员知识面广度和深度很好的度量标准，而分布式锁又是其中非常重要的一个知识点。可以说面试只要谈到分布式，没有不问分布式锁的。

我们知道分布式应用在进行逻辑处理的时候经常涉及到并发的问题，比如对一个转账修改一个用户的账户金额数据，此时可能会涉及多个用户同时对这个用户进行转账，它们都需要将数据读取到各内存中进行修改，然后再存刷新回去，这个时候就会出现并发问题：

这里假设初始account.money = 400

客户端A，向账户转账100，并未提交到Redis
客户端B，读取金额为400，并向账户转账200
客户端A提交
客户端B提交

最后account.money = 600

执行流程如下所示：

并发场景示例.png

出现上述问题的主要原因是，“读取”和“写入”这两个操作并不是一个原子操作（所谓原子操作是指不会被线程调度机制打断的操作；这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch （切换到另一个线程））。

关于上述问题的解决，分布式锁就可以派上用场了，我们通过分布式锁来限制程序的并发执行，就像Java中的synchronized，常见的分布式锁解决方案如下所示：

基于数据库锁机制实现的分布式锁
基于Zookeeper实现的分布式锁
基于Redis实现的分布式锁

本文和大家共同探讨的是基于Redis的分布式锁。

二、分布式锁的演进

2.1 精细胞与卵细胞的爱情故事

嗯……学过生物的宝宝们都知道，精细胞和卵细胞相遇的故事，上亿精细胞中最后也只会有一个幸运的精细胞和卵细胞发生甜蜜的爱情故事，这是因为当有一个精子进入卵子后，卵子会发生皮质反应、透明带反应使透明带对精子的结合能力下降，阻止了多精受精。分布式锁就好像卵细胞，而万千访问客户端就好比精细胞，无论客户访问并发多激烈，我们也应该保证分布式锁只被一个线程获取到。

u=131622752,2670653155&fm=26&fmt=auto&gp=0.webp

2.2 Redis中的分布式锁

2.2.1 setnx

我们将Redis实现分布式锁理解为上厕所蹲坑排队，只有一个坑，但是有多个人要到坑里面去，所以就只能一个一个的来了。

u=1315806982,1319670206&fm=26&fmt=auto&gp=0.webp

很多人一开始想到的是Redis中一般使用setnx(set if no exists)指令来实现，setnx是如果不存在，则 SET的简写，这个指令描述如下：

只在键 key 不存在的情况下，将键 key 的值设置为 value 。
若键 key 已经存在，则 SETNX 命令不做任何动作。

127.0.0.1:6379> exists lock # lock key不存在

(integer) 0

127.0.0.1:6379> setnx lock true # 设值成功

(integer) 1

127.0.0.1:6379> setnx lock false # 覆盖失败

(integer) 0

127.0.0.1:6379> del lock # 删除lock 释放

(integer) 1

如上这种方案存在的问题非常明显，如果逻辑执行过程中间出现了异常，可能导致del key 指令没有执行，这样会产生死锁。如下图所示：

删除key出问题导致死锁 (1).png

2.2.2 setnx + expire

在第一种解决方案的基础上，可能部分人会相到，既然主动删除key可能会出现异常情况，那么就设值key的过期时间到期自动删除。

127.0.0.1:6379> setnx lock true

(integer) 1

127.0.0.1:6379> expire lock 10 # 设值过期时间10s

(integer) 1

127.0.0.1:6379> setnx lock true # 10s内再次设值失败

(integer) 0

127.0.0.1:6379> setnx lock true # 10skey过期，后设置成功

(integer) 1

这种的方案和前面的方案其实并没有本质上的区别，它还是可能会出现服务器异常等情况，导致expire的不到执行的情况，换汤不换药，如下图所示：

setnx + expire.png

2.2.3 原子操作

基于上面两种方案，我们可以发现，产生问题的本质在于两个操作并不是原子操作。方案一中是setnx指令加一个del指令，方案二中是setnx指令加一个expire指令，这两个指令并不是原子指令。基于这个问题，Redis官方将这两个指令组合在了一起，解决Redis分布式锁原子性操作的问题。

先认真看set指令可选参数 EX 和 NX

set key value [EX seconds] [PX milliseconds] [NX|XX]

EX seconds ：将键的过期时间设置为 seconds 秒。执行 SET key value EX seconds 的效果等同于执行 SETEX key seconds value 。

PX milliseconds ：将键的过期时间设置为 milliseconds 毫秒。执行 SET key value PX milliseconds 的效果等同于执行 PSETEX key milliseconds value 。

NX：只在键不存在时，才对键进行设置操作。执行 SET key value NX 的效果等同于执行 SETNX key value 。

XX ：只在键已经存在时，才对键进行设置操作。

127.0.0.1:6379> set lock true EX 10 NX # 设置 10s生效

127.0.0.1:6379> set lock true EX 10 NX # 10s内再次设值失败

(nil)

127.0.0.1:6379> set lock true EX 10 NX # 10s后设置成功

如上这个操作就成功的解决了Redis分布式锁的原子操作问题。

2.2.4 解锁

Redis分布式锁加锁在上面讲述了，而Redis分布式锁的解锁过程其实就是将key删除，key的删除有客户端调用del指令删除，也有设置key的过期时间自动删除。但是这个删除不能乱删除，不能说客户端A请求的锁被客户端B给删除了……，那这把锁就是一把烂锁了。

为了防止客户端A请求的锁被客户端B给删除了这种情况，我们通过匹配客户端传入的锁的值与当前锁的值是否相等来做判断（这个值是随机且保证不会重复的），如果相等就删除，解锁成功。

但是Redis并未提供这样的功能，我们只能通过Lua脚本来处理，因为Lua脚本可以保证多个指令的原子性执行。

示例：

首先设置一个key，这个key的值是123456789，通过客户端传入的value值是否相等来校验是否允许删除这个key

127.0.0.1:6379> get lock

(nil)

127.0.0.1:6379> set lock 123456789 # 设置一个key 值为123456789

127.0.0.1:6379> get lock

“123456789”

在客户机上编写lua脚本，lock.lua文件，文件内容如下

if redis.call(“get”,KEYS[1]) == ARGV[1] then

return redis.call(“del”,KEYS[1])

else

return 0

end

测试通过错误的value值去执行lua脚本，这个时候删除key失败，返回0

通过正确的value值执行则返回1，说明key被删除了。

2.2.5 代码实现

一下演示一个spring boot项目来实现Redis分布式锁，为了方便大家使用，我贴出的代码比较全面，篇幅稍多。

pom依赖

org.springframework.boot

spring-boot-starter-parent

2.3.4.RELEASE

org.springframework.boot

spring-boot-starter-web

redis.clients

jedis

3.0.1

org.projectlombok

lombok

cn.hutool

hutool-all

5.3.4

Redis配置文件

package com.lizba.config;

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

import org.springframework.beans.factory.annotation.Value;

import org.springframework.cache.annotation.CachingConfigurerSupport;

import org.springframework.context.annotation.Bean;

import org.springframework.context.annotation.Configuration;

import redis.clients.jedis.JedisPool;

import redis.clients.jedis.JedisPoolConfig;

/**

```
    Redis简单配置文件
```
@Author: Liziba
@Date: 2021/7/11 11:17

@Configuration

public class RedisConfig extends CachingConfigurerSupport {

protected static final Logger logger = LoggerFactory.getLogger(RedisConfig.class);

@Value(“${spring.redis.host}”)

private String host;

@Value(“${spring.redis.port}”)

private int port;

@Value(“${spring.redis.jedis.pool.max-active}”)

private int maxTotal;

@Value(“${spring.redis.jedis.pool.max-idle}”)

private int maxIdle;

@Value(“${spring.redis.jedis.pool.min-idle}”)

private int minIdle;

@Value(“${spring.redis.password}”)

private String password;

@Value(“${spring.redis.timeout}”)

private int timeout;

@Bean

public JedisPool redisPoolFactory() {

JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();

jedisPoolConfig.setMaxTotal(maxTotal);

jedisPoolConfig.setMaxIdle(maxIdle);

jedisPoolConfig.setMinIdle(minIdle);

JedisPool jedisPool = new JedisPool(jedisPoolConfig, host, port, timeout, null);

logger.info(“JedisPool注入成功！！”);

logger.info(“redis地址：” + host + “:” + port);

return jedisPool;

}

application.yml配置文件

server:

port: 18080

spring:

redis:

database: 0

host: 127.0.0.1

port: 6379

timeout: 10000

password:

jedis:

pool:

max-active: 20

max-idle: 20

min-idle: 0

获取锁与释放锁代码

package com.lizba.utill;

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.stereotype.Service;

import redis.clients.jedis.Jedis;

import redis.clients.jedis.JedisPool;

import redis.clients.jedis.params.SetParams;

import java.util.Arrays;

import java.util.concurrent.TimeUnit;

/**

```
  Redis分布式锁简单工具类
```
@Author: Liziba
@Date: 2021/7/11 11:42

@Service

public class RedisLockUtil {

private static Logger logger = LoggerFactory.getLogger(RedisLockUtil.class);

/**

锁键 -> key

private final String LOCK_KEY = “lock_key”;

/**

锁过期时间 -> TTL

private Long millisecondsToExpire = 10000L;

/**

获取锁超时时间 -> get lock timeout for return

private Long timeout = 300L;

/**

LUA脚本 -> 分布式锁解锁原子操作脚本

private static final String LUA_SCRIPT =

“if redis.call(‘get’,KEYS[1]) == ARGV[1] then” +

" return redis.call(‘del’,KEYS[1]) " +

“else” +

" return 0 " +

“end”;

/**

set命令参数

private SetParams params = SetParams.setParams().nx().px(millisecondsToExpire);

@Autowired

private JedisPool jedisPool;

/**

加锁 -> 超时锁

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）

最后的话

无论是哪家公司，都很重视Spring框架技术，重视基础，所以千万别小看任何知识。面试是一个双向选择的过程，不要抱着畏惧的心态去面试，不利于自己的发挥。
同时看中的应该不止薪资，还要看你是不是真的喜欢这家公司，好了希望这篇文章对大家有帮助！

部分截图：
在这里插入图片描述

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

Su9HHANt-1712762105268)]
[外链图片转存中…(img-6D0CO2Db-1712762105269)]
[外链图片转存中…(img-LnPMhfkG-1712762105269)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-mYXQi4kA-1712762105269)]

最后的话

部分截图：
[外链图片转存中…(img-hLyuNXo4-1712762105270)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-D1hQrK9q-1712762105270)]

彩虹的颜

关注

18
点赞
踩
25

收藏

觉得还不错? 一键收藏
0
评论
详解Redis分布式锁（图文并茂，手把手搭建服务，一文轻松搞定

无论是哪家公司，都很重视Spring框架技术，重视基础，所以千万别小看任何知识。面试是一个双向选择的过程，不要抱着畏惧的心态去面试，不利于自己的发挥。同时看中的应该不止薪资，还要看你是不是真的喜欢这家公司，好了希望这篇文章对大家有帮助！一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
复制链接

扫一扫