Redis 压力测试要想有参考价值，前提一定是先固定基线环境，而且优化效果不能靠感觉判断，必须用数据验证：先通过redis-cli --stat和INFO memory摸清基线状态，再用memtier_benchmark重点测试P99延迟、QPS以及淘汰数量，核心是盯住内存淘汰策略是否真正生效，同时确认客户端访问行为与服务端配置是否匹配。
验证 Redis 性能优化是否有效，必须以压测数据为依据，不能只看监控曲线，更不能依赖主观判断。
压测前先固定基线环境
进行 Redis 压测时，必须保证同一台机器、同一组配置、同一份测试脚本，否则前后对比没有意义。常见干扰因素包括：CPU 被其他进程抢占、Redis 刚启动时内存尚未碎片化、客户端连接池没有完成预热等。
- 用
redis-cli --stat持续观察 30 秒稳定后的 ops/sec 基线值 - 执行
INFO memory记录used_memory和mem_fragmentation_ratio的初始数据 - 运行
redis-benchmark -t set,get -n 10000 -c 50获取初始 QPS 与 P99 延迟表现 - 避免在压测过程中临时修改
maxmemory或重启实例——这会重置当前内存状态，导致测试结果失真
关注延迟分布而非平均值
评估 Redis 性能时，平均延迟往往会掩盖长尾问题，真正引发业务卡顿的通常是 P99 或 P99.9 的延迟尖刺。比如优化后平均延迟从 0.8ms 降到 0.6ms，但 P99 却从 5ms 上升到 12ms，这通常说明大 Key 扫描或 AOF fsync 正在阻塞主线程。
- 优先使用
memtier_benchmark而不是redis-benchmark，因为它支持输出更完整的延迟直方图 - 关键命令增加
--print-percentiles=90,99,99.9参数，便于查看不同分位延迟 - 做效果对比时，重点关注 P99 是否
< 2ms（缓存场景）或< 10ms（队列场景） - 如果 P99 波动明显，需检查是否触发了
activedefrag或bgrewriteaof
验证内存回收策略是否生效
调整 maxmemory-policy 之后，必须确认 Redis 淘汰机制确实发生了作用，而且被淘汰的是冷数据，而不是业务中的热点数据。
- 压测期间持续执行
INFO stats | grep evicted_keys，观察淘汰数量是否随着内存增长而同步上升 - 用
MEMORY USAGE keyname抽样检查高频访问的键是否仍然存在，避免误淘汰热点 Key - 对于
volatile-lru策略，要确认所有目标键都设置了EXPIRE；使用allkeys-lfu时，建议配合maxmemory-samples 10提高采样精度 - 如果
evicted_keys为 0，但used_memory_peak持续上涨，说明maxmemory设置过大，或者配置实际上并未生效
别忽略客户端侧的“假优化”
很多 Redis 调优看起来有效，实际上可能被客户端行为抵消。比如服务端开启了 activedefrag 来降低内存碎片率，但客户端仍然使用短连接并频繁 DEL 大 Key，结果每秒依旧会产生大量小内存块。
- 检查客户端是否启用了连接复用，
redis-benchmark -c 50模拟的是 50 个长连接，而不是 50 个请求后立即断开 - 使用
CLIENT LIST查看idle字段，确认连接没有因为空闲超时而被踢掉 - 如果启用了 Pipeline，需确保 batch size 合理（通常 10–100 条），过大反而可能触发输出缓冲区限制
client-output-buffer-limit - 压测脚本中不要混用
SET和EVAL—— Lua 脚本会阻塞 Redis 主线程，影响其他命令的吞吐能力
真正称得上 Redis 性能优化有效，必须看同一套压测条件下的实际结果：P99 延迟有没有明显下降，QPS 有没有稳定提升，evicted_keys 和 expired_keys 的变化是否符合预期，同时 used_cpu_sys 也不能出现明显抬升。只要其中任何一项表现异常，就应该沿着配置变更点继续排查，不要动不动就把问题简单归因于“网络抖动”。
