如何使用Redis实现分布式重入锁？
Redis Assistant 是一款为Redis设计的高效可视化管理与监控工具，提供多种操作模式，高效处理服务器数据。日常使用里的持续防护和信息管理会更突出，适合把安全控制放进长期使用流程中的场景。
什么是不可重入锁？即若当前线程执行某个方法已经获取了该锁，那么在方法中尝试再次获取锁时，就会获取不到而阻塞。什么是可重入锁？可重入锁，也叫做递归锁，指的是在同一线程内，外层函数获得锁之后，内层递归函数仍然可以获取到该锁。就是同一个线程再次进入同样代码时，可以再次拿到该锁。可重入锁作用？防止在同一线程中多次获取锁而导致死锁发生。注：在java的编程中synchronized和ReentrantLock都是可重入锁。基于synchronized的可重入锁步骤1：双重加锁逻辑publicclassSynchro
什么是不可重入锁？
即若当前线程执行某个方法已经获取了该锁，那么在方法中尝试再次获取锁时，就会获取不到而阻塞。
什么是可重入锁？
可重入锁，也叫做递归锁，指的是在同一线程内，外层函数获得锁之后，内层递归函数仍然可以获取到该锁。 就是同一个线程再次进入同样代码时，可以再次拿到该锁。
可重入锁作用？
防止在同一线程中多次获取锁而导致死锁发生。
注：在java的编程中synchronized 和 ReentrantLock都是可重入锁。
基于synchronized的可重入锁
步骤1：双重加锁逻辑
public class SynchronizedDemo {
//模拟库存100
int count=100;
public synchronized void operation(){
log.info("第一层锁:减库存");
//模拟减库存
count--;
add();
log.info("下订单结束库存剩余:{}",count);
}
private synchronized void add(){
log.info("第二层锁：插入订单");
try {
Thread.sleep(1000*10);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}步骤2：加个测试类
public static void main(String[] args) {
SynchronizedDemo synchronizedDemo=new SynchronizedDemo();
for (int i = 0; i < 3; i++) {
int finalI = i;
new Thread(()->{
log.info("-------用户{}开始下单--------", finalI);
synchronizedDemo.operation();
}).start();
}
}步骤3：测试
20:44:04.013 [Thread-2] INFO com.agan.redis.controller.SynchronizedController - -------用户2开始下单-------- 20:44:04.013 [Thread-1] INFO com.agan.redis.controller.SynchronizedController - -------用户1开始下单-------- 20:44:04.013 [Thread-0] INFO com.agan.redis.controller.SynchronizedController - -------用户0开始下单-------- 20:44:04.016 [Thread-2] INFO com.agan.redis.Reentrant.SynchronizedDemo - 第一层锁:减库存 20:44:04.016 [Thread-2] INFO com.agan.redis.Reentrant.SynchronizedDemo - 第二层锁：插入订单 20:44:14.017 [Thread-2] INFO com.agan.redis.Reentrant.SynchronizedDemo - 下订单结束库存剩余:99 20:44:14.017 [Thread-0] INFO com.agan.redis.Reentrant.SynchronizedDemo - 第一层锁:减库存 20:44:14.017 [Thread-0] INFO com.agan.redis.Reentrant.SynchronizedDemo - 第二层锁：插入订单 20:44:24.017 [Thread-0] INFO com.agan.redis.Reentrant.SynchronizedDemo - 下订单结束库存剩余:98 20:44:24.017 [Thread-1] INFO com.agan.redis.Reentrant.SynchronizedDemo - 第一层锁:减库存 20:44:24.017 [Thread-1] INFO com.agan.redis.Reentrant.SynchronizedDemo - 第二层锁：插入订单 20:44:34.017 [Thread-1] INFO com.agan.redis.Reentrant.SynchronizedDemo - 下订单结束库存剩余:97
由于synchronized关键字修饰的是方法，所有加锁为实例对象：synchronizedDemo
运行结果可以看出减库存和插入订单都是每个线程都完整运行两个方法完毕，才能释放锁，其他线程才能拿锁，即是一个线程多次可以拿到同一个锁，可重入。所以synchronized也是可重入锁。
基于ReentrantLock的可重入锁
ReentrantLock，是一个可重入且独占式的锁，是一种递归无阻塞的同步锁。和synchronized关键字相比，它更灵活、更强大，增加了轮询、超时、中断等高级功能。
步骤1：双重加锁逻辑
public class ReentrantLockDemo {
private Lock lock = new ReentrantLock();
public void doSomething(int n){
try{
//进入递归第一件事：加锁
lock.lock();
log.info("--------递归{}次--------",n);
if(n<=2){
try {
Thread.sleep(1000*2);
} catch (InterruptedException e) {
e.printStackTrace();
}
this.doSomething(++n);
}else{
return;
}
}finally {
lock.unlock();
}
}
}步骤2：加个测试类
public static void main(String[] args) {
ReentrantLockDemo reentrantLockDemo=new ReentrantLockDemo();
for (int i = 0; i < 3; i++) {
int finalI = i;
new Thread(()->{
log.info("-------用户{}开始下单--------", finalI);
reentrantLockDemo.doSomething(1);
}).start();
}
}步骤3：测试
20:55:23.533 [Thread-1] INFO com.agan.redis.controller.ReentrantController - -------用户1开始下单-------- 20:55:23.533 [Thread-2] INFO com.agan.redis.controller.ReentrantController - -------用户2开始下单-------- 20:55:23.533 [Thread-0] INFO com.agan.redis.controller.ReentrantController - -------用户0开始下单-------- 20:55:23.536 [Thread-1] INFO com.agan.redis.Reentrant.ReentrantLockDemo - --------递归1次-------- 20:55:25.537 [Thread-1] INFO com.agan.redis.Reentrant.ReentrantLockDemo - --------递归2次-------- 20:55:27.538 [Thread-1] INFO com.agan.redis.Reentrant.ReentrantLockDemo - --------递归3次-------- 20:55:27.538 [Thread-2] INFO com.agan.redis.Reentrant.ReentrantLockDemo - --------递归1次-------- 20:55:29.538 [Thread-2] INFO com.agan.redis.Reentrant.ReentrantLockDemo - --------递归2次-------- 20:55:31.539 [Thread-2] INFO com.agan.redis.Reentrant.ReentrantLockDemo - --------递归3次-------- 20:55:31.539 [Thread-0] INFO com.agan.redis.Reentrant.ReentrantLockDemo - --------递归1次-------- 20:55:33.539 [Thread-0] INFO com.agan.redis.Reentrant.ReentrantLockDemo - --------递归2次-------- 20:55:35.540 [Thread-0] INFO com.agan.redis.Reentrant.ReentrantLockDemo - --------递归3次--------
运行结果可以看出，每个线程都可以多次加锁解锁的，ReentrantLock是可重入的。
redis如何实现分布式重入锁？
setnx虽然可以实现分布式锁，但是不可重入，在一些复杂的业务场景，我们需要分布式重入锁时,
对于redis的重入锁业界还是有很多解决方案的，目前最流行的就是采用Redisson。【相关推荐：Redis视频教程】
什么是Redisson？
Redisson是Redis官方推荐的Java版的Redis客户端。
基于Java实用工具包中常用接口，为使用者提供了一系列具有分布式特性的常用工具类。
在网络通信上是基于NIO的Netty框架，保证网络通信的高性能。
在分布式锁的功能上，它提供了一系列的分布式锁；如：
可重入锁（Reentrant Lock）
公平锁（Fair Lock）
非公平锁（unFair Lock）
读写锁（ReadWriteLock）
联锁（MultiLock）
红锁（RedLock）
案例实战：体验redis分布式重入锁
步骤1:Redisson配置
Redisson配置的可以查考：redis分布式缓存（三十四）一一 SpringBoot整合Redission - 掘金 (juejin.cn)
https://juejin.cn/post/7057132897819426824
步骤2:Redisson重入锁测试类
public class RedisController {
@Autowired
RedissonClient redissonClient;
@GetMapping(value = "/lock")
public void get(String key) throws InterruptedException {
this.getLock(key, 1);
}
private void getLock(String key, int n) throws InterruptedException {
//模拟递归，3次递归后退出
if (n > 3) {
return;
}
//步骤1：获取一个分布式可重入锁RLock
//分布式可重入锁RLock :实现了java.util.concurrent.locks.Lock接口，同时还支持自动过期解锁。
RLock lock = redissonClient.getLock(key);
//步骤2：尝试拿锁
// 1. 默认的拿锁
//lock.tryLock();
// 2. 支持过期解锁功能,10秒钟以后过期自动解锁, 无需调用unlock方法手动解锁
//lock.tryLock(10, TimeUnit.SECONDS);
// 3. 尝试加锁，最多等待3秒，上锁以后10秒后过期自动解锁
// lock.tryLock(3, 10, TimeUnit.SECONDS);
boolean bs = lock.tryLock(3, 10, TimeUnit.SECONDS);
if (bs) {
try {
// 业务代码
log.info("线程{}业务逻辑处理: {},递归{}" ,Thread.currentThread().getName(), key,n);
//模拟处理业务
Thread.sleep(1000 * 5);
//模拟进入递归
this.getLock(key, ++n);
} catch (Exception e) {
log.error(e.getLocalizedMessage());
} finally {
//步骤3：解锁
lock.unlock();
log.info("线程{}解锁退出",Thread.currentThread().getName());
}
} else {
log.info("线程{}未取得锁",Thread.currentThread().getName());
}
}
}RLock三个加锁动作：
lock.tryLock();
默认的拿锁
lock.tryLock(10, TimeUnit.SECONDS);
支持过期解锁功能,10秒钟以后过期自动解锁
lock.tryLock(3, 10, TimeUnit.SECONDS);
尝试加锁，最多等待3秒，上锁以后10秒后过期自动解锁
区别：
lock.lock()：阻塞式等待。默认加的锁都是30s
锁的自动续期，如果业务超长，运行期间自动锁上新的30s。不用担心业务时间长而导致锁自动过期被删掉（默认续期）
加锁的业务只要运行完成，就不会给当前锁续期，即使不手动解锁，锁默认会在30s内自动过期，不会产生死锁问题
lock()如果我们未指定锁的超时时间，就使用【看门狗默认时间】： lockWatchdogTimeout = 30 * 1000
原理：只要占锁成功，就会启动一个定时任务【重新给锁设置过期时间，新的过期时间就是看门狗的默认时间】,每隔10秒都会自动的再次续期，续成30秒
lock.lock(10,TimeUnit.SECONDS) ：10秒钟自动解锁,自动解锁时间一定要大于业务执行时间
出现的问题：在锁时间到了以后，不会自动续期
原理：lock(10,TimeUnit.SECONDS)如果我们传递了锁的超时时间，就发送给redis执行脚本，进行占锁，默认超时就是我们制定的时间
最佳实战：
lock.lock(10,TimeUnit.SECONDS); 省掉看门狗续期操作，自动解锁时间一定要大于业务执行时间，手动解锁
步骤3:测试
访问3次：http://127.0.0.1:9090/lock?key=ljw
线程http-nio-9090-exec-1业务逻辑处理: ljw,递归1 线程http-nio-9090-exec-2未取得锁 线程http-nio-9090-exec-1业务逻辑处理: ljw,递归2 线程http-nio-9090-exec-3未取得锁 线程http-nio-9090-exec-1业务逻辑处理: ljw,递归3 线程http-nio-9090-exec-1解锁退出 线程http-nio-9090-exec-1解锁退出 线程http-nio-9090-exec-1解锁退出
通过测试结果：
nio-9090-exec-1线程，在getLock方法递归了3次,即证明了lock.tryLock是可重入锁
只有当nio-9090-exec-1线程执行完后，io-9090-exec-2 nio-9090-exec-3 未取得锁 因为lock.tryLock(3, 10, TimeUnit.SECONDS)，尝试加锁，最多等待3秒，上锁以后10秒后过期自动解锁 所以等了3秒都等不到，就放弃了
在Docker环境下为PHP安装Redis扩展：手动编译需下载源码、安装phpize、配置编译并安装，生成redis.so并在php.d目录新建redis.ini加载，重启PHP-FPM；也可直接yum安装php72w-pecl-redis，免手动编译。
配置PHP的Redis扩展：先安装Redis服务，从GitHub下载phpredis源码，用phpize编译安装，修改php.ini添加extension=redis.so，重启php-fpm或Apache，通过phpinfo验证并连接Redis。
C++结构体无法直接序列化为RESP协议，需手动将字段映射为*N数组嵌套$lenbulkstring形式。整数需转换为字符串并加:前缀，空字符串用$0\r\n，null用$-1\r\n。长度计算需精确到字节数，特别注意二进制安全，同时确保字段顺序与结构体定义一致。
Redis作为跨服务临时状态枢纽，需按消息队列、缓存和原子状态三重角色设计。选型用List实现任务分发及延迟重试，Stream用于事件广播与位点回溯。go-redis/v8需配置MinIdleConns、MaxRetries及超时。数据写入应JSON序列化并带type标签、设合理TTL、将关键字段提至顶层。消费通过原子GET+DEL或processedkey
在高并发秒杀场景下，利用Redis的减库存原子操作预扣减库存拦截超卖请求，再通过数据库乐观锁（版本号与库存校验）确保最终一致性，异常时回滚Redis库存并借助Lua脚本保证原子性，从而有效防止库存超卖。
在Go中使用go-redis执行Lua脚本可借助原子性解决竞态问题，通过redis.Script封装脚本并自动处理SHA1缓存与重试。需注意KEYS必须为非空切片且所有键在Cluster模式下落在同一slot，ARGV以字符串传入并由tonumber转换。返回值需先检查错误再调用Val()，避免panic。
先看一个典型场景：电商秒杀、库存扣减、定时任务重复调度——这些并发冲突在 TP6 应用里屡见不鲜。用 Redis 的 SETNX 做互斥锁，确实是轻量又直接的方案，但“能用”和“稳妥”之间，隔着三层硬功夫：原子加锁、身份校验、合理超时。这三条，差一条就翻车。 很多人第一次上手，直接写 SETNX 加
高并发抢购中，Redis的DECR原子操作可安全扣库存；配合think-queue异步削峰，接口仅扣库存和推消息；分布式锁需用SETNXEX加唯一标识，释放时用Lua脚本校验；成功资格后须以数据库事务双写为准，失败时补回Redis库存。
基于Redis的ZSET实现延时队列需解决并发重复消费、失败重试混乱、精度不足及内存爆炸等问题。通过Lua脚本保证取删原子性，使用毫秒级时间戳，对临时错误采用指数退避重试，永久错误记入独立哈希表，并限制最大延迟、定期清理过期任务、使用紧凑序列化格式。
操作 Redis 的时候，改个 Key 的过期时间其实是个高频场景。特别是做运维排查或者临时调试那会儿，谁也不想反复切命令行窗口、背那些命令参数。好在 RedisInsight 这个图形工具把这事儿做得很顺手——三种方式任选，总有一种合你胃口。 在动手前，先确认一下 Key 当前的 TTL 状态是个
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
