Redis 分布式锁上线前要先想清楚它解决什么问题分布式锁很容易被写成一段固定模板先用 Redis 设置一个带过期时间的键业务结束后删除。这样在简单场景里看似能跑但它真正进入多实例、慢请求、故障转移和重试链路后很多假设都会失效。最常见的不是“锁完全没用”而是锁的适用边界没有被说明业务把它当成了比它更强的一致性保证。因此讨论 Redis 分布式锁时不宜只比较命令、客户端和算法名称。更重要的问题是临界区到底是什么业务能否容忍偶发并发锁失效后怎样避免旧执行者继续写入底层 Redis 的部署与故障模式是什么。答案不同方案也不同。先确认是否真的需要分布式锁并发控制并非总要从锁开始。某些问题可以由数据库唯一约束、条件更新、幂等键、队列顺序或领域状态机更直接地处理。例如防止重复提交通常需要服务端幂等语义库存扣减需要可靠的数据一致性规则任务重复执行则可能需要可恢复的任务状态。仅靠一把外部锁很难替代这些基础保证。只有当多个进程确实需要在一段有限时间内协调某个共享资源并且现有数据层无法表达这个约束时才值得引入分布式锁。开始前要写清资源标识如何生成、锁保护哪段操作、持锁者失败后会怎样、未拿到锁的请求如何处理。若这些问题没有答案代码里多加一个锁键也不会让业务更安全。锁的粒度也要谨慎。粒度太粗会把无关请求排成队拖慢整个服务粒度太细又可能遗漏相互影响的操作。用业务对象或明确的操作范围作为锁键比用一个全局“业务锁”更容易理解和维护。加锁与释放必须围绕同一个持有者Redis 键应具有过期时间避免进程崩溃后永久占用资源创建键与设置过期也需要以原子方式完成避免在两步之间留下无法自动释放的状态。更关键的是锁值应带有随机且不可预测的持有者标识而不是简单写一个固定字符串。释放时不能直接删除键。锁可能已到期并被另一请求重新获取旧请求若无条件删除会把新持有者的锁删掉。安全的释放方式是先比较键中的持有者标识只有匹配时才删除比较与删除之间也不能留出竞态窗口因此应由 Redis 原子执行。具体可以使用服务端脚本或项目使用的客户端能力实现但要保证语义是“我只能释放我拿到的那把锁”。业务代码还应确保异常路径会走到释放逻辑。无论是返回、抛错还是取消都不能依赖开发者每次手工记得调用。即便如此释放失败也不是可以静默忽略的事件它可能意味着锁已失效、Redis 不可用或持有关系发生了变化应该留下适合排查的记录。过期时间不是一个万能参数锁设置过期是必要的但“设多久”不能靠拍脑袋。太短时业务尚未完成锁已失效其他请求可能进入同一临界区太长时异常后的等待时间增加。更根本的问题是客户端无法保证业务一定在某个时间内结束暂停、资源争抢、下游变慢和网络异常都可能让实际时间偏离预期。自动续期能减少长时间任务因初始过期时间过短而失效的情况。一些客户端提供了类似看门狗的机制在确认自己仍持有锁时延长存活时间。使用这类机制前要先理解它的条件续期线程或进程一旦暂停、与 Redis 失去连接锁仍可能到期续期成功也不代表业务写入一定安全。它只是延长持有时间并没有消除分布式系统中的不确定性。对于有明确上限的短操作固定租约可能反而更容易推理。对于可能很长的任务需要评估自动续期、取消策略和工作拆分是否合理。无论选择哪一种都应让业务在失去锁后停止继续执行或拒绝后续写入不能默认“我开始时拿到过锁所以现在仍可写”。用版本或栅栏保护真正的资源仅知道“曾经持有锁”往往不够。设想一个请求因为暂停错过了锁的过期另一个请求已经取得新锁并更新资源旧请求恢复后仍继续写入就可能覆盖新结果。即使它没有误删锁也可能造成业务错误。需要更强保护的场景应在受保护资源侧建立能够拒绝旧持有者的规则。常见思路是为每次成功获取分配单调递增的标识资源写入时只接受不旧于当前记录的标识。这个概念通常被称为栅栏令牌。它不是所有业务都必须实现但它提醒我们锁服务与实际数据写入之间仍有一道必须由资源所有者执行的校验。数据库条件更新、乐观版本号和消息去重也是类似的保护方式。选择哪种取决于资源所在位置和业务语义。不要把 Redis 锁当作唯一的正确性防线特别是在资金、库存、状态迁移等不能容忍冲突的链路上。主从切换和多节点算法要如实评估Redis 主从复制通常不是同步完成的。发生故障切换时最近一次写入不一定已经出现在新主节点上因此锁状态可能与客户端观察不一致。这并不意味着 Redis 锁完全不能使用而是意味着它不能被宣传为在所有故障条件下都提供绝对互斥。多节点加锁方案试图通过多个独立实例降低单点故障影响但它们同样依赖时钟、网络延迟和客户端行为等假设。社区对于这些方案的适用范围存在不同观点不能把某个算法名称当成“强一致”的替代品。若业务确实要求在故障和网络分区下保持严格协调应评估提供更强一致语义的协调系统或将约束放到能执行最终校验的数据层。架构选择应由风险决定而不是由技术名气决定。可以容忍偶发重复执行、且具备幂等与补偿机制的任务要求与资金结算或不可逆状态变更完全不同。将它们使用同一套锁策略通常是不负责任的简化。把监控和演练纳入交付上线前应验证正常获取、竞争失败、业务超时、客户端崩溃、Redis 短暂不可达和锁已失效等情况。观察日志时不要记录敏感业务内容但应能关联资源标识、请求状态、持有时长和失败原因。没有这些信息线上出现排队或重复执行时很难判断问题在哪一层。还要留意等待与重试。无上限的自旋会在竞争激烈时消耗资源无差别重试会放大下游故障。应由业务定义等待预算、失败反馈和降级方式而不是让锁客户端无限尝试。Redis 分布式锁是一个协调工具不是正确性的魔法开关。持有者身份可验证、过期与续期语义清楚、实际资源有防旧写保护、故障边界被如实评估才能让它在适合的场景里发挥作用。 Redis 分布式锁上线前，要先想清楚它解决什么问题
Redis 分布式锁上线前要先想清楚它解决什么问题分布式锁很容易被写成一段固定模板先用 Redis 设置一个带过期时间的键业务结束后删除。这样在简单场景里看似能跑但它真正进入多实例、慢请求、故障转移和重试链路后很多假设都会失效。最常见的不是“锁完全没用”而是锁的适用边界没有被说明业务把它当成了比它更强的一致性保证。因此讨论 Redis 分布式锁时不宜只比较命令、客户端和算法名称。更重要的问题是临界区到底是什么业务能否容忍偶发并发锁失效后怎样避免旧执行者继续写入底层 Redis 的部署与故障模式是什么。答案不同方案也不同。先确认是否真的需要分布式锁并发控制并非总要从锁开始。某些问题可以由数据库唯一约束、条件更新、幂等键、队列顺序或领域状态机更直接地处理。例如防止重复提交通常需要服务端幂等语义库存扣减需要可靠的数据一致性规则任务重复执行则可能需要可恢复的任务状态。仅靠一把外部锁很难替代这些基础保证。只有当多个进程确实需要在一段有限时间内协调某个共享资源并且现有数据层无法表达这个约束时才值得引入分布式锁。开始前要写清资源标识如何生成、锁保护哪段操作、持锁者失败后会怎样、未拿到锁的请求如何处理。若这些问题没有答案代码里多加一个锁键也不会让业务更安全。锁的粒度也要谨慎。粒度太粗会把无关请求排成队拖慢整个服务粒度太细又可能遗漏相互影响的操作。用业务对象或明确的操作范围作为锁键比用一个全局“业务锁”更容易理解和维护。加锁与释放必须围绕同一个持有者Redis 键应具有过期时间避免进程崩溃后永久占用资源创建键与设置过期也需要以原子方式完成避免在两步之间留下无法自动释放的状态。更关键的是锁值应带有随机且不可预测的持有者标识而不是简单写一个固定字符串。释放时不能直接删除键。锁可能已到期并被另一请求重新获取旧请求若无条件删除会把新持有者的锁删掉。安全的释放方式是先比较键中的持有者标识只有匹配时才删除比较与删除之间也不能留出竞态窗口因此应由 Redis 原子执行。具体可以使用服务端脚本或项目使用的客户端能力实现但要保证语义是“我只能释放我拿到的那把锁”。业务代码还应确保异常路径会走到释放逻辑。无论是返回、抛错还是取消都不能依赖开发者每次手工记得调用。即便如此释放失败也不是可以静默忽略的事件它可能意味着锁已失效、Redis 不可用或持有关系发生了变化应该留下适合排查的记录。过期时间不是一个万能参数锁设置过期是必要的但“设多久”不能靠拍脑袋。太短时业务尚未完成锁已失效其他请求可能进入同一临界区太长时异常后的等待时间增加。更根本的问题是客户端无法保证业务一定在某个时间内结束暂停、资源争抢、下游变慢和网络异常都可能让实际时间偏离预期。自动续期能减少长时间任务因初始过期时间过短而失效的情况。一些客户端提供了类似看门狗的机制在确认自己仍持有锁时延长存活时间。使用这类机制前要先理解它的条件续期线程或进程一旦暂停、与 Redis 失去连接锁仍可能到期续期成功也不代表业务写入一定安全。它只是延长持有时间并没有消除分布式系统中的不确定性。对于有明确上限的短操作固定租约可能反而更容易推理。对于可能很长的任务需要评估自动续期、取消策略和工作拆分是否合理。无论选择哪一种都应让业务在失去锁后停止继续执行或拒绝后续写入不能默认“我开始时拿到过锁所以现在仍可写”。用版本或栅栏保护真正的资源仅知道“曾经持有锁”往往不够。设想一个请求因为暂停错过了锁的过期另一个请求已经取得新锁并更新资源旧请求恢复后仍继续写入就可能覆盖新结果。即使它没有误删锁也可能造成业务错误。需要更强保护的场景应在受保护资源侧建立能够拒绝旧持有者的规则。常见思路是为每次成功获取分配单调递增的标识资源写入时只接受不旧于当前记录的标识。这个概念通常被称为栅栏令牌。它不是所有业务都必须实现但它提醒我们锁服务与实际数据写入之间仍有一道必须由资源所有者执行的校验。数据库条件更新、乐观版本号和消息去重也是类似的保护方式。选择哪种取决于资源所在位置和业务语义。不要把 Redis 锁当作唯一的正确性防线特别是在资金、库存、状态迁移等不能容忍冲突的链路上。主从切换和多节点算法要如实评估Redis 主从复制通常不是同步完成的。发生故障切换时最近一次写入不一定已经出现在新主节点上因此锁状态可能与客户端观察不一致。这并不意味着 Redis 锁完全不能使用而是意味着它不能被宣传为在所有故障条件下都提供绝对互斥。多节点加锁方案试图通过多个独立实例降低单点故障影响但它们同样依赖时钟、网络延迟和客户端行为等假设。社区对于这些方案的适用范围存在不同观点不能把某个算法名称当成“强一致”的替代品。若业务确实要求在故障和网络分区下保持严格协调应评估提供更强一致语义的协调系统或将约束放到能执行最终校验的数据层。架构选择应由风险决定而不是由技术名气决定。可以容忍偶发重复执行、且具备幂等与补偿机制的任务要求与资金结算或不可逆状态变更完全不同。将它们使用同一套锁策略通常是不负责任的简化。把监控和演练纳入交付上线前应验证正常获取、竞争失败、业务超时、客户端崩溃、Redis 短暂不可达和锁已失效等情况。观察日志时不要记录敏感业务内容但应能关联资源标识、请求状态、持有时长和失败原因。没有这些信息线上出现排队或重复执行时很难判断问题在哪一层。还要留意等待与重试。无上限的自旋会在竞争激烈时消耗资源无差别重试会放大下游故障。应由业务定义等待预算、失败反馈和降级方式而不是让锁客户端无限尝试。Redis 分布式锁是一个协调工具不是正确性的魔法开关。持有者身份可验证、过期与续期语义清楚、实际资源有防旧写保护、故障边界被如实评估才能让它在适合的场景里发挥作用。