Redis 6.2+需用--cluster参数运行redis-benchmark，否则MOVED/ASK重定向导致QPS归零；低版本需手动固定槽位或升级。
用 redis-benchmark 测集群 QPS，但得绕过重定向陷阱
直接对集群任意节点跑 redis-benchmark -h 127.0.0.1 -p 7000 -n 100000 会失败，因为集群模式下多数命令（如 SET、GET）触发 MOVED 或 ASK 重定向，而 redis-benchmark 默认不处理——它把重定向响应当成错误，QPS 统计崩掉，甚至返回 0。
必须加 -c（客户端连接数）和 -t（指定命令），更重要的是：用 --cluster 模式（Redis 6.2+）或退而求其次，让 benchmark 打到一个稳定槽位上：
- 如果 Redis 版本 ≥ 6.2，用
redis-benchmark -h 127.0.0.1 -p 7000 --cluster -n 100000 -t set,get，它会自动解析集群拓扑并打散请求 - 若版本 {user1001} 这种带哈希标签的 key，确保所有请求落到同一分片，再配合
-r随机生成（如-r 1000）避免单 key 热点 - 别用
-q（quiet 模式）就完事，先加-d 64控制 value 大小，否则默认 2MB 的 payload 会压垮网络或触发 TCP 分包，测出来不是 Redis 瓶颈而是网卡瓶颈
从 INFO 实时抓取 total_commands_processed 算真实 QPS
benchmark 工具容易受客户端机器性能干扰（比如并发连接数打太高，本地 CPU 先打满），更稳的方式是直接看服务端指标。Redis 集群每个节点都暴露 INFO 接口，其中 total_commands_processed 是累计值，差值除以时间就是实际 QPS。
操作步骤很简单：
- 在测试开始前，对所有 master 节点分别执行
redis-cli -h 127.0.0.1 -p 7000 INFO | grep total_commands_processed，记下初始值 - 跑 30 秒压力（比如用 Python 脚本发请求，或
redis-benchmark -n 3000000），期间不要做其他操作 - 测试结束后立刻再抓一次
total_commands_processed，用差值 ÷ 30 得到该节点 QPS；把所有 master 节点的 QPS 加起来，才是集群总吞吐 - 注意：slave 节点的
total_commands_processed只统计自己收到的 replication stream 命令，不能计入——只看 master
redis-benchmark 的 -P 参数对集群无效，别白调
-P（pipeline 数量）在单实例上能显著提升 QPS，因为减少了 RTT；但在集群里，只要 key 不在同一个 slot，pipeline 就会被拆成多个 TCP 请求转发，效果大打折扣，甚至因跨节点协调反而变慢。
实测中常见误区：
- 设
-P 16后发现 QPS 比-P 1还低——大概率是 pipeline 里混了不同 hash tag 的 key，导致请求被路由到多个节点，协调开销盖过了 pipeline 收益 - 如果真要用 pipeline，必须保证整批 key 都落在同一 slot（例如全用
{order}1001、{order}1002），否则不如不用 - 集群场景下，优先靠增加 client 并发数（
-c）和分散 key 槽位来横向扩展，而不是堆-P
版本差异直接影响上限：6.0 vs 7.0 的多线程 I/O 表现
Redis 6.0 引入多线程 I/O（由 io-threads 和 io-threads-do-reads 控制），但仅负责 socket 读写，命令执行仍是单线程；到了 7.0，I/O 线程可真正参与部分命令预处理（如协议解析），高并发小包场景下吞吐提升约 15%～25%。
关键配置项必须匹配版本：
- Redis 6.0：设
io-threads 4后，必须设io-threads-do-reads yes，否则线程只干写，读仍卡主线程 - Redis 7.0：
io-threads-do-reads默认为 yes，且支持io-threads 8（6.0 最高建议 4），但要注意线程数 ≠ CPU 核数，超过会造成上下文切换反拖慢 - 集群环境下，每个节点都要单独配，且所有 master 节点配置应一致，否则负载不均——比如有的节点开 4 线程，有的没开，QPS 分布会严重倾斜
真正卡集群上限的，往往不是 Redis 自身，而是客户端连接池耗尽、TCP TIME_WAIT 堆积、或某个 master 节点内存碎片率 > 1.5 导致分配变慢——这些细节比“理论最大 QPS”更值得盯紧。
