1. Redis分布式锁的核心原理与必要性
在分布式系统中，多个服务实例需要协调对共享资源的访问时，传统的单机锁机制就失效了。想象一下，当多个订单服务同时尝试扣减同一件商品的库存时，如果没有跨进程的锁机制，就会导致超卖问题。这就是Redis分布式锁最典型的应用场景。
Redis之所以能实现分布式锁，主要依靠其单线程特性和原子操作。当我们在Redis中执行SET key value NX PX 30000这样的命令时：
- NX表示只有当key不存在时才设置成功
- PX 30000表示这个key会在30秒后自动过期
- 整个操作是原子的，不会被其他命令打断
这种特性完美符合了分布式锁的三个基本要求：
- 互斥性（同一时刻只有一个客户端能持有锁）
- 避免死锁（自动过期机制）
- 容错性（Redis节点宕机时锁会自动释放）
2. 基础实现方案与常见陷阱
2.1 正确的加锁方式
最基础的加锁命令如下：
SET lock:order:1234 uuid1234 NX PX 30000这个命令中：
- lock:order:1234是锁的名称，建议按业务场景命名
- uuid1234是全局唯一标识，通常用UUID生成
- 30000是锁的自动释放时间(毫秒)
在Java中，使用Jedis客户端的实现如下：
public boolean tryLock(Jedis jedis, String lockKey, String requestId, int expireTime) { String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime); return "OK".equals(result); }2.2 常见错误实现
很多初学者会犯的一个典型错误是将加锁和设置过期时间分成两步：
// 错误示范！ Long result = jedis.setnx(lockKey, requestId); if (result == 1) { // 如果在这步之前程序崩溃，就会导致死锁 jedis.expire(lockKey, expireTime); }这种非原子操作在高并发场景下会导致严重问题。
3. 安全释放锁的正确姿势
3.1 为什么释放锁需要特殊处理
直接使用DEL命令删除锁是危险的，考虑以下时序：
- 客户端A获取锁，设置30秒过期
- 客户端A执行耗时操作（如数据库事务），耗时超过30秒
- 锁自动过期释放
- 客户端B获取到同一个资源的锁
- 客户端A完成操作，执行DEL命令
- 结果：客户端B的锁被意外释放！
3.2 Lua脚本实现原子解锁
Redis的eval命令可以原子化执行Lua脚本，这是最可靠的解锁方式：
if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 endJava中的调用示例：
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end"; Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));4. 生产环境中的进阶考量
4.1 锁续期机制
对于可能长时间执行的任务，需要实现锁续期（也称为看门狗机制）。基本思路是：
- 获取锁成功后启动一个后台线程
- 每隔一段时间（如过期时间的1/3）检查锁是否仍由当前客户端持有
- 如果是，则延长锁的过期时间
Redisson客户端库已经内置了这个功能。
4.2 集群环境下的特殊问题
在Redis主从架构中，当主节点崩溃时：
- 客户端A在主节点获取锁
- 主节点还未同步到从节点就崩溃
- 从节点升级为新主节点
- 客户端B也能获取同一个资源的锁
针对这种情况，Redis作者提出了RedLock算法，需要至少5个独立的Redis主节点，客户端需要在多数节点上成功获取锁才算真正获取成功。
5. 性能优化与最佳实践
5.1 锁粒度控制
锁的粒度应该尽可能小：
- 好的做法：lock:order:1234（锁定特定订单）
- 不好的做法：lock:orders（锁定所有订单）
5.2 超时时间设置
过期时间需要仔细权衡：
- 太短：业务未完成锁就自动释放
- 太长：系统故障时恢复时间延长
建议：
- 根据业务操作的最长时间设置基础值
- 增加20-30%的缓冲时间
- 实现锁续期机制
5.3 客户端选型建议
对于Java项目：
- 简单场景：Jedis + 自研锁逻辑
- 复杂场景：Redisson（内置分布式锁、锁续期等功能）
6. 真实案例：库存扣减系统
我们曾实现一个电商库存系统，核心逻辑如下：
public boolean deductStock(String itemId, int num) { String lockKey = "lock:stock:" + itemId; String requestId = UUID.randomUUID().toString(); try { // 尝试获取锁 boolean locked = tryLock(lockKey, requestId, 5000); if (!locked) { return false; } // 查询库存 int stock = getStockFromDB(itemId); if (stock < num) { return false; } // 扣减库存 updateStockInDB(itemId, stock - num); return true; } finally { // 释放锁 unlock(lockKey, requestId); } }遇到的坑与解决方案：
问题：高峰期锁竞争导致性能下降 解决：引入分段锁，将商品库存拆分为多个子库存
问题：锁自动释放后业务仍在执行 解决：实现锁续期机制，每2秒检查一次
问题：Redis节点故障导致锁服务不可用 解决：部署Redis哨兵集群，并设置合理的故障转移策略
7. 监控与问题排查
完善的监控应包括：
- 锁等待时间
- 锁持有时间
- 锁获取失败率
- Redis节点健康状态
当出现问题时，可以检查：
- Redis慢查询日志
- 客户端连接池状态
- 网络延迟情况
- GC日志（如果是Java应用）
8. 替代方案对比
除了Redis，常见的分布式锁实现还有：
| 方案 | 优点 | 缺点 |
|---|---|---|
| ZooKeeper | 强一致性，可靠性高 | 性能较低，部署复杂 |
| etcd | 支持租约，API友好 | 社区资源相对较少 |
| 数据库 | 无需额外组件 | 性能差，有死锁风险 |
选择建议：
- 强一致性要求高：ZooKeeper
- 高性能要求：Redis
- 已有etcd集群：etcd
在实际项目中，我们通常会根据具体场景选择合适的方案，有时甚至会组合使用多种实现。
