不能直接在生产redis上跑redis-benchmark压测淘汰策略，因其默认不带ttl、狂塞无过期key，会误触发noeviction报oom错误，导致误判策略失效；真实验证需分批写入带30–300秒ttl的key，使内存达maxmemory的85%后持续写入，并监控evicted_keys持续增长、used_memory_human逼近阈值、expired_keys不显著高于evicted_keys。
为什么不能直接在生产Redis上跑 redis-benchmark 压测淘汰策略
因为 redis-benchmark 默认不带过期时间、不模拟真实缓存写入模式，它狂塞无TTL的key，会快速触发 allkeys-lru 或 noeviction 的边界行为，但这种“压”根本测不出淘汰是否按预期生效——比如你设了 volatile-lru，结果压测数据全没过期时间，策略直接退化成拒绝写入，报 (error) OOM command not allowed when used memory > 'maxmemory'，误判为“策略失效”，其实是测试方法错了。
如何构造能验证淘汰逻辑的真实压力数据
关键不是压QPS，而是让Redis内存稳定逼近 maxmemory，同时确保有足够多带TTL的key参与淘汰决策。必须满足三个条件：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 所有写入key都带
EXPIRE或SETEX，TTL建议设为 30–300 秒，避免过短导致惰性删除来不及触发，也避免过长让样本失效 - 写入数据量要分批：先用脚本预热填到内存占用达
maxmemory的 85% 左右，再开启持续写入流（每秒几百 key），观察evicted_keys计数器是否稳步上升 - 混入不同访问频次的key：一部分高频读（模拟热key）、一部分低频或只写不读（模拟冷key），这样才能验证
allkeys-lru是否真把冷key踢出去，而不是随机乱删
监控哪些指标才能确认淘汰策略在起作用
光看内存是否回落是假象——可能是旧key自然过期释放的，不是淘汰策略干的。必须盯住这几个 INFO memory 和 INFO stats 中的真实信号：
-
used_memory_human：确认已接近maxmemory设置值（如设了 2GB，这里应显示 ~1.95G） -
evicted_keys：该值从 0 开始持续增长，才说明淘汰策略被真正触发；如果一直是 0，说明还没到阈值或策略配置未生效 -
expired_keys：和evicted_keys对比，若前者远大于后者，说明大部分释放靠自然过期，淘汰策略实际未承压 -
mem_fragmentation_ratio：超过 1.5 就得警惕内存碎片干扰判断，此时即使evicted_keys上升，也可能因碎片导致新写入仍失败
最容易被忽略的配置陷阱
压测前不检查这三项，90% 的“淘汰策略无效”结论都是错的：
-
CONFIG GET maxmemory-policy返回的不是你以为的值——比如配置文件写了allkeys-lru，但运行时被运维脚本覆盖成了noeviction，必须现场确认 -
maxmemory设的是 0（不限制）或远高于物理内存，此时根本不会触发淘汰，evicted_keys永远为 0 - 用了
volatile-*类策略（如volatile-ttl），但压测数据全用SET写入，没加过期时间，等于策略永远收不到可淘汰对象
used_memory 精确值，这个值受碎片、客户端缓冲区、AOF rewrite 临时空间等隐蔽因素影响——所以压测前务必先 INFO memory 看原始数字，别只信 redis-cli info | grep used 这种模糊过滤。
