1. Redis分布式锁的核心价值与挑战
在分布式系统中，多个服务实例对共享资源的并发访问是个经典难题。想象一下电商系统中的库存扣减场景：当100个用户同时抢购10件商品时，如果没有可靠的并发控制机制，很可能出现超卖问题。这就是分布式锁要解决的核心问题——在分布式环境下实现互斥访问。
Redis之所以成为实现分布式锁的热门选择，主要基于三个特性：
- 单线程执行模型：天然避免多线程竞争
- 高性能：每秒数万次操作能力满足高并发场景
- 丰富的数据结构和原子操作：为锁实现提供多种可能
但实现一个生产可用的Redis分布式锁并非易事，需要解决以下关键问题：
- 互斥性：必须确保任意时刻只有一个客户端能持有锁
- 死锁预防：持有锁的客户端崩溃时要有自动释放机制
- 容错性：Redis节点故障时不能出现锁状态不一致
- 可重入性：同一线程可多次获取同一把锁
- 高性能：加锁/解锁操作不能成为系统瓶颈
2. 基于SETNX的简易分布式锁实现
2.1 基础实现原理
最直观的实现方式是使用Redis的SETNX（SET if Not eXists）命令：
SETNX lock_key unique_value当key不存在时设置成功返回1，否则返回0。客户端通过返回值判断是否获取到锁。
典型加锁流程：
- 客户端A执行
SETNX lock_key 1 - Redis返回1表示加锁成功
- 客户端A执行业务逻辑
- 完成后执行
DEL lock_key释放锁
2.2 关键问题与优化
这个基础实现存在明显缺陷：
- 死锁风险：如果客户端获取锁后崩溃，锁将永远无法释放
- 非原子性：设置锁和设置过期时间不是原子操作
改进方案：
SET lock_key unique_value NX PX 30000这条命令实现了：
- NX：等效于SETNX的互斥设置
- PX：设置毫秒级过期时间
- unique_value：客户端唯一标识，防止误删
2.3 释放锁的正确姿势
错误的解锁方式：
DEL lock_key这会导致其他客户端可能删除不属于自己的锁。正确做法：
if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end使用Lua脚本保证原子性，并通过value验证锁的所有者。
关键经验：一定要设置合理的过期时间，通常建议是业务最大预估耗时的2-3倍。我曾遇到过因GC停顿导致业务执行超时，锁提前释放引发的并发问题。
3. RedLock算法实现分布式锁
3.1 为什么需要RedLock
当Redis采用单节点部署时，存在单点故障风险。RedLock算法通过多节点部署来提高可靠性，核心思想是：在大多数节点上获取到锁才算成功。
3.2 算法实现步骤
- 获取当前毫秒级时间戳T1
- 依次向N个Redis节点发送加锁命令（相同key和value）
- 计算获取锁耗时 = 当前时间T2 - T1
- 只有当客户端在多数节点（N/2+1）上获取成功
- 且总耗时小于锁有效期时才算成功
- 锁的实际有效时间 = 初始有效时间 - 获取锁耗时
- 如果获取失败，需要向所有节点发送释放锁请求
3.3 生产环境注意事项
- 节点数量建议5个以上，且部署在不同物理机
- 时钟同步问题：各节点必须使用NTP保持时钟同步
- 性能考量：获取多个节点的锁会增加延迟
- 争议场景处理：当发生网络分区时可能出现多个客户端同时持有锁
# Python伪代码示例 def acquire_lock(redis_nodes, resource, ttl): start_time = time.time() locked_nodes = [] for node in redis_nodes: try: if node.set(resource, random_value, nx=True, px=ttl): locked_nodes.append(node) except RedisError: continue elapsed = time.time() - start_time if len(locked_nodes) >= len(redis_nodes)//2 + 1 and elapsed < ttl: return Lock(locked_nodes, resource, random_value, ttl - elapsed) else: for node in locked_nodes: node.delete(resource) return None4. 基于Redisson的分布式锁实现
4.1 Redisson的优势
Redisson是Redis的Java客户端，提供了开箱即用的分布式锁实现：
- 自动续期：通过看门狗机制定期延长锁有效期
- 可重入支持：同一线程可多次获取锁
- 多种锁类型：公平锁、联锁、红锁等
- 完善的API：符合Java锁规范
4.2 典型使用方式
RLock lock = redisson.getLock("myLock"); try { // 尝试加锁，最多等待100秒，上锁后30秒自动解锁 boolean res = lock.tryLock(100, 30, TimeUnit.SECONDS); if (res) { // 业务逻辑 } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { lock.unlock(); }4.3 核心实现原理
- Hash结构存储：锁信息存储在Redis的Hash结构中，包含客户端ID、线程ID和重入次数
- 看门狗机制：后台线程每10秒检查一次，如果业务还在执行就延长锁有效期
- 发布订阅：锁释放时会发布消息，其他等待客户端可以立即尝试获取
- Lua脚本：所有关键操作都通过Lua脚本保证原子性
4.4 性能优化建议
- 避免长时间持锁：虽然看门狗可以续期，但长时间持锁会影响系统吞吐量
- 合理设置等待时间：过长的tryLock等待时间可能导致线程堆积
- 锁粒度控制：根据业务场景选择合适粒度的锁（如用户ID级别而不是全局锁）
5. 三种实现方式的对比分析
| 特性 | SETNX实现 | RedLock算法 | Redisson实现 |
|---|---|---|---|
| 实现复杂度 | 低 | 高 | 中（封装完善） |
| 可靠性 | 单点风险 | 多节点容错 | 单点+自动续期 |
| 可重入支持 | 需自行实现 | 需自行实现 | 内置支持 |
| 自动续期 | 不支持 | 不支持 | 支持 |
| 性能影响 | 最低 | 较高（多节点） | 中等 |
| 适用场景 | 简单场景 | 高可用要求场景 | Java技术栈项目 |
6. 生产环境常见问题与解决方案
6.1 锁提前释放问题
现象：业务逻辑还未执行完，锁已经过期被其他客户端获取解决方案：
- 合理评估业务耗时，设置足够长的过期时间
- 使用Redisson的看门狗机制自动续期
- 实现锁续约逻辑（需自行保证原子性）
6.2 时钟漂移问题
现象：在RedLock实现中，各节点时钟不同步导致锁有效期计算错误解决方案：
- 所有Redis节点配置NTP时间同步
- 在锁有效期中预留时钟误差buffer
- 使用物理时钟而非逻辑时钟
6.3 客户端停顿问题
现象：因GC停顿或网络延迟导致客户端"假死"，锁过期后业务继续执行解决方案：
- 监控JVM GC情况，优化内存配置
- 在业务代码中添加锁有效性检查
- 实现锁令牌机制，每次操作前验证令牌有效性
6.4 Redis脑裂问题
现象：集群发生网络分区，出现多个主节点同时对外服务解决方案：
- 配置合理的Redis集群参数（如min-slaves-to-write）
- 使用RedLock算法增加容错性
- 在应用层添加二次确认机制
7. 性能优化实战技巧
锁分段：将热点资源拆分为多个段，用不同的锁保护
- 例如库存系统可以将商品ID哈希后分散到100个锁
乐观锁配合：在适合的场景结合版本号机制
UPDATE inventory SET count=count-1 WHERE id=100 AND version=123避免锁嵌套：尽量减少锁的持有时间和作用范围
监控告警：
- 监控锁等待时间
- 记录锁获取失败率
- 设置锁持有时间阈值告警
压测验证：使用JMeter等工具模拟高并发场景，验证锁的有效性
在最近的一个秒杀系统项目中，我们通过锁分段将TPS从500提升到了3000+。关键实现是将商品ID取模后分散到256个Redis key，每个key对应一个独立的分布式锁。
