Redis 分布式锁的工程真相：从 SET NX 到 Redlock 的生产级演进

Redis 分布式锁的工程真相从 SET NX 到 Redlock 的生产级演进一、并发场景下的资源争抢——分布式锁为何是刚需在分布式系统中多个服务实例同时访问共享资源是常见的工程挑战。无论是电商的库存扣减、金融场景的余额更新还是定时任务的防重复执行都需要一种跨进程、跨机器的互斥机制来保证数据一致性。以一个典型的 AI SaaS 平台为例用户调用大模型接口时系统需要校验 Token 余额并扣减。如果两个请求同时到达不同的服务实例在无锁保护的情况下可能出现超扣问题——两个请求都读到余额为 100各自扣减 50 后写入 50实际应该剩余 0 却变成了 50。这类并发 Bug 在低流量时难以复现但在流量高峰期会集中爆发造成直接的资金损失。Redis 因其单线程执行模型和丰富的原子命令成为实现分布式锁的首选方案。然而从简单的SET NX到生产级可用的分布式锁中间存在大量容易被忽视的工程细节。一个不严谨的分布式锁实现比没有锁更危险——因为它给人一种安全的错觉。二、Redis 分布式锁的底层机制与演进路径2.1 基础实现SET NX 过期时间最基础的 Redis 分布式锁利用SET key value NX PX timeout命令的原子性当 key 不存在时设置成功获取锁并附带毫秒级过期时间防止死锁。sequenceDiagram participant C1 as 客户端1 participant R as Redis participant C2 as 客户端2 C1-R: SET lock_key uuid NX PX 30000 R--C1: OK获取锁成功 C2-R: SET lock_key uuid NX PX 30000 R--C2: nil锁已被占用 C1-R: 执行业务逻辑... C1-R: 删除锁需验证 value C2-R: SET lock_key uuid NX PX 30000 R--C2: OK获取锁成功2.2 锁续约机制看门狗模式业务逻辑执行时间可能超过锁的过期时间。如果锁提前过期其他客户端就能获取锁导致互斥性被破坏。看门狗Watchdog模式通过后台线程定期续约来解决此问题。graph LR A[获取锁br过期时间 30s] -- B{业务是否完成?} B --|否| C[看门狗线程br每 10s 续约至 30s] C -- B B --|是| D[主动释放锁] D -- E[停止看门狗] style A fill:#2d3436,color:#fff style D fill:#00b894,color:#fff style E fill:#636e72,color:#fff2.3 多节点一致性Redlock 算法单节点 Redis 存在单点故障风险。如果 Redis 主节点宕机而锁数据尚未同步到从节点从节点被提升为主节点后另一个客户端可能获取同一把锁导致互斥性失效。Redlock 算法通过在多个独立 Redis 实例上同时获取锁来解决这个问题。三、生产级 Redis 分布式锁的完整实现以下实现涵盖了锁获取、看门狗续约、安全释放和 Redlock 多节点一致性四个核心能力。import time import uuid import threading from typing import Optional, List import redis class RedisDistributedLock: 基于 Redis 的分布式锁实现。 包含看门狗自动续约和安全释放机制。 # 看门狗续约间隔过期时间的 1/3 WATCHDOG_RATIO 1 / 3 # 默认锁过期时间毫秒 DEFAULT_LOCK_TIMEOUT_MS 30000 def __init__(self, redis_client: redis.Redis, lock_key: str, timeout_ms: int DEFAULT_LOCK_TIMEOUT_MS): self.redis redis_client self.lock_key lock_key self.timeout_ms timeout_ms # 每个锁持有者使用唯一标识防止误删其他客户端的锁 self.lock_value str(uuid.uuid4()) self._watchdog_thread: Optional[threading.Thread] None self._stop_watchdog threading.Event() def acquire(self, retry_count: int 3, retry_delay_ms: int 200) - bool: 获取分布式锁支持重试。 使用 SET NX PX 原子命令保证获取和设置过期时间的原子性。 for attempt in range(retry_count): # SET key value NX PX timeout —— 原子操作 result self.redis.set( self.lock_key, self.lock_value, nxTrue, pxself.timeout_ms ) if result: # 获取锁成功启动看门狗续约线程 self._start_watchdog() return True if attempt retry_count - 1: time.sleep(retry_delay_ms / 1000.0) return False def release(self) - bool: 安全释放锁使用 Lua 脚本保证检查 value 删除 key的原子性。 只有锁的持有者才能释放自己的锁避免误删。 # 先停止看门狗 self._stop_watchdog_event() # Lua 脚本原子性地检查并删除 lua_script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end result self.redis.eval(lua_script, 1, self.lock_key, self.lock_value) return result 1 def _start_watchdog(self) - None: 启动看门狗线程定期续约锁的过期时间 self._stop_watchdog.clear() interval self.timeout_ms * self.WATCHDOG_RATIO / 1000.0 def _watchdog_loop(): while not self._stop_watchdog.wait(timeoutinterval): # 续约仅当锁的 value 仍然匹配时才续约 # 防止续约了已经被其他客户端获取的锁 lua_script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(pexpire, KEYS[1], ARGV[2]) else return 0 end self.redis.eval( lua_script, 1, self.lock_key, self.lock_value, str(self.timeout_ms) ) self._watchdog_thread threading.Thread( target_watchdog_loop, daemonTrue, namefwatchdog-{self.lock_key} ) self._watchdog_thread.start() def _stop_watchdog_event(self) - None: 停止看门狗线程 self._stop_watchdog.set() if self._watchdog_thread and self._watchdog_thread.is_alive(): self._watchdog_thread.join(timeout2.0) class Redlock: Redlock 算法实现在多个独立 Redis 实例上获取锁 只有在大多数实例上获取成功才视为锁获取成功。 def __init__(self, redis_clients: List[redis.Redis], lock_key: str, timeout_ms: int 30000): self.clients redis_clients self.lock_key lock_key self.timeout_ms timeout_ms self.quorum len(redis_clients) // 2 1 self.lock_value str(uuid.uuid4()) def acquire(self, retry_count: int 3, retry_delay_ms: int 200) - bool: 在所有 Redis 实例上尝试获取锁。 成功条件在超过半数实例上获取成功 且总耗时不超过锁的有效时间。 for _ in range(retry_count): acquired_count 0 start_time time.monotonic() for client in self.clients: try: result client.set( self.lock_key, self.lock_value, nxTrue, pxself.timeout_ms ) if result: acquired_count 1 except redis.RedisError: # 单节点故障不影响整体流程 continue elapsed_ms (time.monotonic() - start_time) * 1000 # 锁的有效时间需要扣除获取锁的耗时 validity self.timeout_ms - elapsed_ms if acquired_count self.quorum and validity 0: return True # 获取失败清理已获取的锁 self._release_acquired() if _ retry_count - 1: time.sleep(retry_delay_ms / 1000.0) return False def release(self) - None: 在所有实例上释放锁 self._release_acquired() def _release_acquired(self) - None: 在所有实例上尝试释放锁 lua_script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end for client in self.clients: try: client.eval(lua_script, 1, self.lock_key, self.lock_value) except redis.RedisError: # 释放失败记录日志但不阻塞流程 continue # ---- 使用示例 ---- if __name__ __main__: r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) # 单节点分布式锁 lock RedisDistributedLock(r, order:12345:lock, timeout_ms30000) if lock.acquire(): try: # 执行需要互斥保护的业务逻辑 print(锁获取成功执行业务逻辑...) finally: lock.release() else: print(锁获取失败请稍后重试)上述实现的关键设计决策包括使用 UUID 作为锁的唯一标识防止误删、Lua 脚本保证检查与删除的原子性、看门狗线程定期续约防止业务未完成锁已过期、Redlock 算法在多节点上获取锁并扣除获取耗时。四、Redis 分布式锁的边界条件与架构权衡4.1 时钟漂移问题Redlock 算法依赖各 Redis 实例的本地时钟来计算锁的有效时间。如果某个实例的时钟发生跳变如 NTP 同步可能导致锁提前过期或延迟释放。在跨数据中心的部署场景中时钟漂移的影响更为显著。应对策略确保所有 Redis 实例使用 NTP 同步并设置合理的过期时间缓冲。对于时钟敏感度极高的场景应考虑使用基于租约Lease的方案替代。4.2 网络分区下的行为当客户端与部分 Redis 实例之间的网络中断时Redlock 可能出现以下情况客户端在多数实例上获取了锁但无法与其中某些实例通信来释放锁。这会导致锁在这些实例上一直保持到过期在此期间其他客户端无法在这些实例上获取锁。应对策略设置合理的锁过期时间确保即使释放失败锁也会自动过期。过期时间应根据业务最长执行时间设置不宜过长也不宜过短。4.3 性能开销对比方案获取锁延迟可靠性适用场景单节点 SET NX~0.1ms单点故障风险对可靠性要求不高的场景Redis Sentinel SET NX~1ms主从切换可能丢锁中等可靠性要求Redlock3 节点~3ms多数派一致高可靠性要求Redlock5 节点~5ms更高容错金融级场景4.4 何时不应使用 Redis 分布式锁Redis 分布式锁不适合以下场景第一需要严格线性一致性的场景——应使用基于共识协议如 Raft的分布式协调服务如 etcd、ZooKeeper第二锁持有时间极长的场景——Redis 是内存数据库锁信息在重启后丢失第三高频锁竞争场景——Redis 的网络往返开销会成为瓶颈应考虑本地锁或无锁设计。五、总结Redis 分布式锁是分布式系统中解决资源互斥访问的常用方案但其工程实现远比SET NX复杂。核心要点如下第一锁的释放必须使用 Lua 脚本保证检查-删除的原子性否则会误删其他客户端的锁。第二看门狗续约机制是解决业务执行时间不确定性的关键续约时同样需要验证锁的持有者身份。第三Redlock 算法通过多节点多数派一致来提升可靠性但引入了时钟依赖和网络开销需要在可靠性与性能之间权衡。第四锁的过期时间设置需要兼顾业务最长执行时间和故障恢复时间过长影响故障恢复速度过短可能导致业务未完成锁已过期。第五对于需要严格线性一致性的场景应选择 etcd 或 ZooKeeper 等基于共识协议的方案而非 Redis 分布式锁。