Redis CLIENT PAUSE 如何做维护窗口：WRITE、READ 隔离与恢复验收

Redis 做主从切换、实例升级或连接迁移时，最怕的是维护动作已经开始，旧主节点仍悄悄接收写入。CLIENT PAUSE 可以把客户端请求暂时挡在 Redis 入口，但它不是一把无条件的“全局锁”：WRITE 只拦写命令，ALL 连读命令也一起暂停，恢复则要明确执行 CLIENT UNPAUSE 或等待超时。

维护窗口优先评估 CLIENT PAUSE WRITE：让读请求继续提供服务，同时阻止新的写入；只有确实需要读写一起静止时，才考虑 ALL，并把超时、恢复和客户端重试写进验收步骤。

先把维护目标拆成“停写”还是“读写都停”

CLIENT PAUSE 的语法是：

CLIENT PAUSE timeout [WRITE | ALL]
CLIENT UNPAUSE

timeout 以毫秒计。ALL 是全暂停模式，会阻塞客户端发来的读写命令；WRITE 只在客户端尝试写入时阻塞。两者都影响连接上的请求处理，而不是把 Redis 进程关掉，副本之间的复制交互仍可继续。

维护目标不同，选择也不同。升级前需要确保旧主不再接收写入，通常先评估 WRITE；如果要让某段数据在切换期间保持完全静止，才有理由使用 ALL。这里别急着照抄网上的“暂停几秒”，时间必须覆盖实际切换动作，并留出恢复检查的余量。

用 WRITE 模式保护切换中的写入边界

假设应用连接名为 order-writer，维护动作要把业务写入切到新主。可以先在维护脚本中发出：

CLIENT PAUSE 15000 WRITE

服务端会尽快对这条管理命令返回 OK，随后尝试执行写命令的客户端进入暂停状态。读请求仍可能返回，因此前端不一定立刻“全站无响应”；这正是 WRITE 适合短切换窗口的原因。

验收不要只执行一次 SET。至少准备一个只读检查和一个写入检查：只读请求应符合当前切换策略，新的写入应被阻塞或由客户端超时处理。应用侧要区分“Redis 暂停导致的超时”和“网络断开”，否则重试逻辑可能在旧主恢复瞬间补写一批过期请求。

GET switch:state
SET switch:probe paused-write

如果切换动作提前完成，可以主动恢复，而不是等 15 秒自然到期：

CLIENT UNPAUSE

ALL 模式为什么更容易造成恢复时的拥塞

CLIENT PAUSE 8000 ALL 会把读写请求都挡住。暂停期间，客户端仍可能持续向连接写入请求数据；时间到后，这些积累的请求会重新进入处理流程，瞬间恢复并不等于平滑恢复。

因此 ALL 更适合有明确静默窗口、客户端连接数可控、且已经设计好超时与退避的场景。连接池很大时，恢复时要重点观察请求堆积、应用线程池和 Redis 延迟。不能把“命令返回 OK”理解成“所有业务连接都已完成排空”。

把暂停、切换、恢复串成可回放的步骤

1. 记录旧主节点、复制状态、客户端连接数和维护开始时间。
2. 执行 CLIENT PAUSE 15000 WRITE，保存返回值，不要重复发送多个暂停命令。
3. 确认写入路径不再接受新请求，再完成副本提升或连接配置切换。
4. 在新主上执行一组固定的读写探针，确认目标 key 的结果来自预期节点。
5. 执行 CLIENT UNPAUSE，观察暂停连接是否恢复，检查应用重试队列是否出现重复提交。

这组顺序的关键是“先停新写入，再切换，再验收，再恢复”。如果切换动作本身失败，应优先恢复可用路径并保留暂停时的探针结果；不要为了赶时间直接把旧主重新开放写入而跳过数据一致性核对。

相关问题

CLIENT PAUSE 会暂停 Redis 副本复制吗？

官方说明中，客户端暂停不会阻止副本交互正常进行。它控制的是客户端命令处理，不等同于暂停复制链路。

WRITE 模式会放过所有非写命令吗？

不要把它理解成简单的命令字符串过滤。官方文档列出了一些特殊行为，例如脚本、发布和 WAIT 在 WRITE 模式下有额外处理，具体版本应以目标实例文档核对。

到达 timeout 后还需要 CLIENT UNPAUSE 吗？

超时会解除暂停；如果维护提前结束，主动执行 CLIENT UNPAUSE 能让恢复动作更明确，也便于把恢复点写进变更记录。

为什么执行 CLIENT PAUSE 后还有请求日志？

暂停命令自身会尽快返回，非活跃客户端也可能尚未尝试执行命令。还要区分读请求、管理连接、复制交互和暂停前已经进入处理流程的命令。

维护结束后的最小验收清单

最后检查四件事：旧主没有继续接收业务写入；新主能够完成固定探针；CLIENT UNPAUSE 已执行或暂停已自然到期；应用端没有因集中恢复产生重复写入。只有这四项都能在日志、命令返回和业务探针中对上，才算完成一次可控的 Redis 维护窗口。