1. Redis分布式锁的本质与核心挑战
在分布式系统中，多个服务实例需要协调对共享资源的访问时，分布式锁就成为了刚需。Redis凭借其高性能和丰富的数据结构，成为了实现分布式锁的热门选择。但真正要设计一个可靠的Redis分布式锁，我们需要先理解它需要解决的四个本质问题：
1.1 互斥性：锁的基本要求
互斥性意味着在同一时刻，只有一个客户端能够持有锁。这看似简单，但在分布式环境下却充满挑战。想象一下银行金库的大门——任何时候只能有一个人持有钥匙进入，其他人必须等待。Redis的SETNX命令（SET if Not eXists）天然适合实现这种互斥性。
1.2 防死锁：系统稳定性的保障
死锁是指锁的持有者由于某种原因（如进程崩溃）无法释放锁，导致其他客户端永远无法获取锁的情况。就像某人拿着金库钥匙突然晕倒，其他人永远进不去了。Redis的EXPIRE机制可以设置键的自动过期时间，是防止死锁的关键。
1.3 防误删：数据安全的防线
误删是指当前客户端错误地删除了其他客户端持有的锁。这通常发生在锁过期时间设置不合理的情况下。例如：
- 客户端A获取锁，设置10秒过期
- A的业务处理耗时15秒
- 第10秒时锁自动释放
- 客户端B获取锁
- 第15秒时A完成处理，误删了B的锁
1.4 高可用：生产环境的必备条件
当Redis节点宕机时，锁服务不能完全不可用。虽然Redis本身提供了持久化和集群方案，但在极端情况下（如主从切换时），仍然可能出现锁失效的问题。RedLock算法就是针对这种场景提出的解决方案。
2. 四种实现方案深度解析
2.1 方案1：SETNX + EXPIRE（基础版）
实现原理
bash复制SETNX lock_key 1 # 尝试获取锁
EXPIRE lock_key 10 # 设置过期时间
致命缺陷
这两个命令不是原子操作。如果在SETNX成功后、EXPIRE执行前客户端崩溃，锁将永远不会释放。我在早期项目中使用这种方案时，就曾因为一个未捕获的异常导致系统锁死，不得不手动清理Redis中的锁键。
适用场景
仅适用于学习理解分布式锁的基本概念，绝对不要在生产环境使用。
2.2 方案2：SET NX EX（原子操作版）
实现原理
bash复制SET lock_key random_value NX EX 10
这个命令将获取锁和设置过期时间合并为一个原子操作，解决了方案1的死锁问题。
仍然存在的问题
- 误删风险：如果直接使用DEL命令删除锁，可能会删除其他客户端持有的锁
- 过期时间难题：业务执行时间超过锁过期时间会导致并发问题
生产环境建议
小型系统、对一致性要求不高的场景可以谨慎使用，但必须配合唯一标识来避免误删。
2.3 方案3：唯一标识 + Lua脚本（企业标准版）
完整实现
lua复制-- 加锁
SET lock_key unique_id NX EX 10
-- 解锁脚本
if redis.call("GET",KEYS[1]) == ARGV[1] then
return redis.call("DEL",KEYS[1])
else
return 0
end
关键改进
- 每个锁都有唯一标识（通常使用UUID）
- 解锁时验证标识，确保不会误删他人锁
- 使用Lua脚本保证解锁操作的原子性
实战经验
在实际项目中，我推荐将锁操作封装为客户端库。以下是一个Java实现的伪代码示例：
java复制public class RedisLock {
private String lockKey;
private String lockValue;
private int expireTime;
public boolean tryLock() {
lockValue = UUID.randomUUID().toString();
String result = redis.set(lockKey, lockValue, "NX", "EX", expireTime);
return "OK".equals(result);
}
public void unlock() {
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
redis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(lockValue));
}
}
2.4 方案4：Redisson Watchdog（生产级方案）
核心机制
Redisson的分布式锁实现了以下特性：
- 自动续期：默认30秒过期，后台线程每10秒检查并续期（"看门狗"机制）
- 可重入：同一线程可以多次获取同一把锁
- 公平锁：支持按照请求顺序获取锁
- 联锁：可以将多个锁合并为一个锁管理
使用示例
java复制RLock lock = redisson.getLock("orderLock");
try {
// 尝试加锁，最多等待100秒，上锁后30秒自动解锁
boolean res = lock.tryLock(100, 30, TimeUnit.SECONDS);
if (res) {
// 业务逻辑
}
} finally {
lock.unlock();
}
实现原理
Redisson底层使用Hash结构存储锁信息：
code复制myLock: {
"uuid:threadId": 1 // 重入次数
}
加锁和解锁都通过Lua脚本保证原子性，同时启动守护线程定期续期。
3. 生产环境选型指南
3.1 方案对比矩阵
| 方案 | 互斥性 | 防死锁 | 防误删 | 自动续期 | 生产适用性 | 面试价值 |
|---|---|---|---|---|---|---|
| SETNX+EXPIRE | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| SET NX EX | ✅ | ✅ | ❌ | ❌ | ⚠️ | ❌ |
| 唯一ID+Lua | ✅ | ✅ | ✅ | ❌ | ✅ | ⚠️ |
| Redisson | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
3.2 选型建议
- 小型项目：可以使用方案3（唯一ID+Lua），但需要仔细评估业务最大执行时间
- 中大型项目：强烈推荐Redisson，它解决了锁续期、可重入等复杂问题
- 金融级场景：考虑RedLock算法（尽管有争议），或直接使用Zookeeper等CP系统
3.3 性能优化技巧
- 锁粒度：锁的粒度要尽可能小。例如，不要锁整个订单系统，而是锁单个订单ID
- 超时时间：根据压测结果设置合理的超时时间，既不能太短导致频繁超时，也不能太长导致系统僵死
- 重试策略：获取锁失败时采用指数退避算法，避免大量客户端同时重试造成雪崩
4. 常见问题与解决方案
4.1 锁过期时间设置难题
问题场景：
- 设置太短：业务未完成锁已过期
- 设置太长：系统故障时恢复缓慢
解决方案：
- 监控业务平均执行时间，设置超时时间为平均时间的2-3倍
- 使用Redisson的看门狗机制自动续期
- 实现锁续期接口，业务代码定期上报"心跳"
4.2 Redis主从切换导致锁失效
问题描述：
在Redis主从架构中，如果主节点在锁信息同步到从节点前崩溃，可能导致多个客户端同时获取锁。
解决方案：
- 使用RedLock算法（需要至少5个独立的Redis主节点）
- 接受极小概率的锁失效，通过业务层幂等性设计弥补
- 考虑使用Zookeeper等CP系统替代
4.3 锁重入需求
问题场景：
同一线程需要多次获取同一把锁（如递归调用）。
解决方案：
- 使用Redisson等支持可重入的客户端
- 自行实现计数器，记录锁的获取次数：
lua复制-- 加锁脚本
local counter = redis.call('hincrby', KEYS[1], ARGV[1], 1)
redis.call('expire', KEYS[1], ARGV[2])
return counter
5. 高级话题与面试深度
5.1 Redisson底层实现剖析
Redisson的分布式锁实现包含以下关键设计：
- 异步续约：通过Netty的定时任务实现后台续期
- 订阅发布：锁释放时通过Redis的pub/sub通知等待客户端
- 看门狗：守护线程定期检查客户端是否存活
- hash结构：存储锁持有者信息和重入次数
5.2 Redis分布式锁的局限性
即使使用Redisson，Redis分布式锁也有其适用边界：
- 性能与一致性权衡：Redis是AP系统，在极端情况下无法保证强一致性
- 时钟依赖：RedLock算法依赖各节点的时钟同步
- 资源消耗：大量锁竞争时会显著增加Redis负载
5.3 替代方案对比
当Redis锁不满足需求时，可以考虑：
- Zookeeper：CP系统，适合强一致性场景，但性能较低
- Etcd：同样提供强一致性，比Zookeeper更轻量
- 数据库锁：简单但性能差，适合低频场景
在实际项目中，我通常会根据业务特点选择最合适的方案。例如，对一致性要求极高的金融交易使用Zookeeper，而对性能要求高的秒杀系统则使用Redis锁配合本地缓存。