压测必须基于固定基线环境并用数据验证效果：先用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 是否
< 2ms（缓存场景）或< 10ms（队列场景） - 若 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 没明显升高。任何一项异常，都得回溯配置变更点，而不是归因于“网络抖动”。
