CONFIG SET maxmemory-policy 为什么能热生效？

背后的原理其实很直接。Redis将淘汰策略存储在一个名为 server.maxmemory_policy 的全局变量中。CONFIG SET 命令所做的，就是毫秒级地、原子性地修改这个变量的值。整个过程不涉及任何键扫描、LRU/LFU计算或内存释放操作。

• ✅ 安全：对正在服务的读写请求零影响。
• ✅ 零风险：切换前后数据集保持完全一致。
• ❌ 不清理：不会主动驱逐任何一个现有key。

当你执行：

redis-cli config set maxmemory-policy allkeys-lru

看到返回 OK，只意味着变量更新成功了。此时即便内存已经用满，只要没有新的写入命令到来，淘汰机制就依然在“待命”状态。

切换后什么时候真正起作用？

新策略要真正“干活”，必须满足以下两个条件，缺一不可：

• used_memory ≥ maxmemory（内存使用达到上限）。
• 有新的写入命令执行（例如 SET、HSET、LPUSH 等带有 CMD_DENYOOM 标志的命令）。

只有这时，Redis内部才会调用 freeMemoryIfNeeded() 函数。这个函数会读取最新的 server.maxmemory_policy 值，并严格按照新规则来挑选牺牲者进行淘汰。

• 如果切换到 noeviction，那么后续的写入命令会直接收到 (error) OOM command not allowed when used memory > 'maxmemory'. 的错误。
• 如果切换到 volatile-ttl，那么下次淘汰时，就会优先踢掉那些最快过期的键，而不是LRU算法中最近最久未使用的那个。

容易踩的坑

理解了原理，就能避开下面这些常见的坑：

• 忘了设置 maxmemory：这是前提中的前提。如果 maxmemory 是0或者根本没设置，那么无论 maxmemory-policy 配置成什么，淘汰机制都不会启动。
• 误把“配置生效”当成“开始删数据”：切换后，可以通过 INFO memory 观察 mem_peak 和 used_memory_human。如果没有写入压力，evicted_keys 这个计数器会一直保持为0。
• 混淆“过期删除”与“内存淘汰”：这是两套独立的逻辑。键的过期清理（由 expireIfNeeded 处理）和内存超限后的强制淘汰（由 freeMemoryIfNeeded 处理）互不影响。更改淘汰策略，不会改变Redis处理过期键的行为。
• 动态修改不持久化：CONFIG SET 只改变运行时的内存状态。一旦Redis重启，配置就会回退到 redis.conf 文件中的设定。生产环境务必记得同步修改配置文件，否则变更会在重启后“一夜回到解放前”。

那么，如何验证新策略是否真的在按预期工作呢？关键在于构造一个“内存触顶+写入”的场景。可以先用 DEBUG POPULATE 或批量 SET 命令将内存填满，然后发送一条新的 SET 命令。接着，观察 INFO stats 中的 evicted_keys 是否增加，以及 INFO keyspace 中的键数量是否下降。

否则，仅仅执行 config get maxmemory-policy 看到返回值变了，只能证明“规则已经换了”，并不能证明“规则已经开始干活了”。