redis-benchmark 不能直接测出生产配置下的真实极限 qps，因其默认用固定 key、无 ttl、单命令裸跑，结果仅反映协议层吞吐，与业务中混合读写、带过期、pipeline、集群等场景严重脱节；必须关闭 -q 静默模式以观察延迟分布等关键瓶颈信号。
redis-benchmark 不能直接测出生产配置下的真实极限 QPS
它默认用固定 key、无 TTL、单命令裸跑，结果只反映协议层吞吐，和你业务里混合读写、带过期、有 pipeline、走集群的流量完全不是一回事。比如你压出 12 万 QPS，但线上实际只有 3 万，不是 Redis 不行，是测试没对齐场景。
必须关掉 -q 静默模式，否则看不到关键瓶颈信号
静默模式（-q）只输出最终 QPS 和延迟均值，但真实瓶颈往往藏在分布细节里：比如 99% 请求 -q 会直接抹掉这个信号。实操建议：
- 压测时去掉
-q，保留完整 latency 分布（如99.9% ） - 加
-e启用 pipeline，模拟真实客户端批量请求行为，否则单命令往返放大网络开销 - 用
-d 100控制 value 大小（单位 byte），避免默认 3 字节导致内存分配失真；生产缓存 value 多在 1KB–10KB，建议设为-d 1024或-d 4096
压测前必须确认 maxmemory-policy 和 used_memory_human 是否就位
很多人压到 OOM 才发现策略根本没生效——因为 CONFIG GET maxmemory-policy 返回的是 noeviction，而你以为配的是 allkeys-lru。真实极限 QPS 只在淘汰真正触发后才有意义。所以：
- 先连上实例执行
CONFIG GET maxmemory和CONFIG GET maxmemory-policy，确认值非 0 且是你期望的策略 - 用
INFO memory看used_memory_human当前占比，若远低于maxmemory，压测只是空转，不会触发淘汰压力 - 若要测淘汰下的极限，得先预热：用脚本写入带
EXPIRE 120的 key，填到内存达maxmemory的 85%，再开redis-benchmark持续写入
集群环境用 redis-benchmark 就是自欺欺人
它不解析 MOVED 响应，所有跨 slot 请求都会失败，报错类似 (error) MOVED 12345 10.0.1.5:6379。这不是你 Redis 不行，是工具根本不支持 Cluster。此时所谓“QPS”只是单节点吞吐，其余节点完全闲置。正确做法只有两个：
- 用
redis-py-cluster写 Python 脚本，初始化时传任意节点地址，自动拉取CLUSTER SLOTS并路由 - 或退一步：手动按 slot 范围分片，用多个
redis-benchmark实例分别压不同主节点（例如-r 0-5460、-r 5461-10922），再把 QPS 相加
别信“加 -e 就能绕过重定向”的说法——协议层面不处理 MOVED，再多参数也白搭。
