Redis CLIENT NO-TOUCH 怎样避免访问键更新 LRU/LFU

如果一个 Redis 客户端主要做批量扫描、离线统计或后台检查，频繁读取大量键可能会改变这些键的 LRU/LFU 访问状态。CLIENT NO-TOUCH ON 可以让当前连接访问键时不更新这类触碰信息；任务结束后执行 CLIENT NO-TOUCH OFF，即可恢复该连接的默认行为。

它控制的是“当前客户端连接如何触碰访问统计”，不是删除键，也不是修改 Redis 的全局淘汰策略。官方命令地址：https://redis.io/docs/latest/commands/client-no-touch/

先分清访问触碰和淘汰策略

Redis 的 LRU/LFU 淘汰会参考键的访问相关信息，但“访问某个键时是否更新统计”和“实例最终采用哪种淘汰策略”是两件事。CLIENT NO-TOUCH 只改变前一件事：当前连接发出的访问命令，不再更新被访问键的 LRU/LFU 触碰状态。

因此它不会完成下面这些动作：

• 不会删除已经存在的键；
• 不会阻止其他客户端访问同一批键；
• 不会修改 maxmemory-policy 等全局配置；
• 不会把当前连接变成“只读连接”，写命令仍需遵守原有权限和命令语义。

CLIENT NO-TOUCH 的语法和作用域

命令只有两个状态：

# 在当前 redis-cli 连接上关闭访问触碰
redis-cli CLIENT NO-TOUCH ON

# 任务结束后恢复该连接的默认行为
redis-cli CLIENT NO-TOUCH OFF

官方文档给出的命令复杂度是 O(1)，命令本身返回 OK 表示切换请求被接受。ON 不是实例级开关，而是当前连接的状态；换一个客户端连接，不能假设它已经继承了上一个连接的设置。

可以把它理解成连接上的一个小开关：

怎样在受控连接上切换

最简单的做法是让后台任务独占一条连接，进入任务时打开 NO-TOUCH，任务结束时关闭。下面的命令序列只表达连接状态切换，不把它当作业务数据处理结果：

# 先打开当前连接的无触碰模式
redis-cli CLIENT NO-TOUCH ON

# 这里执行本次后台读取任务；读取结果仍由具体命令返回
redis-cli --scan --pattern 'report:*' | head -n 20

# 任务完成后显式恢复默认，避免连接继续被复用时带着旧状态
redis-cli CLIENT NO-TOUCH OFF

如果需要在脚本中判断切换是否成功，应检查命令返回值；连接断开、权限策略或客户端封装错误，都不应被误判成“已经开启”。同时，不要把命令的 OK 当作内存下降、淘汰行为改变或数据清理完成的证明。

连接池为什么更容易踩坑

连接池会复用 TCP 连接，而 NO-TOUCH 是连接级状态。一个后台任务把状态设为 ON 后，如果把连接放回池中，后续普通业务请求可能继续使用这个状态；反过来，如果业务连接曾经被改成 OFF，后台任务也不能假定它已经处于想要的状态。

更稳妥的处理有三点：

1. 任务开始时显式发送 CLIENT NO-TOUCH ON，不依赖连接池初始状态；
2. 任务结束时在同一条连接发送 CLIENT NO-TOUCH OFF；
3. 如果中途发生异常，也要在连接归还前执行清理，或直接销毁这条连接。

尤其要注意，普通客户端库通常会把命令封装成方法或原始命令调用。封装层如果自动重连，新的连接不会自动等价于旧连接，初始化钩子需要重新设置。

它适合什么场景，不适合什么场景

当访问行为本身不应把键“加热”时，NO-TOUCH 很有价值。例如离线盘点、低频抽样、后台扫描或迁移前的只读检查，可以减少诊断任务对访问统计的干扰。

但如果读取就是业务热度的一部分，就不应为了降低触碰而盲目开启。商品详情、会话续期、热点排行榜等正常业务读取，可能需要按默认行为维护访问信息。NO-TOUCH 也不能解决键空间持续增长、内存碎片、错误的过期策略或大键本身占用过高等问题。

用一张表做最后判断

常见问题

CLIENT NO-TOUCH ON 会阻止 Redis 淘汰键吗？

不会。它只影响当前连接访问键时的 LRU/LFU 触碰更新，不能替代淘汰策略配置，也不能保证键不会被其他原因淘汰。

执行一次 ON 后所有客户端都生效吗？

不会。该设置绑定当前客户端连接，其他连接需要单独设置。

连接断开后需要手动恢复 OFF 吗？

断开的连接状态不会继续存在，但连接池复用场景不能等到断开再处理；归还连接前应显式恢复 OFF，或者销毁连接。

返回 OK 是否说明内存已经下降？

不是。OK 只说明开关命令被接受，是否影响后续访问统计以及实例内存表现，需要结合实际任务和指标单独判断。