Redis 分布式锁：从 SETNX 到 Redisson 的坑

归档6

Java4 AI1 Minecraft1

470 字

2 分钟

Redis 分布式锁：从 SETNX 到 Redisson 的坑

2026-08-15

分布式锁看上去只是「加锁、解锁」两步，实际上一个坑接一个坑。

第一版：SETNX#

1
Boolean ok = redis.opsForValue().setIfAbsent("lock:order:1001", "1");
2
if (Boolean.TRUE.equals(ok)) {
3
    try {
4
        // 业务逻辑
5
    } finally {
6
        redis.delete("lock:order:1001");
7
    }
8
}

问题：如果进程在持有锁时崩溃，锁永远不会被释放。

第二版：加上过期时间#

必须把「加锁」和「设置过期」做成一个原子操作：

1
Boolean ok = redis.opsForValue()
2
    .setIfAbsent("lock:order:1001", token, Duration.ofSeconds(30));

不要先 SETNX 再 EXPIRE，两步之间崩溃就又回到了死锁。

第三版：防止误删#

假如业务执行超过 30 秒，锁已经过期并被别人拿走，此时你的 delete 会把别人的锁删掉。

做法：加锁时写入唯一标识（token），解锁时先比较再删除，并且这两步要用 Lua 脚本保证原子性：

1
if redis.call("get", KEYS[1]) == ARGV[1] then
2
    return redis.call("del", KEYS[1])
3
else
4
    return 0
5
end

第四版：续期#

业务耗时不确定时，固定的过期时间要么太短要么太长。解决方案是「看门狗」：持有锁期间，后台线程定时延长过期时间。

自己实现很容易出错，推荐直接使用 Redisson：

1
RLock lock = redissonClient.getLock("lock:order:1001");
2
lock.lock(); // 默认开启看门狗，自动续期
3
try {
4
    // 业务逻辑
5
} finally {
6
    lock.unlock();
7
}

还要考虑什么#

主从切换：主节点宕机、锁尚未同步到从节点时，可能出现两个客户端同时持锁。对一致性要求极高的场景，不要只依赖 Redis，考虑数据库唯一约束或 ZooKeeper 等方案。
业务幂等：锁只是减少并发冲突，不应该是唯一的正确性保证。关键操作务必做幂等设计。
锁粒度：锁越细越好，避免把整个服务串行化。