Redis 客户端驱逐与 noeviction 是两回事：CLIENT NO-EVICT 实战排障

线上 Redis 报写入异常的时候，最容易混淆的一类现场是：业务侧反馈内存满了写不进去，运维侧却看到有连接被主动清理，之后监控连接还断过一次。两类现象都和内存超限挂钩，但触发对象完全不一样。数据键的淘汰策略看 maxmemory-policy，客户端输出缓冲的驱逐看 maxmemory-clients，而 CLIENT NO-EVICT 只会保护当前这条连接。

你遇到的 CLIENT NO-EVICT 相关写入失败，基本都是数据集 OOM 报错和客户端驱逐两类故障链叠加导致的，先分开两条链路再逐个排查，不用上来就扩容整台主机内存。

先把两条 OOM 故障链分开

Redis 的 maxmemory 主要限制业务数据集使用的内存上限。当内存淘汰策略设为 noeviction，Redis 不会为了腾出空间自动删除现有键；所有会产生新数据的写入请求都可能收到内存不足报错，而读取已有键的请求仍然可以正常响应。这个错误的作用对象是“待写入的数据”，不是连接。

客户端驱逐是另外一层独立的保护机制。Redis 7.0 开始，maxmemory-clients 可以限制所有普通客户端连接累计占用的内存，输出缓冲堆积特别大的连接会被优先选中清理。CLIENT NO-EVICT ON 可以把当前连接排除在客户端驱逐候选名单之外，很适合监控、故障处理这类控制通道使用。

从现场时间线定位真正的触发条件

可以用一个常见的批量导出接口场景还原现场：上午缓存命中率一切正常，下午某个后台管理查询一次返回几十万集合成员，客户端输出缓冲持续暴涨；同一时间另一个业务的写入请求因为 maxmemory-policy noeviction 收到内存不足报错。两条日志打印时间挨得很近，但根因分别落在客户端连接资源占用和数据键写入限制两个完全独立的模块。

先记录报错发生的对应连接、执行命令和精确时间，再跑下面的只读检查操作，不要一看到 OOM 关键字就直接调大主机内存上限。

INFO memory
maxmemory
maxmemory_policy
maxmemory_clients_normal
used_memory
used_memory_dataset
mem_clients_normal

CONFIG GET maxmemory
CONFIG GET maxmemory-policy
CONFIG GET maxmemory-clients
CLIENT LIST

重点核对三组对应关系：used_memory 是否接近配置的 maxmemory，mem_clients_normal 是否逼近客户端内存限额，以及 CLIENT LIST 中是否存在输出缓冲明显偏大的异常连接。如果所用版本或者云托管环境不暴露某个配置项，就以实际返回的监控字段为准，不要把空返回直接当成零压力判定。

控制连接怎样启用 CLIENT NO-EVICT

保护动作必须从你想要保留的那条连接上直接发出：

CLIENT SETNAME redis-control
CLIENT NO-EVICT ON
CLIENT NO-EVICT OFF

命令返回 OK 只说明当前这条连接的免驱逐状态切换成功，不代表整个应用下所有连接都获得了保护资格。如果应用连接池里配置了多个控制连接，要在创建连接之后逐条单独设置，同时把连接名称写入监控维度方便后续排查。连接断开重建之后，这个免驱逐状态不会自动保留，要重新执行设置操作。

可被保护的连接范围要严格控制：报警上报、配置核对、健康检查这类低吞吐通道可以开免驱逐；高吞吐数据导出、订阅大量频道消息、长期不读取响应的连接不能靠免驱逐来兜底，否则一个本来就要被清理的慢消费者，会把多余的内存压力全部转嫁给整个 Redis 实例。

修复动作按压力来源落地

数据集占用接近 maxmemory

缓存场景可以评估 allkeys-lru、allkeys-lfu 或带 TTL 回收规则的策略，但要先确认业务侧哪些键是允许被自动删除的。持久化数据或者不能丢失的状态类数据，不能只靠更换淘汰策略解决，应该走实例拆分、降低单键体积或者迁移到更适配的存储引擎的方案。

客户端输出缓冲过大

先定位大响应的来源：大范围 SMEMBERS、未做分页的 XRANGE、长时间阻塞的订阅者都是高频可疑点。把全量返回改成结果分页、分批读取或者走专用离线导出连接，比无条件给所有连接开免驱逐要安全得多。

监控连接已经被驱逐

在连接初始化流程里提前设置连接名称并开启 CLIENT NO-EVICT ON，同时额外保留一条低频控制备用通道。第二通道不是为了让系统无限保留连接，而是为了在主控制连接异常断开的时候，你还能正常读取内存指标和限额配置。

回归验收与回退边界

修复完成之后不要只看业务侧报错消失就结束。用小批量测试请求复现之前的读写路径，观察 used_memory、mem_clients_normal 和连接存活时间的走势；再确认控制连接的名称、免驱逐状态和重连后的初始化逻辑是否符合预期。

• 数据写入还是报内存错误：优先检查数据限额和淘汰策略配置，不要反复尝试只设置 CLIENT NO-EVICT。
• 控制连接状态稳定但客户端内存持续上涨：优先处理慢消费者或者大响应请求，免驱逐本身不是清理内存的修复方案。
• 切换淘汰策略之后命中率或者数据完整性出现异常：立刻回退原有配置，先做实例拆分和键生命周期梳理再做后续调整。

常见问题

CLIENT NO-EVICT 能解决 Redis 的 OOM 错误吗？

不能直接解决。它只能保证当前连接不参与客户端驱逐的判定流程；数据写入因为 noeviction 被拒绝的时候，还是要处理底层的数据内存占用和淘汰策略问题。

开启 CLIENT NO-EVICT 后会不会让内存压力消失？

不会。被保护连接产生的访问压力还是会持续占用客户端内存配额，配置之后还要配合分页查询、访问限流、及时读取响应内容和连接上限管控一起生效。

配置了 maxmemory-clients 却没看到连接被清理？

先确认客户端内存限额配置值不是零，再检查连接类型、输出缓冲堆积情况和当前实际内存压力。复制连接等特殊类型的连接，不一定适用普通客户端驱逐规则。

控制连接断开重连后还需要重新设置吗？

需要。CLIENT NO-EVICT 是仅针对当前会话的临时状态，连接池新建连接的时候要重新设置并确认命令返回结果。

把“数据键不能淘汰”和“客户端连接被驱逐”两个场景分开之后，Redis OOM 排查就有了清晰的切入路径：先统计全量内存占用，再核对各连接状态，最后按照实际压力来源落地修复方案。控制通道值得针对性保护，但真正的根因修复永远是缩小数据集、限制大响应返回和规范管理连接生命周期。