redis-benchmark无法直接测试lfu/lru淘汰行为，因其不触发maxmemory限制和驱逐逻辑；必须显式配置maxmemory、maxmemory-policy，并用-r、-e等参数构造真实驱逐压力。
redis-benchmark 无法直接测试 LFU/LRU 淘汰行为
直接用 redis-benchmark -t set,get 压测，根本测不出 LFU 和 LRU 的性能差异。原因很简单：淘汰策略只在内存满、触发 maxmemory 限制时才起作用；而默认压测不设内存上限，也不构造键过期/驱逐场景，所有数据都缓存在内存里，根本不会触发淘汰逻辑。
常见错误现象是：跑完 redis-benchmark 看到 QPS 很高、延迟很低，就以为“LFU 比 LRU 快”——其实两者压根没被激活。
- 必须显式配置
maxmemory和maxmemory-policy（如allkeys-lfu或volatile-lru） - 压测数据量要远超
maxmemory，才能持续触发驱逐 -
redis-benchmark默认不带 key 过期时间，若用volatile-*策略，需配合-e参数（Redis 6.2+ 才支持）或改用自定义脚本注入 TTL
用 redis-benchmark 模拟淘汰压力的正确姿势
以 Redis 6.2+ 为例，想对比 allkeys-lfu 和 allkeys-lru 在写密集场景下的表现，得这样组合参数：
redis-benchmark -h 127.0.0.1 -p 6379 -n 1000000 -q -t set \ -r 10000000 \ -l \ -e \ --csv | grep SET
说明：
-
-r 10000000：让 key 名随机化（如key:123456），避免命中率虚高，逼出真实驱逐压力 -
-l：长连接，减少建连开销，聚焦淘汰本身耗时 -
-e：为每个SET自动附加EXPIRE（仅 Redis 6.2+ 支持），配合volatile-*策略生效 - 服务端必须提前配置：
maxmemory 100mb+maxmemory-policy allkeys-lfu（或allkeys-lru）
注意：-e 不控制 TTL 长短，默认是 10 秒；若要更短 TTL 加速驱逐，得换 redis-cli 脚本或 memtier_benchmark。
为什么 Redis 7.x 的 LFU 实现比 4.x/5.x 更难压准
Redis 7.x 对 LFU 做了关键调整：引入访问频次衰减（counter decay）和更精细的热度分级，这导致它在短期突发请求下“看起来更慢”，但长期分布更合理。用 redis-benchmark 这种恒定速率压测，反而会放大这种假象。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
典型陷阱：
- 用 100 万次
SET压完就停，7.x 的 LFU counter 还没热起来，统计不准 - 未调大
lfu-log-factor（默认 10），导致低频访问被过早降权，误判为“LFU 效果差” - 忽略
maxmemory-samples影响：值越小，采样越粗糙，LFU 决策抖动越大，压测结果方差飙升
真正可比的方式是：固定 maxmemory、相同 key 分布、持续运行 5 分钟以上，再看 INFO memory 中的 evicted_keys 和 expired_keys 累计值，而非单看 QPS。
替代方案：用 memtier_benchmark 更靠谱
redis-benchmark 太简陋，对淘汰类场景支持弱。生产级对比建议换 memtier_benchmark：
- 支持按比例混合
SET（带 TTL）和GET，模拟真实缓存读写比 - 可指定 key 模式（如
--key-pattern=R:R随机读写），天然触发驱逐 - 输出含
Hits/Misses/Evictions明细，直接关联淘汰策略效果
示例命令：
memtier_benchmark -s 127.0.0.1 -p 6379 \ --key-minimum=1 --key-maximum=10000000 \ --key-pattern=R:R \ --ratio=1:1 \ --requests=1000000 \ --test-time=300 \ --clients=12 \ --threads=4
压测后查 INFO stats 的 evicted_keys 和 expired_keys，再结合 INFO memory 的 used_memory_peak_human，才能看出 LFU 在不同版本里是否真降低了无效驱逐率。
最易被忽略的一点：淘汰算法性能不是看“快不快”，而是看“在同样内存下，缓存命中率高不高”。压测时盯着 evicted_keys 数字本身没意义，得算它占总 set 操作的比例——这个比值低，才说明策略更优。
