1

2

Redis分布式锁实现方式确实是经典问题，下面我将系统性地分析这个方案及其演进过程，并给出生产级的解决方案。

一、基础方案及其缺陷

1. 初始实现方式

SETNX lock_key unique_value  # 尝试获取锁
EXPIRE lock_key 30           # 设置过期时间

致命缺陷：

• 非原子性操作：如果在SETNX和EXPIRE之间进程崩溃，将导致锁永远无法释放

• 如下图所示的崩溃时间点会导致死锁：

二、原子性解决方案

1. 单命令原子操作（Redis 2.6.12+）

SET lock_key unique_value NX EX 30  # 原子性获取锁并设置过期时间

参数说明：

• NX：仅当key不存在时设置

• EX：设置过期时间（秒）

• PX：设置过期时间（毫秒）

2. 完整Java实现示例

public class RedisDistributedLock {private final JedisPool jedisPool;private final String lockKey;private final int expireTime;public boolean tryLock(String uniqueId) {try (Jedis jedis = jedisPool.getResource()) {String result = jedis.set(lockKey, uniqueId, SetParams.setParams().nx().ex(expireTime));return "OK".equals(result);}}public boolean unlock(String uniqueId) {String script = "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(script, Collections.singletonList(lockKey), Collections.singletonList(uniqueId));return Long.valueOf(1).equals(result);}}
}

三、生产环境关键问题处理

1. 锁续期问题（看门狗机制）

问题场景：业务执行时间超过锁过期时间

Redisson解决方案：

// Redisson自动续期实现
RLock lock = redisson.getLock("lock");
try {lock.lock();  // 默认30秒，看门狗每10秒续期// 业务逻辑
} finally {lock.unlock();
}

2. 集群环境下的锁失效

问题场景：主节点崩溃，锁未同步到从节点

RedLock算法（Redis官方推荐）：

Config config1 = new Config();
config1.useSingleServer().setAddress("redis://node1:6379");
RedissonClient redisson1 = Redisson.create(config1);// 创建多个RLock实例
RLock lock1 = redisson1.getLock("lock");
// ...其他节点// 联锁
RedissonRedLock lock = new RedissonRedLock(lock1, lock2, lock3);
try {lock.lock();// 业务逻辑
} finally {lock.unlock();
}

四、各方案对比分析

方案	优点	缺点	适用场景
SETNX+EXPIRE	简单直接	非原子性，存在死锁风险	已淘汰，不推荐使用
SET NX EX	原子性操作	无自动续期机制	短期锁定简单场景
Redisson普通锁	自动续期，API友好	单节点故障可能失效	单Redis节点环境
Redisson红锁	更高的可用性	性能开销大，实现复杂	高要求的金融级场景
Lua脚本实现	灵活性高	需要自行处理所有边界情况	需要定制化的特殊场景

五、生产环境最佳实践

1. 锁命名规范：

   // 业务:功能:资源 三级命名
   String lockKey = "order:pay:orderId_123456";

2. 超时时间设置：

   • 设置合理的过期时间（通常500ms-5s）

   • 评估业务最大执行时间，设置超时时间 > 最大执行时间 × 2

3. 重试策略：

   int retryCount = 0;
   while (retryCount++ < 3) {if (tryLock()) {try {// 业务逻辑break;} finally {unlock();}}Thread.sleep(100 * retryCount);
   }

4. 监控指标：

   • 锁等待时间

   • 锁持有时间

   • 锁获取失败率

   • 死锁发生次数

六、常见陷阱与规避方法

1. 误解锁的持有者：

   // 错误示范：任何线程都能解锁
   public void unlock() {jedis.del(lockKey);
   }// 正确做法：验证唯一标识
   public void unlock(String uniqueId) {// 使用前面展示的Lua脚本
   }

2. 锁过期后处理：

   try {if (tryLock()) {// 业务执行中锁过期...// 可能导致多个客户端同时进入}
   } finally {// 可能释放其他客户端的锁unlock(); 
   }

   解决方案：

   • 实现锁续期机制

   • 使用Redisson等成熟框架

3. 锁重入问题：

   public void methodA() {lock();methodB();  // 需要重入锁unlock();
   }public void methodB() {lock();    // 同一线程再次获取锁// ...unlock();
   }

   解决方案：使用支持可重入的锁实现

七、性能优化建议

1. 锁粒度控制：

   // 粗粒度锁（不推荐）
   lock("order");// 细粒度锁（推荐）
   lock("order:123456");

2. 锁分段技术：

   // 将库存分成16段
   int segment = orderId.hashCode() & 15;
   lock("inventory:" + segment);

3. 避免长时间持锁：

   • 将业务逻辑分为锁内和锁外部分

   • 锁内只做竞争资源的操作

八、扩展思考

1. 分布式锁的本质：

   • 本质上是借助一个外部共享存储系统实现的互斥机制

   • Redis只是其中一种实现方式（其他如Zookeeper、Etcd等）

2. CAP理论下的选择：

   • Redis锁偏向AP（高可用）

   • Zookeeper锁偏向CP（一致性）

3. 分布式锁的演进趋势：

   • 向着更高性能、更易用的方向发展

   • 与云原生技术深度整合（如基于Kubernetes的实现）

通过以上系统性的分析和实践建议，可以构建出健壮可靠的Redis分布式锁方案。对于大多数Java项目，推荐直接使用Redisson框架，它已经处理了各种边界条件和异常情况。

3