Redis分布式锁：从基础实现到Redisson最佳实践

1. Redis分布式锁的核心价值与演进背景

在现代分布式系统中，资源竞争问题就像早高峰的地铁闸机——多个乘客（线程/进程）同时争夺有限的通行权限。传统单机锁就像车站只安排一名检票员，而分布式锁则需要协调多个车站的检票系统协同工作。Redis凭借其高性能、原子性操作和丰富的数据结构，成为实现分布式锁的首选方案之一。

我经历过从早期基于SETNX的简陋实现，到逐步引入超时机制、唯一标识、可重入性等特性的完整演进过程。在这个过程中踩过的坑包括：

• 锁未设置过期时间导致死锁（某次线上事故让支付服务瘫痪2小时）
• 误删其他线程持有的锁（缺乏唯一标识校验）
• 锁续期不及时引发的业务中断（GC停顿期间锁过期）

2. 基础实现方案与致命缺陷

2.1 第一代实现：SETNX + DEL

最基础的实现方案只需要两个命令：

bash复制SETNX lock_key 1  # 尝试获取锁
DEL lock_key      # 释放锁

这种方案存在三个致命缺陷：

1. 死锁风险：如果获取锁的客户端崩溃，锁将永远无法释放
2. 误删风险：可能删除其他客户端持有的锁
3. 非原子性：SETNX和EXPIRE不是原子操作

我在2016年曾用这种方案实现商品秒杀，结果因为某个节点网络抖动导致锁未释放，整个系统死锁了45分钟。这个教训让我意识到分布式锁绝不是简单的键值操作。

2.2 第二代实现：SET NX PX + Lua脚本

针对第一代的问题，改进方案引入了过期时间和唯一标识：

bash复制SET lock_key $uuid NX PX 30000  # 原子性设置锁和过期时间

释放锁时使用Lua脚本保证原子性：

lua复制if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

这个方案解决了前代的核心问题，但仍有改进空间：

• 锁过期时间设置需要经验值（设置太短会导致提前释放，太长会影响故障恢复）
• 不支持锁续期
• 不具备可重入性

3. Redisson的专业级实现

3.1 核心架构设计

Redisson的分布式锁实现可以看作是一个精密的瑞士手表，主要包含这些组件：

1. 锁续期机制：通过看门狗线程（Watchdog）定期刷新锁有效期
2. 可重入计数：用Hash结构存储客户端ID和重入次数
3. 异步释放：通过Pub/Sub通道通知其他等待客户端
4. 故障转移：支持RedLock算法跨多节点获取锁

3.2 关键源码解析

以Redisson 3.17.7版本为例，核心加锁逻辑在RedissonLock.tryLockInnerAsync方法：

java复制<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, 
                                long threadId, RedisStrictCommand<T> command) {
    return evalWriteAsync(getRawName(), LongCodec.INSTANCE, command,
            "if (redis.call('exists', KEYS[1]) == 0) then " +
            "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
            "redis.call('pexpire', KEYS[1], ARGV[1]); " +
            "return nil; " +
            "end; " +
            "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
            "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
            "redis.call('pexpire', KEYS[1], ARGV[1]); " +
            "return nil; " +
            "end; " +
            "return redis.call('pttl', KEYS[1]);",
            Collections.singletonList(getRawName()), 
            unit.toMillis(leaseTime), getLockName(threadId));
}

这段Lua脚本实现了：

• 通过Hash结构存储锁信息（支持可重入）
• 每次重入都会刷新过期时间
• 返回当前锁的剩余生存时间（用于等待锁的客户端）

3.3 看门狗机制详解

看门狗线程是Redisson最精妙的设计之一，其工作流程如下：

1. 默认情况下，如果未指定leaseTime，会启动看门狗线程
2. 锁的初始过期时间为30秒（默认值）
3. 每10秒（internalLockLeaseTime/3）检查一次客户端是否仍持有锁
4. 如果持有则延长过期时间至30秒

实际使用中发现，在GC停顿时间较长（超过看门狗检查间隔）的情况下，可能导致锁意外释放。建议对延迟敏感的业务显式指定leaseTime。

4. 生产环境最佳实践

4.1 参数调优指南

4.2 典型问题排查表

4.3 高可用架构建议

对于金融级场景，建议采用多活架构：

1. 部署至少5个Redis主节点（不同可用区）
2. 使用RedLock算法获取锁（需超过半数节点成功）
3. 设置合理的锁有效期和重试策略
4. 添加锁持有时间的监控告警

5. 深度优化与扩展思考

5.1 性能压测数据

在AWS c5.xlarge机型（4vCPU 8GB内存）的测试环境中：

5.2 与ZooKeeper的对比

5.3 锁的粒度控制技巧

在实际电商库存系统中，我发现分层加锁能显著提升并发性：

1. 全局锁：用于库存总量检查（key: "stock:global:{sku}"）
2. 区域锁：用于区域库存分配（key: "stock:region:{regionId}:{sku}"）
3. 仓库锁：最终扣减（key: "stock:warehouse:{whId}:{sku}"）

这种设计使得北京和上海的订单可以并行处理，只在涉及同一仓库时才需要互斥。