首页 > 数据库 >Redis分布式锁8个高频面试题总结

Redis分布式锁8个高频面试题总结

来源：互联网 2026-07-24 09:09:21

Redis分布式锁通过SETNXEX原子操作加锁、唯一value标识及Lua脚本安全解锁实现。需处理锁过期续期（看门狗）和主从切换丢锁问题，生产推荐Redisson框架。

1. 为什么需要分布式锁？

先从一个经典场景说起——双11秒杀，10000个人抢100个商品。

Redis分布式锁8个高频面试题总结

长期稳定更新的攒劲资源： >>>点此立即查看<<<

单机锁为什么不行？因为秒杀系统通常有10台服务器，每台都有自己的内存，锁只能锁住自己，管不了别的机器。这时候，需要一个所有服务器都能访问的共享锁，Redis分布式锁就是为此而生的。

2. 最简单的分布式锁怎么写？（错误示范）

//  新手最容易写的错误代码
public boolean lock(String key) {
    String result = jedis.setnx(key, "1");  // 尝试加锁
    return result == 1;  // 1表示加锁成功
}
public void unlock(String key) {
    jedis.del(key);  // 删除锁
}

这个写法问题很大。

死锁风险：如果程序在加锁后崩溃了，锁永远都不会释放。
误删别人锁：A的锁超时释放了，B获得锁，结果A醒来之后把B的锁给删了。

3. 怎么设置过期时间？（还是不对）

//  这个也有问题
public boolean lock(String key, int seconds) {
    // 两步操作：1.加锁 2.设置过期时间
    Long result = jedis.setnx(key, "1");
    if (result == 1) {
        jedis.expire(key, seconds);  // 设置过期
        return true;
    }
    return false;
}

问题在于，setnx和expire是两步操作，不是原子的。如果setnx成功，但expire之前程序崩溃了，锁就变成永久的了——这恰恰是刚才提到的死锁问题。

4. 正确写法是怎样的？

//  正确的加锁（一步完成）
public boolean lock(String key, String value, int seconds) {
    // 一条命令完成：加锁+设置过期时间
    String result = jedis.set(key, value, "NX", "EX", seconds);
    return "OK".equals(result);
}

//  安全的解锁
public void unlock(String key, String value) {
    // 用Lua脚本保证原子操作：检查值再删除
    String script = 
        "if redis.call('get', KEYS[1]) == ARGV[1] then " +
        "   return redis.call('del', KEYS[1]) " +
        "else " +
        "   return 0 " +
        "end";
        
    jedis.eval(script, 1, key, value);
}

核心要点有三个：

一条命令搞定：SET key value NX EX seconds，加锁和设置过期时间是原子操作。
value用唯一标识：比如UUID或线程ID，而不是固定值“1”。
原子删除：用Lua脚本先检查value是不是自己的，再删除，避免误删别人的锁。

5. 锁的value为什么不能用“1”？

//  错误：大家value都一样
jedis.set("lock", "1", "NX", "EX", 10);

//  正确：每人一个唯一标识
String myId = UUID.randomUUID().toString();
jedis.set("lock", myId, "NX", "EX", 10);

来看一个实际场景：

线程A：获得锁，value="A123"，超时10秒

线程A：执行了15秒（锁在第10秒已过期）

线程B：获得锁，value="B456"

线程A：终于执行完，要删除锁 → 删了线程B的锁！

用唯一标识就能避免这种情况：删除前检查value是否还是自己的，不是就别动。

6. 业务没执行完，锁过期了怎么办？

方案1：设置合理的过期时间。提前评估业务执行时间，把过期时间设得足够长。

// 评估业务时间，设置更长过期
jedis.set("lock", uuid, "NX", "EX", 30);  // 设置30秒

方案2：自动续期（看门狗模式）。启动一个线程定期检查，业务还没执行完就延长锁的过期时间。

// 启动一个线程，定期续期
new Thread(() -> {
    while (业务没执行完) {
        Thread.sleep(8000);  // 8秒续一次
        
        // 如果是自己的锁，就延长过期时间
        jedis.expire("lock", 10);
    }
}).start();

7. Redis主从切换会丢锁吗？

会！这是Redis分布式锁最大的隐患。

场景还原：

1. 线程A在主节点获得锁

2. 主节点宕机（锁数据还没同步到从节点）

3. 从节点变成新主节点

4. 线程B在新主节点获得“相同”的锁

结果：A和B同时持有了锁！

解决方案有几个：

用RedLock算法：在多个Redis实例上加锁，提高可靠性。
用ZooKeeper：本质上更适合分布式锁场景。
接受风险：在业务层面做幂等处理，让重复执行不影响最终结果。

8. 实际开发用什么？（不要造轮子！）

// 使用Redisson框架（最省心）
RedissonClient redisson = Redisson.create();
RLock lock = redisson.getLock("myLock");
try {
    lock.lock();  // 加锁（自动续期）
    // 执行业务...
} finally {
    lock.unlock();  // 解锁
}

面试对比表

方案	优点	缺点	适用场景
Redis单节点	简单、快	主从切换丢锁	测试环境、不重要的锁
RedLock	相对可靠	实现复杂、性能差	重要的业务锁
Redisson	功能全、自动续期	依赖框架	推荐的生产方案
ZooKeeper	最可靠	性能较差	强一致性的场景