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脚本实现 | 灵活性高 | 需要自行处理所有边界情况 | 需要定制化的特殊场景 |
五、生产环境最佳实践
-
锁命名规范：
// 业务:功能:资源 三级命名 String lockKey = "order:pay:orderId_123456"; -
超时时间设置：
-
设置合理的过期时间（通常500ms-5s）
-
评估业务最大执行时间，设置超时时间 > 最大执行时间 × 2
-
-
重试策略：
int retryCount = 0; while (retryCount++ < 3) {if (tryLock()) {try {// 业务逻辑break;} finally {unlock();}}Thread.sleep(100 * retryCount); } -
监控指标：
-
锁等待时间
-
锁持有时间
-
锁获取失败率
-
死锁发生次数
-
六、常见陷阱与规避方法
-
误解锁的持有者：
// 错误示范：任何线程都能解锁 public void unlock() {jedis.del(lockKey); }// 正确做法：验证唯一标识 public void unlock(String uniqueId) {// 使用前面展示的Lua脚本 } -
锁过期后处理：
try {if (tryLock()) {// 业务执行中锁过期...// 可能导致多个客户端同时进入} } finally {// 可能释放其他客户端的锁unlock(); }解决方案：
-
实现锁续期机制
-
使用Redisson等成熟框架
-
-
锁重入问题：
public void methodA() {lock();methodB(); // 需要重入锁unlock(); }public void methodB() {lock(); // 同一线程再次获取锁// ...unlock(); }解决方案：使用支持可重入的锁实现
七、性能优化建议
-
锁粒度控制：
// 粗粒度锁（不推荐） lock("order");// 细粒度锁（推荐） lock("order:123456"); -
锁分段技术：
// 将库存分成16段 int segment = orderId.hashCode() & 15; lock("inventory:" + segment); -
避免长时间持锁：
-
将业务逻辑分为锁内和锁外部分
-
锁内只做竞争资源的操作
-
八、扩展思考
-
分布式锁的本质：
-
本质上是借助一个外部共享存储系统实现的互斥机制
-
Redis只是其中一种实现方式（其他如Zookeeper、Etcd等）
-
-
CAP理论下的选择：
-
Redis锁偏向AP（高可用）
-
Zookeeper锁偏向CP（一致性）
-
-
分布式锁的演进趋势：
-
向着更高性能、更易用的方向发展
-
与云原生技术深度整合（如基于Kubernetes的实现）
-
通过以上系统性的分析和实践建议，可以构建出健壮可靠的Redis分布式锁方案。对于大多数Java项目，推荐直接使用Redisson框架，它已经处理了各种边界条件和异常情况。
3
