# 

一批定时任务在凌晨集体停摆，日志停在「正在获取锁」，之后什么都没有。

登录缓存实例查看，那把锁的键存在，值也正常，但没有过期时间。也就是说，它会一直存在，直到有人手动删。

## 那次发生了什么？

那把锁由当天下午发布时的某个实例创建。滚动重启把那个实例杀了，正好杀在「设置键」成功之后、「设置过期时间」执行之前。

两行代码之间，有一段没人管的时间。进程恰好死在这段里，锁就再也不会自己消失。

后续所有实例来抢锁，得到的都是「已被占用」，于是整批任务停在那里，等一个永远不会到来的释放。

## 两行代码之间有什么窗口？

头一行是「键不存在才设置」，成功说明抢到了锁；第二行是「给这个键设置过期时间」。

这两条命令是两次独立的网络往返。中间那段时间里，键已存在，却没有过期时间。

| 时间点 | 发生了什么 | 结果 |
| --- | --- | --- |
| 一 | 设置键成功 | 锁被持有，但无过期时间 |
| 二 | 进程被杀或网络断开 | 设置过期时间的命令永不执行 |
| 三 | 之后所有尝试 | 一直返回占用 |

时间点二能触发的情况比想象的多：进程被强制结束、容器被驱逐、客户端超时、网络闪断，以及云上特有的主备切换。

## 云上的主备切换为什么更危险？

云数据库与缓存服务通常提供高可用版：一个主节点加一个或多个备节点，主节点故障时自动切换。

切换过程中有两个时间窗口需要关心。

第一个是「写入未同步」。设置键的请求写到了主节点，主节点在同步给备节点之前挂了，备节点升为主节点——锁就不存在了，两个客户端可能同时认为自己持有锁。

第二个是「同步了键但没同步过期时间」。键存在而到期时间没跟上，就变成永久锁。

| 切换时的状态 | 结果 | 影响 |
| --- | --- | --- |
| 键未同步 | 锁消失 | 可能两个客户端同时持锁 |
| 键同步、过期时间未同步 | 永久锁 | 任务全部阻塞 |
| 两者都未同步 | 锁不存在 | 与第一行相同 |
| 客户端的连接未重建 | 命令失败 | 需要客户端重连重试 |

这也是所有基于缓存的锁的共同局限：主从复制是异步的，切换点上的状态不确定。指望靠写法消除这个窗口不现实，只能接受它并做好兜底。

## 用事务包起来为什么不行？

很多人的头一个反应是用事务把两条命令包起来。

这解决了「原子提交」，但没解决「条件执行」。事务的语义是把命令排队、一起执行，而队列里的命令在入队时拿不到执行结果。所以设置过期时间那一步无论如何都会执行，即使抢锁失败。

结果比原来更糟：抢锁失败的一方，把别人正在持有的锁的过期时间改掉了。

| 写法 | 是否原子 | 失败时会不会改掉别人过期时间 |
| --- | --- | --- |
| 两行命令依次执行 | 否，中间有窗口 | 不会，第二步不执行 |
| 事务包两条 | 提交层面是 | 会，第二步无条件执行 |
| 一条命令带两个选项 | 是 | 不会，整体不生效 |

## 一条命令怎么写？

缓存服务的主设置命令支持条件与过期两个选项。官方文档对这两个选项的说明是：

> NX: Only set the key if it does not already exist.

> EX seconds: Set the specified expire time, in seconds (a positive integer).

「只在键不存在时设置它」「设置过期时间，单位为秒」。

两个选项可以同时用。文档里还有一句直接说明了替代关系：

> Note: Since the SET command options can replace SETNX, SETEX, PSETEX, GETSET, it is possible that in future versions of Redis these commands will be deprecated and finally removed.

「由于主设置命令的选项可以替代那几个老命令，将来它们有可能被弃用并最终移除。」

这条能力不是一开始就有，是某个较早版本之后才加入的。所以那些老代码里的窗口不是疏忽，是当年的唯一选择。

## 返回值怎么判断？

带条件选项的 SET，返回值和普通 SET 不同。文档的返回说明写了两类：键已存在而指定了条件时返回空回复；其余情况返回成功。

落到代码里是三种：

| 返回 | 含义 | 处理方式 |
| --- | --- | --- |
| 成功 | 抢到了锁 | 继续执行业务 |
| 空回复 | 锁被别人持有 | 重试或放弃，不当异常 |
| 抛异常 | 连接层问题 | 按失败处理，绝不能当成功 |

第三行的坑在于：某些客户端超时返回空，而空恰好也是「没抢到」的语义。于是「网络超时」与「锁被占用」在返回值上分不开——这也是必须配合持有者校验的原因。

## 释放锁为什么不能直接删？

因为持有者可能已经变了。

一个实例抢到锁，过期时间三十秒，业务跑了三十五秒，锁自动过期，另一个实例抢到。这时头一个实例执行完直接删，删掉的是别人的锁。

接着第三个实例又能抢到，于是两个实例同时执行。

正确做法是「先核对持有者再删」，且核对与删除也要原子。常见写法是把判断与删除放进一段服务端脚本里执行，服务保证单段脚本不会被插入其他命令。

需要说明的是：核对持有者不是缓存文档里的规定，而是分布式锁的通行做法。官方对条件设置的说明只覆盖怎么设置，不覆盖怎么释放。

## 过期时间怎么定？

这是分布式锁两头都难的地方。

| 设置方式 | 优点 | 风险 |
| --- | --- | --- |
| 短过期时间 | 崩溃后恢复快 | 业务没跑完就失效 |
| 长过期时间 | 不会中途失效 | 崩溃后长时间不可用 |
| 按执行时间推算 | 兼顾两者 | 需要准确的耗时统计 |

我们的做法是按执行时间的九十九分位乘三到五倍来设，同时给业务加超时，让它一定在锁过期前结束。

如果业务耗时不可预测，就需要续期。而续期会引入新的复杂度：谁来续、续多久、续的时候锁还是不是自己的。

## 云上部署还该补什么？

三点。

第一，监控「锁的存活时间」。如果某把锁的存在时间明显超过业务上限，说明有人在续期或者根本没释放。

第二，加告警。锁的等待队列长度、获取失败次数、平均等待时长，三个指标能提前发现异常。

第三，准备人工兜底。留一个可以按业务维度强制释放锁的入口，并记录操作人与原因。这次故障最后就是靠它恢复的。

这套锁的实现要点我整理进了项目的分布式组件说明，最早散在几次「任务卡死」的排查记录里，用 AI墨衍 把其中的判断依据归拢成按「环节、正确做法、出错后果」三列排的表。

## 小结

三句话：两条命令不是一步，事务不能条件执行，主备切换会留下不确定状态。

判断一把锁可靠不可靠，先看它在最坏的中断点上会留下什么：一个带过期时间的键，还是一个永远不释放的键。


登录缓存实例查看，那把锁的键存在，值也正常，但没有过期时间。也就是说，它会一直存在，直到有人手动删。

云上缓存实例切换主节点之后，那把锁永久卡住了

后端

数据库

云计算

一批定时任务凌晨集体停摆，日志停在「正在获取锁」，原因是下午发布的实例在设置键后、设置过期时间前被杀，锁成为永久占用。云主备切换加剧风险，两行命令需用SET NX EX原子执行，释放时校验持有者，过期时间按业务耗时99分位设3-5倍，并监控锁存活与等待队列。

云数据库

容器

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

云上缓存实例切换主节点之后，那把锁永久卡住了-腾讯云开发者社区-腾讯云

云上缓存实例切换主节点之后，那把锁永久卡住了

云上缓存实例切换主节点之后，那把锁永久卡住了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐