Redis分布式锁
很多人在刚接触分布式系统的时候，都会遇到一个问题：
多个服务实例同时处理同一件事情，如何避免数据被重复处理？
例如：
- 用户抢优惠券
- 定时任务执行
- 库存扣减
- 订单状态更新
如果系统只有一个进程，其实很简单，用 本地锁（mutex） 就能解决。
但在微服务架构或者集群部署之后，问题就变了。
系统可能有：
- 10个服务实例
- 100个Worker
- 甚至多个数据中心
这时候，本地锁就完全失效了，因为不同进程之间根本不知道彼此的锁状态。
于是就出现了一个概念：
分布式锁（Distributed Lock）
分布式锁的目标很简单：
在分布式环境下，保证某一时刻只有一个节点能执行某段逻辑。
为什么 Redis 可以做分布式锁？
在实现分布式锁的时候，很多人第一反应是数据库。
例如：
select ... for update但数据库锁的问题是：
- 性能差
- 锁粒度大
- 并发高时压力很大
于是大家开始寻找一个更适合做锁的系统。
Redis就非常合适。
原因很简单：
Redis天然具备三个优势：
1）单线程模型
Redis核心命令是单线程执行的。
这意味着：
同一时间只有一个命令在执行。
所以像下面这种操作：
SET key value NX是 绝对原子操作。
不会出现竞争条件。
2）内存操作，速度极快
Redis所有数据都在内存中。
一次锁操作通常只需要：
- 一次 SET
- 一次 DEL
延迟通常在：
几十微秒级别
远远比数据库快。
3）支持自动过期
Redis key 可以设置 TTL。
例如：
SET lock:order 123 NX EX 10含义是：
- 不存在才创建
- 10秒自动过期
这样即使服务崩溃，锁也不会永远卡住。
Redis锁释放
释放锁时不能直接 DEL。
因为可能发生这种情况：
线程A获取锁
线程A执行超时
锁过期
线程B获取锁
线程A执行完删除锁这时候线程A会误删线程B的锁。
正确做法是：
只删除自己持有的锁。
通常通过 Lua 脚本实现：
if redis.call("GET",KEYS[1]) == ARGV[1] then
return redis.call("DEL",KEYS[1])
else
return 0
end这样才能保证安全释放。
redis分布式锁的几个经典问题
虽然Redis锁很简单，但在真实系统中会遇到很多坑。
最常见的几个问题是：
锁过期问题
如果业务执行时间超过TTL：
锁就会提前释放。
其他节点就可能同时进入。
解决办法：
自动续期（WatchDog）。
例如：
- 锁10秒
- 根据过期时间最后30%的时间进行自动秒续期一次，并添加抖动时间，防止在一个时刻进行续期，对Redis进行集中请求
只要任务还在执行，锁就不会过期。
Redis单点问题
如果Redis挂掉：
所有锁都会失效。
常见解决方案是：
- Redis Sentinel
- Redis Cluster
- RedLock算法
Redis AP设计与 ETCD，Zookeeper CP 架构区别
Redis本身是一个偏 AP（可用性优先） 的系统。
也就是说：
在网络分区或者节点故障的时候，Redis会优先保证服务可用，而不是保证数据绝对一致。
这就可能带来一个风险：
在极端情况下，可能同时出现两个客户端都认为自己拿到了锁。
例如：
客户端A在主节点获取了锁
主节点还没来得及同步到从节点
主节点突然宕机
从节点被提升为新的主节点
这时候新的主节点并不知道A已经加过锁。
客户端B就可能再次获取锁。
这样就会出现：
两个客户端同时持有锁。
这就是Redis分布式锁在理论上的一致性风险。
相比之下，像 etcd 或 ZooKeeper 这样的系统是基于 CP模型（强一致） 设计的。
它们内部通过 Raft 或 ZAB 协议 保证多数节点确认之后才会提交数据。
因此：
一旦锁被获取成功，整个集群都会达成一致。
不会出现多个客户端同时拿到锁的情况。
所以在工程实践中通常有一个经验：
如果是 业务级锁（例如库存、任务控制）
Redis分布式锁通常已经足够使用。
但如果是 强一致要求很高的场景
例如：
金融交易
全局调度系统
分布式协调服务
很多系统会选择：
etcd / ZooKeeper 这种强一致的锁实现。
Redis分布式锁总结
Redis分布式锁的核心思想其实非常简单
利用Redis原子操作实现互斥。
它通常包含三个关键点：
1）原子加锁
2）安全释放
3）自动过期或续期
在实际工程中，一套成熟的Redis锁通常还会包含：
重试机制
- WatchDog自动续期
- Lua安全释放
- 锁唯一标识
这些设计组合在一起，才能真正成为一个稳定可靠的 分布式锁系统。