Redis分布式锁：从原理到实现，一篇搞懂

原创已于 2025-07-29 09:58:45 修改 · 2.9k 阅读

28 ·

CC 4.0 BY-SA版权

文章标签：

#缓存 #redis #java #后端

于 2025-07-29 09:47:47 首次发布

Redis分布式锁：从原理到实现，一篇搞懂

在分布式系统中，当多个服务实例需要操作共享资源（比如库存、订单ID）时，“并发”就可能变成“灾难”——比如秒杀场景下的超卖、分布式任务调度中的重复执行。这时候，我们需要一种跨服务、跨实例的“互斥机制”，这就是分布式锁。

而Redis凭借其高性能、高可用的特性，成为实现分布式锁的主流方案之一。今天我们就从“为什么需要分布式锁”讲起，一步步拆解Redis分布式锁的实现原理、核心问题与解决方案。

一、先搞懂：什么是分布式锁？为什么需要它？

在单机系统中，我们可以用synchronized（Java）或Lock接口实现“本地锁”，保证同一JVM内的线程互斥。但在分布式系统中，服务通常部署在多个节点（多台服务器），本地锁只能控制单个节点内的线程，无法阻止其他节点的线程操作共享资源——这时候就需要分布式锁：

定义：分布式锁是一种跨节点、跨服务的互斥机制，用于保证多个服务实例对共享资源的“串行操作”。
核心要求：要实现一个可靠的分布式锁，必须满足以下特性：
- 互斥性：同一时间只能有一个服务实例获取到锁；
- 安全性：锁只能被持有锁的实例释放，不能被其他实例释放；
- 防死锁：即使持有锁的实例崩溃，锁也能自动释放（避免资源永久不可用）；
- 可用性：获取/释放锁的操作要高效，避免成为性能瓶颈；
- 容错性：Redis节点宕机时，锁机制仍能正常工作（或有限降级）。

二、Redis分布式锁的核心原理：用SET命令实现“互斥”

Redis实现分布式锁的核心思路很简单：用一个Redis键作为“锁标识”，通过“只有一个客户端能成功设置该键”的特性实现互斥。

具体来说，就是：当一个客户端需要获取锁时，就向Redis设置一个“锁键”；释放锁时，就删除这个“锁键”。其他客户端只有在“锁键不存在”时，才能获取到锁。

1. 最基础的实现：用SET命令的“隐藏技能”

Redis的SET命令有两个关键参数，是实现分布式锁的核心：

NX：全称“Not Exist”，只有当键不存在时，才能设置成功（如果键已存在，设置失败）；
PX：设置键的过期时间（单位：毫秒），避免锁被永久占用。

结合这两个参数，我们可以用一条命令实现“获取锁”：

# 向Redis设置键“lock:stock”，值为“client1”（客户端标识），
# NX：只有键不存在时才设置；PX 30000：设置30秒过期时间
SET lock:stock client1 NX PX 30000

如果返回OK：表示客户端成功获取到锁；
如果返回nil：表示锁已被其他客户端持有，获取失败。

2. 为什么这两个参数缺一不可？

上面的SET命令看起来简单，但每个参数都在解决关键问题：

NX参数：保证“互斥性”。只有当锁键不存在时（即没有其他客户端持有锁），当前客户端才能获取到锁；
PX参数：解决“死锁问题”。如果持有锁的客户端崩溃（比如机器断电），没有主动释放锁，Redis会在过期时间后自动删除锁键，其他客户端可以重新获取锁；
客户端标识（值）：保证“安全性”。释放锁时，客户端需要先判断“当前锁的持有者是不是自己”，避免误删其他客户端的锁（比如自己的锁过期后，其他客户端已获取到新锁，此时不能删除新锁）。

三、关键问题：获取锁后，这些坑必须避

用SET NX PX能实现最基础的分布式锁，但在实际场景中，还有几个核心问题需要解决。

问题1：锁过期了，任务还没执行完怎么办？

假设我们设置锁过期时间为30秒，但任务执行需要40秒——30秒后锁被Redis自动释放，其他客户端会获取到锁，导致“两个客户端同时操作共享资源”。

这是Redis分布式锁最常见的问题，解决方案是锁续命：让持有锁的客户端，在锁过期前“延长锁的有效期”。

具体实现思路：

客户端获取锁后，启动一个“守护线程”（或定时任务）；
守护线程每隔一段时间（比如过期时间的1/3，即10秒）检查：如果当前客户端仍持有锁（锁键存在且值是自己的标识），就延长锁的过期时间（比如再续30秒）；
当任务执行完成，客户端主动释放锁时，同时停止守护线程。

这种“续命”机制在成熟的Redis客户端中已经封装，比如Redisson的“看门狗（Watch Dog）”机制。

问题2：释放锁时，如何保证操作的原子性？

释放锁不能直接用DEL命令——假设客户端A的锁即将过期，在它执行DEL前，锁刚好过期，客户端B已经获取到新锁。此时A执行DEL会误删B的锁。

正确的释放流程应该是“先判断、再删除”，且这两个操作必须“原子执行”（不能被其他操作打断）：

判断当前锁的持有者是不是自己（即锁键的值是否等于自己的客户端标识）；
如果是，就删除锁键；如果不是，就不做操作。

Redis中可以用Lua脚本保证这两个步骤的原子性（Redis会将Lua脚本作为一个整体执行，中间不会被其他命令打断）。

释放锁的Lua脚本示例：

-- 脚本参数：KEYS[1]是锁键，ARGV[1]是客户端标识
if redis.call("GET", KEYS[1]) == ARGV[1] then
    -- 如果锁是自己的，就删除
    return redis.call("DEL", KEYS[1])
else
    -- 不是自己的锁，不操作
    return 0
end

调用时，通过Redis客户端执行该脚本（以Java的Jedis为例）：

// 锁键
String lockKey = "lock:stock";
// 客户端标识（可以用UUID生成）
String clientId = UUID.randomUUID().toString();
// 执行Lua脚本
String script = "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end";
Long result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(clientId));
if (result == 1) {
    // 释放锁成功
} else {
    // 释放锁失败（锁已过期或被其他客户端持有）
}

问题3：Redis集群下，锁会“丢”吗？

在Redis主从集群中，数据是异步复制的（主节点接收命令后返回，再异步同步到从节点）。如果主节点在设置锁后、同步到从节点前宕机，从节点升级为主节点后，“新主节点”中没有该锁的记录——此时其他客户端可以重新获取锁，导致“锁丢失”。

这种场景下，基础的Redis分布式锁无法保证“绝对安全”。解决方案有两种：

方案1：接受风险，优化集群可用性。主从切换的概率本身较低，且大部分业务（如非金融场景的库存）可以接受“极低概率的锁丢失”，此时可以通过Redis哨兵（Sentinel）快速切换主节点，降低锁丢失的影响；
方案2：使用Redlock算法。这是Redis作者提出的“分布式锁增强方案”：需要多个独立的Redis节点（至少3个），客户端需要向多数节点（比如3个中的2个）成功设置锁，才认为获取锁成功。即使部分节点宕机，只要多数节点正常，锁仍能生效。但Redlock实现复杂，性能也会下降（需要操作多个节点），适合对“锁安全性”要求极高的场景。

四、实战：Redis分布式锁的完整实现流程

结合上面的原理，我们可以整理出Redis分布式锁的“标准流程”，包括获取锁、执行任务、释放锁三个阶段。

1. 获取锁

/**
 * 获取Redis分布式锁
 * @param jedis Redis客户端
 * @param lockKey 锁键
 * @param clientId 客户端标识（UUID）
 * @param expireTime 过期时间（毫秒）
 * @return 是否获取成功
 */
public static boolean tryLock(Jedis jedis, String lockKey, String clientId, long expireTime) {
    // 用SET NX PX命令获取锁
    String result = jedis.set(lockKey, clientId, "NX", "PX", expireTime);
    // 返回OK表示获取成功
    return "OK".equals(result);
}

2. 启动“锁续命”线程

/**
 * 启动锁续命线程
 * @param jedis Redis客户端
 * @param lockKey 锁键
 * @param clientId 客户端标识
 * @param expireTime 过期时间（毫秒）
 * @return 用于停止线程的标识
 */
public static ScheduledFuture<?> startRenewThread(Jedis jedis, String lockKey, String clientId, long expireTime) {
    ScheduledExecutorService executor = Executors.newScheduledThreadPool(1);
    // 每隔expireTime/3时间执行一次续命（比如30秒过期，每10秒续命一次）
    ScheduledFuture<?> future = executor.scheduleAtFixedRate(() -> {
        // 用Lua脚本判断是否持有锁，是则续命
        String script = "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('PEXPIRE', KEYS[1], ARGV[2]) else return 0 end";
        Long result = jedis.eval(script, Collections.singletonList(lockKey), 
                                 Arrays.asList(clientId, String.valueOf(expireTime)));
        if (result != 1) {
            // 续命失败（锁已释放或过期），停止线程
            executor.shutdown();
        }
    }, 0, expireTime / 3, TimeUnit.MILLISECONDS);
    return future;
}

3. 释放锁

/**
 * 释放Redis分布式锁
 * @param jedis Redis客户端
 * @param lockKey 锁键
 * @param clientId 客户端标识
 * @param renewFuture 续命线程的Future（用于停止线程）
 * @return 是否释放成功
 */
public static boolean releaseLock(Jedis jedis, String lockKey, String clientId, ScheduledFuture<?> renewFuture) {
    // 先停止续命线程
    if (renewFuture != null && !renewFuture.isCancelled()) {
        renewFuture.cancel(true);
    }
    // 用Lua脚本释放锁（判断+删除原子操作）
    String script = "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end";
    Long result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(clientId));
    return result == 1;
}

4. 完整使用示例

public class RedisLockExample {
    public static void main(String[] args) {
        // 初始化Redis客户端（实际中建议用连接池）
        Jedis jedis = new Jedis("localhost", 6379);
        String lockKey = "lock:stock";
        String clientId = UUID.randomUUID().toString();
        long expireTime = 30000; // 30秒过期
        
        try {
            // 1. 获取锁
            boolean locked = tryLock(jedis, lockKey, clientId, expireTime);
            if (!locked) {
                System.out.println("获取锁失败，退出");
                return;
            }
            System.out.println("获取锁成功，开始执行任务");
            
            // 2. 启动锁续命线程
            ScheduledFuture<?> renewFuture = startRenewThread(jedis, lockKey, clientId, expireTime);
            
            // 3. 执行核心任务（比如扣减库存）
            executeTask();
            
        } finally {
            // 4. 释放锁（无论任务是否成功，都要尝试释放）
            releaseLock(jedis, lockKey, clientId, renewFuture);
            System.out.println("释放锁完成");
            jedis.close();
        }
    }
    
    // 模拟核心任务（比如耗时20秒）
    private static void executeTask() {
        try {
            Thread.sleep(20000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

3. 生产环境推荐：用Redisson简化实现 Redis分布式锁深度解析：从原生实现到Redisson进阶

上面的代码是“原生实现”，用于理解原理。实际生产中，推荐使用成熟的客户端框架Redisson——它已经封装了所有细节：

自动实现“锁续命”（看门狗机制）；
支持公平锁、可重入锁（同一客户端可重复获取锁）；
内置Lua脚本保证释放锁的原子性；
支持Redis集群、哨兵模式，降低锁丢失风险。

Redisson使用示例（Java）：

// 初始化Redisson客户端
Config config = new Config();
config.useSingleServer().setAddress("redis://localhost:6379");
RedissonClient redisson = Redisson.create(config);

// 获取分布式锁（可重入锁）
RLock lock = redisson.getLock("lock:stock");
try {
    // 尝试获取锁，最多等待10秒，10秒后还没获取到则失败；锁自动过期时间30秒
    boolean locked = lock.tryLock(10, 30, TimeUnit.SECONDS);
    if (locked) {
        // 执行任务
        executeTask();
    }
} catch (InterruptedException e) {
    e.printStackTrace();
} finally {
    // 释放锁（只有持有锁时才释放）
    if (lock.isHeldByCurrentThread()) {
        lock.unlock();
    }
}
// 关闭客户端
redisson.shutdown();

五、总结：Redis分布式锁的适用场景与局限性

Redis分布式锁凭借“高性能、易实现”的优势，成为中小规模分布式系统的首选方案，但它并非“银弹”，需要结合业务场景选择：

适用场景：

高并发场景（如秒杀、限流），需要快速获取/释放锁；
对“锁安全性”要求中等（允许极低概率的锁丢失，如非金融场景）；
共享资源操作耗时较短（任务执行时间可控，避免锁续命逻辑复杂）。

局限性：

无法完全解决Redis集群主从切换导致的“锁丢失”（除非用Redlock，但实现复杂）；
锁过期时间设置需要经验（过短可能频繁续命，过长可能降低可用性）；
不适合“长任务”场景（任务执行时间远大于锁过期时间，续命逻辑压力大）。

最后记住：分布式锁的核心是“平衡安全性与可用性”。大部分场景下，用Redisson + Redis主从哨兵的方案，已经能满足需求；如果是金融级场景（如转账），可能需要更严格的分布式锁方案（如ZooKeeper分布式锁）。

希望这篇文章能帮你真正理解Redis分布式锁——不仅知道“怎么用”，更知道“为什么这么用”。