redis-benchmark默认pipeline导致淘汰未触发，需加-p 1单请求发送；测volatile-lru必须加-e设ttl；监控evicted_keys增量并确认used_memory_human逼近maxmemory才有效。
用 redis-benchmark 模拟压测时，为什么 maxmemory 和淘汰策略没生效？
常见现象是：明明配置了 maxmemory 100mb 和 maxmemory-policy allkeys-lru，但压测过程中 evicted_keys 一直为 0，内存持续上涨甚至 OOM。根本原因是 redis-benchmark 默认使用 pipeline 模式批量发请求，写入速度远超 Redis 单线程处理+淘汰的节奏，导致内存还没触顶就卡在 client output buffer 或 pending write 队列里，压根没走到淘汰逻辑。
- 必须加
-P 1关闭 pipeline（单请求逐条发送），否则淘汰指标完全不可信 - 确保
redis-cli info memory | grep -E "used_memory|maxmemory|evicted_keys"中used_memory_human确实逼近maxmemory才算触发条件 - 避免用
redis-benchmark -t set,get这种混合命令——get不占内存，会稀释淘汰率；专注压set即可
如何让 evicted_keys 和 expired_keys 监控值真实反映淘汰行为？
Redis 的淘汰发生在「写入时检查内存超限」那一刻，不是后台定时扫描。所以监控必须和压测同步采样，不能只看最终值。
- 开两个终端：一个跑
redis-benchmark -n 100000 -q -P 1 -t set -r 1000000 -d 1024（10 万次随机 key 写入，value 1KB） - 另一个用
watch -n 0.5 'redis-cli info stats | grep -E "evicted_keys|expired_keys"'实时盯住计数跳变 - 注意
evicted_keys是累计值，要观察单位时间内的增量（比如每秒 +120 表示当前淘汰速率） - 如果
evicted_keys增长但keyspace_hits/keyspace_misses没变化，说明淘汰的是冷 key，LRU 策略实际生效了
allkeys-lru 和 volatile-lru 在 benchmark 下表现差异极大
用 redis-benchmark 测试时，不设 TTL 就等于把所有 key 当成永久键——这对 volatile-* 类策略是致命的。它们只淘汰带过期时间的 key，而 benchmark 默认不加 EX 参数。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 测试
volatile-lru必须加-e参数：例如redis-benchmark -e -t set -r 1000000 -P 1，否则evicted_keys永远为 0 -
allkeys-lru在同样参数下会立即开始淘汰，但要注意：key 名随机性必须高（-r足够大），否则哈希冲突少，内存增长慢，淘汰延迟出现 - 对比两者时，务必用
redis-cli info memory | grep mem_policy确认运行时策略未被动态覆盖
容易被忽略的干扰项：client-output-buffer-limit 和 repl-backlog-size
当 evicted_keys 增长异常缓慢，甚至压测中途 Redis 直接断连，大概率是输出缓冲区或复制积压缓冲区先爆了，而不是内存淘汰机制问题。
- 检查
client-output-buffer-limit normal，benchmark 大量get会堆积响应数据，建议临时调大（如1gb 512mb 60） - 主从架构下，
repl-backlog-size默认 1MB，压测写入洪流会让从库追不上，触发全量同步，此时内存统计失真 - 最干净的测试环境：单机无从库、禁用 AOF/RDB（
save ""）、关闭protected-mode避免连接拒绝
淘汰策略的实际效果永远取决于「写入压力」「key 分布密度」「value 大小」三者的实时博弈，benchmark 只是放大器，不是判决书。盯着 evicted_keys 增速的同时，一定得看 used_memory_peak_human 是否稳定在 maxmemory 附近——这才是淘汰真正扛住压力的证据。
