Redis CLIENT NO-EVICT 怎么保护关键连接：内存压力下的连接级淘汰边界

线上 Redis 的缓存数据把内存顶到高位时，最怕连监控连接也被清掉：业务还在跑，告警通道却先断了。Redis 7.0 起可以给当前连接打开 CLIENT NO-EVICT ON，让它不进入客户端淘汰候选集；不过前提是服务端启用了 maxmemory-clients，而且这个命令保护的是连接，不是缓存键。

要保护一条控制路径，先在这条连接上执行 CLIENT NO-EVICT ON 并确认返回 OK；内存治理仍要靠 maxmemory-clients、连接池上限和键淘汰策略共同完成。

先分清客户端淘汰和键淘汰

Redis 有两条容易混淆的内存路径。键淘汰发生在缓存数据超过 maxmemory 后，受 maxmemory-policy 影响；客户端淘汰则针对连接本身累计的输出缓冲等客户端内存，受 maxmemory-clients 约束。CLIENT NO-EVICT 只参与后者。

因此，给监控连接加了保护，并不等于业务键不会被 LRU、LFU 或 TTL 策略淘汰。它解决的是“内存压力下控制连接还能不能留下来”这个更窄的问题。

用一条控制连接打开保护

假设 redis-cli 这条连接承担健康检查和 INFO 采集。保护必须在这条连接里执行，换一个终端重新连接并不会继承状态。

redis-cli
127.0.0.1:6379> CLIENT NO-EVICT ON
OK
127.0.0.1:6379> CLIENT NO-EVICT OFF
OK

上面先展示完整的开关动作，生产上不要为了验证而立刻关闭；真正使用时执行 ON 后，把这条连接交给监控进程复用。命令复杂度是 O(1)，返回 OK 只说明参数合法且当前连接状态已切换。图中的“排除淘汰”指当前连接不再参与客户端淘汰候选，不是把整个实例的淘汰机制关闭。

再核对 maxmemory-clients 是否真的打开

如果服务端的 maxmemory-clients 仍是默认的 0，客户端淘汰机制本来就没有限制值，NO-EVICT 不会凭空制造一套内存上限。先读取当前值，再决定是否调整。

127.0.0.1:6379> CONFIG GET maxmemory-clients
1) "maxmemory-clients"
2) "5%"
127.0.0.1:6379> CLIENT LIST
id=18 addr=127.0.0.1:54321 name=control-path ...

示例中的 5% 只是配置示例，不是所有实例都适合的固定答案。它可以是字节数，也可以是相对 maxmemory 的百分比；连接池、订阅连接和大响应接口都要计入预算。控制连接还需要通过 CLIENT SETNAME control-path 起一个可识别名字，方便在 CLIENT LIST 中找到它。

三个结果能说明什么

返回 OK，不代表所有连接都被保护

CLIENT NO-EVICT 是当前连接级设置。应用的连接池通常包含多条连接，必须在负责告警、健康检查或故障切换的控制连接建立后执行一次，不能只在人工终端里验证。

保护控制连接，不代表键还会保留

如果 maxmemory 触发了键淘汰，业务缓存仍可能按照 maxmemory-policy 变化。排查时把 INFO memory、键空间指标和客户端连接指标分开看。

Redis Cloud 或 Redis Software 不能照搬

Redis 官方命令参考页标注，标准 Redis Cloud 与 Redis Software 的兼容性并不等同于 Redis Open Source。托管服务先看产品兼容矩阵，不要只凭本地 Redis 7.x 的测试结果下结论。

上线前的最小验收清单

1. 确认控制连接执行 CLIENT NO-EVICT ON 后返回 OK。
2. 用 CLIENT SETNAME control-path 命名，并在 CLIENT LIST 找到相同连接。
3. 读取 CONFIG GET maxmemory-clients，记录是 0、字节数还是百分比。
4. 分别观察客户端内存预算与键淘汰指标，确认没有把两种淘汰混成一个告警。

相关问题

CLIENT NO-EVICT OFF 会发生什么？

当前连接重新回到可能被客户端淘汰的候选范围；它不会断开连接，也不会修改键淘汰策略。

副本连接需要设置吗？

副本与主节点连接本身不受普通客户端淘汰机制影响；应用控制连接是否需要保护，仍应按它连接到的实例和产品形态核对。

可以用它替代连接池限流吗？

不可以。它只排除特定连接，不能限制连接总数、响应缓存大小或订阅客户端数量。

小结

CLIENT NO-EVICT 的价值在于给监控、控制或故障处理连接留一条更稳定的路径。正确顺序是：识别连接、在连接内打开 ON、核对 maxmemory-clients，再把客户端内存和键淘汰分开监控。这样既不会高估命令的保护范围，也能在连接压力出现时留下可用的诊断入口。