1. 分布式锁的本质与原子性挑战
在分布式系统中，锁机制从单机环境扩展到多节点环境时，会遇到一系列新的技术挑战。分布式锁的核心目标是在多个服务实例之间协调对共享资源的访问，确保同一时间只有一个客户端能执行关键操作。这与单机锁的最大区别在于：分布式锁需要应对网络延迟、节点故障、时钟不同步等分布式环境特有的问题。
原子性问题在分布式锁中尤为突出。一个典型的场景是：当客户端A获取锁后，由于GC暂停或网络延迟导致锁超时释放，此时客户端B获得了同一把锁。当客户端A从暂停中恢复后，仍然认为自己持有锁，这就导致了两个客户端同时进入临界区。这种问题的根源在于"获取锁"和"设置超时"这两个操作不是原子性的。
2. Redis分布式锁的原子性实现方案
2.1 SETNX + EXPIRE的原子性问题
早期常见的Redis锁实现方式是组合使用SETNX和EXPIRE命令：
SETNX lock_key unique_value EXPIRE lock_key 10这种方式存在明显的原子性问题：如果在SETNX成功后、EXPIRE执行前客户端崩溃，就会导致锁无法自动释放，形成死锁。
2.2 Redis 2.6+的原子性解决方案
Redis 2.6版本后提供了SET命令的扩展语法，支持原子性地设置值和过期时间：
SET lock_key unique_value NX PX 10000这个命令在设置值的同时指定了过期时间，解决了原子性问题。其中：
- NX表示只在键不存在时设置
- PX 10000表示10秒后自动过期
- unique_value是客户端生成的唯一标识，用于安全释放锁
3. Redisson的分布式锁实现剖析
Redisson作为Redis的Java客户端，提供了更完善的分布式锁实现RLock。其核心特性包括：
3.1 看门狗机制
Redisson通过后台线程定期(默认每10秒)检查客户端是否仍然活跃，如果客户端还在持有锁，就延长锁的生存时间。这解决了因长时间GC暂停导致锁意外释放的问题。
3.2 可重入锁实现
Redisson的锁支持可重入，同一个线程可以多次获取同一把锁。内部使用Redis的Hash结构存储锁信息：
key: lock_name field: client_id + thread_id value: 重入次数3.3 锁续期流程
- 客户端获取锁成功后启动看门狗线程
- 看门狗每隔(lockTimeout/3)时间检查锁状态
- 如果客户端仍持有锁，执行
PEXPIRE命令延长锁时间 - 客户端释放锁时取消看门狗任务
4. 主流分布式锁方案对比
| 实现方式 | 原子性保证 | 自动续期 | 可重入 | 性能 | 适用场景 |
|---|---|---|---|---|---|
| SETNX+EXPIRE | 无 | 无 | 无 | 高 | 简单场景 |
| SET NX PX | 有 | 无 | 无 | 高 | 基础需求 |
| Redisson | 有 | 有 | 有 | 中 | 复杂业务 |
| Zookeeper | 有 | 有 | 有 | 低 | 强一致场景 |
5. 分布式锁的典型原子性问题与解决方案
5.1 锁误删问题
场景：客户端A获取锁后执行时间过长，锁自动释放。客户端B获取锁后，A完成操作误删B的锁。
解决方案：释放锁时校验unique_value：
if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end5.2 锁续期竞争问题
场景：多个线程同时尝试续期同一把锁，导致不必要的Redis请求。
解决方案：Redisson使用semaphore控制同一时刻只有一个线程执行续期操作。
5.3 主从切换导致锁失效
场景：Redis主节点写入锁数据后未同步到从节点就崩溃，从节点提升为主后丢失锁信息。
解决方案：
- 使用RedLock算法(有争议)
- 改用Zookeeper/etcd等CP系统
- 业务层添加幂等性处理
6. 生产环境中的最佳实践
6.1 锁粒度控制
- 细粒度锁：按业务ID分段加锁，提高并发度
- 锁超时时间：根据业务操作耗时合理设置，通常设置为平均耗时的3倍
- 示例：订单支付锁可以设计为
pay_lock:{orderId}
6.2 异常处理策略
RLock lock = redisson.getLock("orderLock"); try { if (lock.tryLock(5, 30, TimeUnit.SECONDS)) { // 业务逻辑 } } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 恢复中断状态 } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } }6.3 监控与告警
- 监控指标：锁等待时间、锁持有时间、锁竞争次数
- 异常告警：锁等待超时、锁释放失败
- 日志记录：锁操作的关键事件(获取、续期、释放)
7. 从CAP理论看分布式锁选择
在分布式系统中，锁的实现需要权衡一致性(C)和可用性(A)：
- Redis锁：偏向AP，高可用但可能丢失锁
- Zookeeper锁：偏向CP，强一致但可能不可用
- 业务选择标准：
- 金融交易类：优先CP，接受短暂不可用
- 互联网业务：通常选择AP，通过业务补偿解决不一致
在实际架构中，可以根据不同业务场景混合使用多种锁方案。比如支付核心使用Zookeeper锁，而库存扣减使用Redis锁。
