当前位置：首页 > news >正文

【黑马点评】Redis分布式锁实战：从Lua脚本到Java实现

news 2026/5/23 17:02:02

1. Redis分布式锁的核心价值与应用场景

在分布式系统中，多个服务实例同时操作共享资源时，会出现并发问题。比如电商平台的秒杀活动中，如果不对库存操作加锁，就可能出现超卖现象。传统单机版的synchronized或ReentrantLock在这样的场景下完全失效，因为它们只能控制单个JVM内的线程同步。

Redis分布式锁之所以成为主流解决方案，主要得益于三个特性：互斥性（通过SETNX实现）、自动过期（避免死锁）和高性能（内存操作）。我在实际项目中遇到过这样的案例：某金融系统在交易日高峰期，由于没有正确实现分布式锁，导致用户余额被重复扣减。后来引入Redis分布式锁后，不仅解决了并发问题，系统吞吐量还保持在每秒2万次以上。

与ZooKeeper等方案相比，Redis锁的实现更轻量，适合对性能要求高的场景。不过要注意，Redis集群在某些极端情况下（如主从切换）可能出现锁失效，这就需要我们后面要讨论的Redisson解决方案了。

2. 基础实现与隐藏的陷阱

2.1 最简版锁的实现

先看一个基础版的Java实现：

public class SimpleRedisLock implements ILock { private StringRedisTemplate stringRedisTemplate; private String lockKey; public boolean tryLock(long timeoutSec) { return stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, "1", timeoutSec, TimeUnit.SECONDS); } public void unlock() { stringRedisTemplate.delete(lockKey); } }

这个实现虽然简单，但藏着三个致命问题：

误删锁：线程A执行时间过长导致锁自动释放，线程B获得锁后，线程A又执行到delete操作
非原子性操作：判断锁归属和删除锁不是原子操作
不可重入：同一个线程无法重复获取已持有的锁

2.2 线程标识解决方案

解决误删问题的关键在于给锁添加"指纹"。我们改进后的方案：

private String getThreadIdentifier() { return UUID.randomUUID() + "-" + Thread.currentThread().getId(); } public boolean tryLock(long timeoutSec) { String threadId = getThreadIdentifier(); return stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, threadId, timeoutSec, TimeUnit.SECONDS); } public void unlock() { String threadId = getThreadIdentifier(); String lockValue = stringRedisTemplate.opsForValue().get(lockKey); if(threadId.equals(lockValue)) { stringRedisTemplate.delete(lockKey); } }

这个方案仍然存在原子性问题：当线程在执行get和delete之间时，锁可能刚好过期。我在压力测试时就遇到过这种情况，2000并发下会出现约0.1%的锁冲突。

3. Lua脚本的原子性魔法

3.1 为什么需要Lua脚本

Redis执行Lua脚本时，会把整个脚本作为一个命令执行，天然具备原子性。这完美解决了我们前面提到的判断+删除的原子性问题。

先看一个释放锁的Lua脚本示例：

-- KEYS[1] 锁key -- ARGV[1] 线程标识 if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end

这个脚本的意思是：只有当锁的值与传入的线程标识匹配时，才执行删除操作。整个过程在Redis内部一次性完成，不存在并发干扰。

3.2 Java中调用Lua脚本

Spring的RedisTemplate提供了完善的Lua支持：

public class LuaRedisLock implements ILock { private static final DefaultRedisScript<Long> UNLOCK_SCRIPT; static { UNLOCK_SCRIPT = new DefaultRedisScript<>(); UNLOCK_SCRIPT.setLocation(new ClassPathResource("unlock.lua")); UNLOCK_SCRIPT.setResultType(Long.class); } public void unlock() { stringRedisTemplate.execute( UNLOCK_SCRIPT, Collections.singletonList(lockKey), getThreadIdentifier()); } }

在实际项目中，我建议把Lua脚本放在resources目录下，而不是硬编码在Java代码中。这样既方便维护，又能利用IDE的语法高亮功能。

4. 生产环境中的最佳实践

4.1 锁参数优化建议

根据不同的业务场景，需要调整以下参数：

过期时间：建议设置为业务平均执行时间的2-3倍。比如下单业务平均耗时200ms，可以设置500ms过期
重试策略：采用指数退避算法，初始等待100ms，最大等待1s
锁前缀：建议使用"serviceName:lockType:"格式，如"order:create:"

4.2 监控与告警

分布式锁需要配套的监控措施：

锁等待时间监控：超过阈值报警，可能预示性能问题
锁持有时间监控：长时间持有锁可能业务阻塞
死锁检测：通过Redis的SCAN命令定期检查过期锁

4.3 常见问题排查指南

问题1：获取锁成功率突然下降

检查Redis集群状态
检查网络延迟
分析业务是否变慢导致锁持有时间变长

问题2：出现锁冲突但业务量没增加

可能是锁过期时间设置不合理
检查是否有线程泄漏导致锁未释放

我在电商项目中就遇到过第二种情况，最终发现是某处异常处理逻辑漏掉了unlock操作。通过添加try-finally块解决了问题。

5. 从黑马点评案例看实战应用

回到黑马点评的优惠券秒杀场景，完整的分布式锁应用流程应该是：

查询优惠券信息：先获取基础数据
获取用户锁：以用户ID为粒度加锁
创建订单：在锁保护下执行核心业务
释放锁：无论成功失败都要确保锁释放

关键代码改进点：

public Result seckillVoucher(Long voucherId) { // ...前置校验逻辑 SimpleRedisLock lock = new SimpleRedisLock("order:"+userId, stringRedisTemplate); try { if (!lock.tryLock(500, TimeUnit.MILLISECONDS)) { return Result.fail("操作太频繁，请稍后再试"); } // 核心业务逻辑 return createVoucherOrder(voucherId); } finally { lock.unlock(); } }

这个实现虽然解决了基本的并发问题，但在生产环境中还需要考虑：

锁自动续期（后面会讲Redisson的看门狗机制）
可重入锁支持
锁等待队列优化

6. 性能优化与高级特性

6.1 分段锁提升并发度

对于热点资源如秒杀商品，可以采用分段锁策略。例如将库存分为10段，每段独立加锁。这样可以将并发度提升N倍（N为分段数）。

实现示例：

public class SegmentLock { private final List<String> lockKeys; public SegmentLock(String baseKey, int segments) { lockKeys = IntStream.range(0, segments) .mapToObj(i -> baseKey + ":" + i) .collect(Collectors.toList()); } public boolean tryLockAll(long timeout, TimeUnit unit) { // 尝试获取所有分段锁 } }