Redis分布式锁实现原理与最佳实践

1. Redis分布式锁的必要性

在分布式系统中，我们经常会遇到需要协调多个服务实例对共享资源进行访问的场景。比如电商平台的库存扣减、秒杀活动中的商品抢购、分布式任务调度等。这些场景下，传统的单机锁机制（如Java中的synchronized关键字或ReentrantLock）就显得力不从心了。

1.1 本地锁的局限性

本地锁只能保证在单个JVM进程内的线程安全。举个例子：

• 单机部署时：使用synchronized修饰库存扣减方法，可以确保同一时刻只有一个线程修改库存
• 集群部署时：每个服务实例都有自己的JVM，本地锁无法跨实例生效，会出现多个线程同时修改库存的情况

这种场景下就会产生两个典型问题：

1. 超卖问题：库存被扣减到负数
2. 数据不一致：同一商品被重复扣减

1.2 分布式锁的核心目标

分布式锁需要实现的核心功能是：在分布式环境下，确保同一时刻只有一个线程能够执行临界区代码。这需要解决以下几个关键问题：

1. 互斥性：任何时候只能有一个客户端持有锁
2. 避免死锁：即使持有锁的客户端崩溃，锁也能自动释放
3. 容错性：大部分Redis节点正常时，客户端就能获取和释放锁
4. 可重入性：同一个客户端可以多次获取同一个锁

2. 基础实现：基于SETNX命令

2.1 SETNX命令解析

Redis的SETNX（SET if Not eXists）命令是实现分布式锁的基础：

bash复制SETNX key value

• 当key不存在时，设置key的值为value，返回1
• 当key已存在时，不做任何操作，返回0

这个命令的原子性特性非常适合用来实现分布式锁。

2.2 基础版Java实现

我们先来看一个基于Jedis的基础实现：

java复制public class SimpleRedisLock {
    private final JedisPool jedisPool;
    private static final String LOCK_PREFIX = "lock:";
    private static final int DEFAULT_EXPIRE_SECONDS = 10;

    public boolean lock(String lockKey) {
        try (Jedis jedis = jedisPool.getResource()) {
            Long result = jedis.setnx(LOCK_PREFIX + lockKey, "1");
            if (result == 1) {
                jedis.expire(LOCK_PREFIX + lockKey, DEFAULT_EXPIRE_SECONDS);
                return true;
            }
            return false;
        }
    }

    public void unlock(String lockKey) {
        try (Jedis jedis = jedisPool.getResource()) {
            jedis.del(LOCK_PREFIX + lockKey);
        }
    }
}

2.3 基础实现的问题

这个看似简单的实现实际上存在几个严重问题：

1. 死锁风险：setnx和expire是两个独立命令，如果在执行setnx后程序崩溃，expire未执行，锁将永远不会释放
2. 误删锁：如果线程A执行时间超过锁过期时间，锁自动释放后线程B获取锁，线程A执行完后会误删线程B的锁
3. 非原子操作：检查和删除操作不是原子的，可能导致竞态条件
4. 不可重入：同一个线程无法重复获取同一个锁

3. 进阶优化方案

3.1 原子性设置锁和过期时间

Redis 2.6.12版本后，SET命令支持了NX和EX选项，可以原子性地实现SETNX和EXPIRE：

java复制public boolean lock(String lockKey) {
    try (Jedis jedis = jedisPool.getResource()) {
        String result = jedis.set(LOCK_PREFIX + lockKey, "1", "NX", "EX", DEFAULT_EXPIRE_SECONDS);
        return "OK".equals(result);
    }
}

3.2 防止误删锁

为每个锁设置唯一值，释放时先检查值是否匹配：

java复制private String lockValue = UUID.randomUUID().toString();

public boolean unlock(String lockKey) {
    String luaScript = "if redis.call('get', KEYS[1]) == ARGV[1] then " +
            "return redis.call('del', KEYS[1]) " +
            "else " +
            "return 0 " +
            "end";
    try (Jedis jedis = jedisPool.getResource()) {
        Object result = jedis.eval(luaScript, 1, LOCK_PREFIX + lockKey, lockValue);
        return "1".equals(result.toString());
    }
}

3.3 看门狗机制

对于执行时间不确定的业务，需要实现锁的自动续期：

java复制public void watchDog(String lockKey, long delay) {
    new Thread(() -> {
        while (true) {
            try {
                Thread.sleep(delay * 1000);
                try (Jedis jedis = jedisPool.getResource()) {
                    String currentValue = jedis.get(LOCK_PREFIX + lockKey);
                    if (lockValue.equals(currentValue)) {
                        jedis.expire(LOCK_PREFIX + lockKey, DEFAULT_EXPIRE_SECONDS);
                    } else {
                        break;
                    }
                }
            } catch (InterruptedException e) {
                break;
            }
        }
    }).start();
}

4. Redisson最佳实践

4.1 Redisson简介

Redisson是Redis官方推荐的Java客户端，提供了丰富的分布式对象和服务，其中就包括完善的分布式锁实现。

4.2 Redisson分布式锁特性

1. 可重入锁：同一个线程可以多次获取同一个锁
2. 自动续期：内置看门狗机制，默认30秒过期，每10秒续期一次
3. 多种锁类型：支持公平锁、联锁、红锁等
4. 完善的异常处理：自动处理各种边界情况

4.3 使用示例

java复制@Autowired
private RedissonClient redissonClient;

public void doSomething(String lockKey) {
    RLock lock = redissonClient.getLock(lockKey);
    try {
        // 尝试获取锁，最多等待3秒，锁持有时间10秒
        if (lock.tryLock(3, 10, TimeUnit.SECONDS)) {
            // 执行业务逻辑
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    } finally {
        if (lock.isHeldByCurrentThread()) {
            lock.unlock();
        }
    }
}

4.4 Redisson实现原理

Redisson使用Hash结构存储锁信息：

• Key：锁名称
• Field：客户端ID+线程ID
• Value：重入次数

加锁流程通过Lua脚本保证原子性：

lua复制if (redis.call('exists', KEYS[1]) == 0) then
    redis.call('hincrby', KEYS[1], ARGV[2], 1);
    redis.call('pexpire', KEYS[1], ARGV[1]);
    return nil;
end;
if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then
    redis.call('hincrby', KEYS[1], ARGV[2], 1);
    redis.call('pexpire', KEYS[1], ARGV[1]);
    return nil;
end;
return redis.call('pttl', KEYS[1]);

5. 集群环境下的RedLock算法

5.1 主从架构的问题

在Redis主从架构中，如果主节点在锁信息同步到从节点前宕机，可能导致锁失效。

5.2 RedLock算法原理

RedLock算法要求：

1. 部署多个独立的Redis节点（建议至少5个）
2. 客户端依次向所有节点请求获取锁
3. 当从大多数节点（N/2+1）获取锁成功，且总耗时小于锁过期时间，才认为获取成功
4. 释放锁时需要向所有节点发送释放请求

5.3 Redisson实现

java复制RLock lock1 = redissonClient1.getLock(lockKey);
RLock lock2 = redissonClient2.getLock(lockKey);
RLock lock3 = redissonClient3.getLock(lockKey);

RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);
try {
    if (redLock.tryLock(3, 10, TimeUnit.SECONDS)) {
        // 执行业务逻辑
    }
} finally {
    redLock.unlock();
}

6. 生产环境建议

1. 锁命名：使用业务相关的有意义的锁名称，如"order:123:pay"
2. 超时设置：根据业务特点合理设置锁超时时间
3. 异常处理：确保锁最终能被释放，避免死锁
4. 监控：对锁的获取、释放、等待时间等进行监控
5. 性能考虑：分布式锁会影响系统吞吐量，只在必要时使用

7. 常见问题排查

7.1 锁无法释放

可能原因：

1. 业务执行时间超过锁过期时间
2. 程序异常未执行解锁代码
3. Redis连接问题

解决方案：

1. 合理设置锁超时时间
2. 使用try-finally确保锁释放
3. 实现锁的自动续期机制

7.2 锁竞争激烈

可能原因：

1. 业务高峰期并发量高
2. 锁粒度太粗

解决方案：

1. 优化锁粒度（如按订单ID加锁而非全局锁）
2. 实现排队机制或使用公平锁
3. 考虑其他并发控制方案

7.3 Redis节点故障

可能原因：

1. 主节点宕机
2. 网络分区

解决方案：

1. 使用RedLock算法
2. 部署Redis哨兵或集群
3. 实现降级方案

在实际项目中，我遇到过因为锁超时时间设置不当导致的业务问题。一个批处理任务执行时间不确定，有时会超过锁的默认过期时间，导致多个节点同时执行任务。后来通过Redisson的看门狗机制解决了这个问题，同时也调整了任务拆分策略，将大任务拆分为多个小任务分别加锁执行。