必须同时设置maxmemory和maxmemory-policy noeviction，缺一不可；仅设maxmemory或策略拼写错误（如no-eviction、noeviction）会导致redis退回到默认行为，不触发淘汰，内存持续增长直至被系统oom killer杀死。
maxmemory没设对，淘汰根本不会启动
Redis 的淘汰逻辑只在 maxmemory 为非零值时才可能触发。如果配置文件里 maxmemory 被注释、写成 0，或单位写错（比如写成 2g 而不是 2gb），CONFIG GET maxmemory 返回的仍是 0，此时无论你把 maxmemory-policy 改成什么，Redis 都当它不存在。
常见错误包括：
-
maxmemory 2G（大小写敏感，应为gb或全小写g，但推荐用2gb） - 配置了
maxmemory-policy allkeys-lru，但漏掉maxmemory行 - 用
CONFIG SET maxmemory 2gb临时设置后，没写入redis.conf，重启即失效
策略改了，但“可淘汰池”为空
比如你切到了 volatile-lru，但业务写入的 key 全是 SET user:1001 "Alice" 这种没带 EXPIRE 的永久键，那 Redis 找不到一个能淘汰的 key —— 淘汰范围是空的，行为等效于 noeviction。
验证方法很简单：
- 用
SCAN 0 MATCH * COUNT 1000拿一批 key，再对每个执行TTL keyname - 如果多数返回
-1（永久）或-2（key 不存在），说明volatile-*类策略注定失效 - 此时必须换
allkeys-lru或补上SETEX/EXPIRE
INFO memory 中 evicted_keys 为 0，不代表策略没生效
evicted_keys 是累计值，只在真正发生淘汰时才加一。刚改完策略，内存还没达到 maxmemory，或者刚好卡在阈值边缘没触发腾挪，它就不会动。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
更关键的观察点是：
-
used_memory_human是否稳定在maxmemory_human附近小幅波动（说明淘汰在动态平衡） -
mem_fragmentation_ratio> 1.5 时，实际可用内存可能远低于maxmemory，导致误判“已满” - 用
INFO stats查evicted_keys增长趋势，至少连续 2–3 分钟有变化才算真工作
淘汰动作本身不释放“立刻可见”的内存
Redis 的淘汰是渐进式、分批进行的：每次写入前，只随机采样几个 key，淘汰其中最符合条件的一个（如 LRU 最久未用）。它不会一口气清空 100MB，所以你改完策略后立刻看 used_memory_human，可能几乎没变。
真正要看到效果，得配合持续写入压力；否则得等自然访问触发 LRU/LFU 排序积累足够差异，或者手动用 MEMORY PURGE（Redis 7.0+）回收碎片。
最容易被忽略的是：淘汰策略解决的是“写入能否继续”，不是“内存能不能立刻下降”。它保的是可用性，不是瞬时水位。
