压测必须基于固定基线环境并用数据验证效果：先用redis-cli --stat和info memory获取基线，再用memtier_benchmark测p99延迟、qps及淘汰数，关注内存策略生效与客户端行为匹配。

必须用压测数据说话，不能只看监控曲线或主观感觉。

压测前先固定基线环境

同一台机器、同一组配置、同一份测试脚本，否则对比无效。常见干扰项包括：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 或重启实例——这会重置所有内存状态

关注延迟分布而非平均值

平均延迟掩盖长尾问题，业务卡顿往往来自 P99 或 P99.9 的尖刺。比如优化后平均延迟从 0.8ms 降到 0.6ms，但 P99 从 5ms 涨到 12ms，说明大 Key 扫描或 AOF fsync 正在阻塞主线程。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 用 memtier_benchmark 而非 redis-benchmark，它支持输出完整延迟直方图
• 关键命令加 --print-percentiles=90,99,99.9 参数
• 对比时重点看 P99 是否 （缓存场景）或 <code>（队列场景）
• 若 P99 波动剧烈，检查是否触发了 activedefrag 或 bgrewriteaof

验证内存回收策略是否生效

改了 maxmemory-policy 后，得确认淘汰真的发生了，且淘汰的是冷数据而非热数据。

• 压测期间持续执行 INFO stats | grep evicted_keys，看淘汰数是否随内存增长而上升
• 用 MEMORY USAGE keyname 抽样检查高频访问键是否还在，避免误删
• 对 volatile-lru 策略，确认所有目标键都设置了 EXPIRE；allkeys-lfu 需配合 maxmemory-samples 10 提高采样精度
• 如果 evicted_keys 为 0 但 used_memory_peak 持续上涨，说明 maxmemory 设置过大或根本没生效

别忽略客户端侧的“假优化”

服务端调优可能被客户端行为抵消。比如开了 activedefrag 降低碎片率，但客户端仍用短连接+频繁 DEL 大 Key，导致每秒产生大量小内存块。

• 检查客户端是否启用了连接复用，redis-benchmark -c 50 模拟的是 50 个长连接，不是 50 个请求就断开
• 用 CLIENT LIST 查看 idle 字段，确认连接未空闲超时被踢
• 若用了 Pipeline，确保 batch size 合理（通常 10–100 条），太大反而触发输出缓冲区限制 client-output-buffer-limit
• 压测脚本里别混用 SET 和 EVAL —— Lua 脚本会阻塞主线程，影响其他命令吞吐

真正有效的优化，是在相同压测条件下，P99 延迟下降、QPS 上升、evicted_keys 和 expired_keys 变化符合预期，且 used_cpu_sys 没明显升高。任何一项异常，都得回溯配置变更点，而不是归因于“网络抖动”。