首页/数据/Redis 进阶速查/CLIENT UNPAUSE 解除暂停
性能与排障129 条

CLIENT UNPAUSE 解除暂停

CLIENT UNPAUSE 立即恢复被 CLIENT PAUSE 挂起的命令处理,用于提前结束暂停窗口。

Redis 进阶速查数据更新于 2026-10-13

CLIENT UNPAUSE 是什么

CLIENT UNPAUSE 用于立即结束一次 CLIENT PAUSE 造成的命令暂停,让被推迟的客户端命令马上恢复处理。CLIENT PAUSE 的执行方式是「挂起」而不是「拒绝」:暂停期间客户端发来的命令不被执行也不被丢弃,连接同样不断开,命令一直排队等到窗口结束。这套机制最典型的用途是主从切换——先冻住旧主的写入,等从库追平、新主提升完成、流量切换过去,再放行。UNPAUSE 就是切换脚本的收尾动作:当切换提前完成时,不必干等到 timeout 到期。该命令自 Redis 6.2 提供,6.2 之前只能等暂停窗口自然结束。

基本信息

命令语法CLIENT UNPAUSE(无参数、无选项)
适用版本Redis 6.2 及以上;6.2 之前没有这条命令
作用范围节点级:只解除执行它的那个实例上的暂停
返回值OK;不报告被放行的客户端数量
权限要求管理类子命令,仅授 +@read/+@write 的 ACL 用户会被 NOPERM 拒绝
配套命令CLIENT PAUSE 设置暂停窗口,CLIENT LIST 观察连接状态

典型使用场景

  • 计划内主从切换:暂停旧主写入,提升完成后立刻解除,把「不可写」窗口压到最短
  • 哨兵或手工故障转移脚本:把暂停窗口设成兜底的大值,脚本按实际进度提前收尾
  • 维护窗口:重启从库、迁移大 key 前暂停写入,操作完立即恢复,不必按固定 timeout 干等
  • 切换演练与压测:验证应用在暂停期间是排队还是误判为故障,确认恢复后的行为可接受
  • 自动化脚本幂等收尾:不管中间走了哪个分支,最后统一执行一次 UNPAUSE
  • 误操作恢复:有人把暂停的 timeout 设得过长,确认业务安全后立即解除

切换脚本中的用法

切换脚本中的用法
redis-cli -h 10.0.0.1 CLIENT PAUSE 60000 ALL        # 冻住旧主,窗口仅作兜底
redis-cli -h 10.0.0.2 INFO replication               # 确认从库 offset 已追平旧主
redis-cli -h 10.0.0.2 REPLICAOF NO ONE               # 把从库提升为新主
redis-cli -h 10.0.0.2 CLIENT PAUSE 60000 ALL         # 新主先暂停,等客户端指向它
redis-cli -h 10.0.0.1 REPLICAOF 10.0.0.2 6379        # 旧主降级为新主的从库
redis-cli -h 10.0.0.1 CLIENT UNPAUSE                 # 确认已降级后再解除旧主暂停
redis-cli -h 10.0.0.2 CLIENT UNPAUSE                 # 客户端流量切完后解除新主暂停

PAUSE 与 UNPAUSE 对照

命令作用典型用途
CLIENT PAUSE <ms>暂停本节点全部客户端命令,读也被推迟切换窗口兜底,防止旧主继续处理写入
CLIENT PAUSE <ms> WRITE只推迟写命令,读命令照常返回切换期间尽量保住读可用性
CLIENT UNPAUSE立即解除本节点暂停,排队命令随之执行切换提前完成时收尾
暂停的表现是「发出去没回」,不是连接报错,很容易被当成网络抖动或慢查询。排查时先看 INFO clients 的连接数是否异常、CLIENT LIST 里各连接的 age 与 idle 是否集体变大,再确认最近有没有人执行过 CLIENT PAUSE。排队的命令会在解除后依次执行,顺序按各连接自己的发送顺序保持。
UNPAUSE 不会跨节点生效:主从、哨兵、集群环境下,哪个实例被暂停就要在哪个实例上解除,集群不会广播这条命令。多节点脚本应逐个实例执行并记录结果,避免漏掉的节点一直暂停到 timeout 到期。

恢复后核对

恢复后核对
redis-cli INFO replication      # 确认角色正确、master_link_status:up
redis-cli INFO clients          # 连接数是否回到暂停前水平
redis-cli CLIENT LIST | wc -l   # 抽样确认没有异常长 idle 的连接
redis-cli LATENCY LATEST        # 看恢复瞬间是否落下延迟事件
redis-cli SLOWLOG GET 10        # 看恢复后有没有成批出现的慢命令
务必确认旧主已经降级或已停止接受写入,再执行 UNPAUSE;否则旧主恢复处理写入就会与新主各自接受写入,造成双写和后续数据覆盖。另外恢复瞬间积压命令会集中执行,QPS 与延迟会出现尖刺,属于预期现象,但要用监控确认它没有拖垮下游。

易错点

  • 旧主还没降级就 UNPAUSE:旧主继续处理写入,与新主形成双写,切过去后数据互相覆盖,事前要确认角色已经变成从库
  • 把 UNPAUSE 当成「取消积压命令」的手段:它只恢复处理,不会丢弃已排队的命令,也不能只撤销某几条命令
  • 漏解暂停:暂停是节点级命令,集群或一主多从环境下只解除了一台,其余实例会一直卡到 timeout 到期,脚本要逐实例执行并记录结果
  • 长 timeout 加脚本异常退出:暂停会一直持续到窗口到期,客户端表现为「卡住但连接不断」,容易被误判为服务器或网络故障,应设较短 timeout 并在监控里加告警
  • 忽略恢复瞬间的压力峰值:积压命令集中执行会产生瞬时 QPS 与延迟尖刺,恢复后要查 LATENCY LATEST 与慢日志,别以为解除就万事大吉

数据来源与参考

  • Redis 官方文档:CLIENT UNPAUSE
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌