Redis 分布式锁是一种基于 Redis 实现的、用于在分布式系统 中控制多个进程或服务节点互斥访问共享资源的协调机制。它的核心目标是确保在分布式环境下，对共享资源的操作（如数据修改）能够保持一致性，避免因并发访问导致的数据错误。
🔧 核心特性
一把可靠的 Redis 分布式锁应具备以下特性：
- 互斥性：这是最基本的要求，保证在任何时刻，只有一个客户端能够持有锁。
- 锁超时释放：锁应设有合理的过期时间，防止因持有锁的客户端崩溃或网络中断而导致锁无法释放，造成死锁。
- 安全性：锁只能由加锁的持有者释放，不能被其他客户端误删。这通常通过为每个锁设置唯一标识（如 UUID）来实现。
- 高可用与高性能：作为分布式锁基础的 Redis 服务需要高可用，并且加锁和解锁操作本身应尽可能高效，避免成为系统瓶颈。
⚙️ 实现原理与关键命令
Redis 分布式锁主要利用 Redis 的原子操作 来实现，其中最关键的命令是 SET key value NX EX seconds（或 PX milliseconds）：
- NX：表示 "Set if Not eXists"，即仅当 Key 不存在时才能设置成功，这保证了互斥性。
- EX/PX ：为 Key 设置过期时间（EX 单位秒，PX 单位毫秒），这是避免死锁的关键。
- 释放锁时，为了确保安全 （只释放自己持有的锁），通常会结合 Lua 脚本实现原子性的"判断+删除"操作。
对于更高要求的场景，Redis 作者提出了 RedLock 算法，它通过在多个独立的 Redis 主节点上获取锁（通常需要超过半数的节点成功），来提升锁的可靠性，避免因单点故障或主从切换导致锁失效。
🚀 主要使用场景
Redis 分布式锁在以下高并发和需要数据强一致性的场景中非常有用：
| 场景 | 说明 |
|---|---|
| 电商秒杀与库存扣减 | 防止商品超卖。在扣减库存前先获取锁，确保只有一个请求能操作库存。 |
| 分布式任务调度 | 确保在集群环境中，多个节点的定时任务（如每天的数据报表）在同一时间只有一个节点执行，避免重复执行。 |
| 防止重复提交 | 针对用户的关键操作（如支付、提交订单），通过锁机制确保即使在网络抖动导致客户端重复发送请求的情况下，服务端也只会处理一次。 |
| 全局配置更新 | 在微服务架构中，当需要更新所有服务的公共配置时，通过分布式锁协调更新过程，避免配置不一致。 |
💡 注意事项与最佳实践
- 锁的粒度 ：锁的 Key 要精确。例如，对商品库存加锁时，使用
seckill:product:123（商品ID=123）比使用一个全局的seckill:lock性能更好，冲突更少。 - 过期时间设置 ：锁的过期时间不宜过短或过长。过短可能导致业务未完成锁就释放；过长则故障恢复慢。建议设置为业务平均处理时间的 2-3 倍，或使用类似 Redisson 的 看门狗机制（Watchdog）自动续期。
- 务必释放锁 ：释放锁的操作必须放在
finally代码块中执行，确保即使业务代码异常也能释放锁。 - 选择成熟客户端 ：在生产环境中，建议直接使用 Redisson 等成熟的 Redis 客户端库，它们提供了开箱即用的分布式锁实现，内置了看门狗、可重入等特性，能帮你处理很多底层细节和边界情况。