Redis淘汰策略压测实战：避开那些“看起来生效”的坑
不少朋友在验证Redis内存淘汰策略时，都遇到过这样的困惑：明明配置都设好了，压测也跑了，可监控指标就是纹丝不动。这背后，往往不是策略失效，而是测试方法本身就把淘汰机制给“架空”了。今天，我们就来拆解几个关键场景，看看如何让压测真实地反映出淘汰策略的运作。
用 redis-benchmark 模拟压测时，为什么 maxmemory 和淘汰策略没生效？
一个典型的场景：配置文件里白纸黑字写着 maxmemory 100mb 和 maxmemory-policy allkeys-lru，可一轮压测下来，evicted_keys 稳稳地停在0，内存却一路飙升甚至触发OOM。问题出在哪儿？
关键在于，redis-benchmark 默认使用了pipeline模式批量发送请求。这种模式下，客户端的写入请求像洪水一样涌入，速度远远超过了Redis单线程处理数据并触发淘汰的节奏。结果就是，数据大量堆积在客户端的输出缓冲区或服务端的待写队列里，内存上限还没真正触及，淘汰逻辑自然无从启动。
要看到真实的淘汰行为，必须解决这个“速度差”：
- 关闭pipeline是第一步：务必加上
-P 1参数，让请求逐条发送。否则，所有的淘汰指标都不可信。 - 确认内存触顶：随时通过
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 下表现差异极大
用同一个压测命令去测试不同的淘汰策略，可能会得到截然相反的结论，这往往是因为忽略了策略的作用范围。volatile-* 这一系列策略（如volatile-lru）只淘汰那些设置了过期时间（TTL）的Key。而 redis-benchmark 默认的SET命令是不带TTL的，这相当于把所有Key都当作永久键来处理。
结果就是，即使用 volatile-lru 策略把内存压爆，evicted_keys 也可能永远是0，因为它根本找不到一个有TTL的Key来淘汰。
- 测试 volatile-lru 的必备参数：必须加上
-e参数，例如redis-benchmark -e -t set -r 1000000 -P 1。这个参数会让SET命令自动为Key加上一个随机过期时间，从而激活淘汰机制。 - 注意 allkeys-lru 的“热身期”：在同样参数下，
allkeys-lru策略会立即开始淘汰。但这里有个细节：Key的随机性（通过-r参数设置）必须足够高。如果Key冲突多，实际写入的Key数量少，内存增长就慢，淘汰行为也会延迟出现。 - 最后确认策略：对比测试前，用
redis-cli info memory | grep mem_policy命令看一眼，确保运行时策略没有被CONFIG SET等命令动态覆盖。
容易被忽略的干扰项：client-output-buffer-limit 和 repl-backlog-size
有时候，一切配置看起来都正确，但 evicted_keys 的增长就是慢得离奇，甚至压测中途Redis连接直接断开。这时，问题可能不在淘汰机制本身，而在缓冲区。
- 客户端输出缓冲区：检查
client-output-buffer-limit normal配置。如果压测中包含大量GET请求，响应数据可能会在此堆积，导致连接被强制关闭。测试时，可以临时将其调大（例如1gb 512mb 60）以排除干扰。 - 复制积压缓冲区：在主从架构下进行压测要格外小心。
repl-backlog-size默认只有1MB，写入洪流可能导致从库复制延迟过大，最终触发全量同步。这个过程会严重干扰内存统计和淘汰观察。 - 追求最干净的测试环境：为了得到最清晰的结果，建议在单机、无从库、禁用AOF和RDB（配置
sa ve ""）、并暂时关闭protected-mode的环境中进行测试，最大限度减少变量。
说到底，淘汰策略的实际效果，永远是“写入压力”、“Key分布密度”和“Value大小”三者实时博弈的结果。redis-benchmark 只是一个压力放大器，而非最终判决书。在紧盯 evicted_keys 增速的同时，务必确认 used_memory_peak_human 这个指标能够稳定在 maxmemory 上限附近——这才是内存淘汰真正在“扛压”的铁证。
