redis-benchmark不能直接测Redis集群，因其是单点客户端，不识别集群拓扑、不处理MOVED/ASK重定向，所有请求仅打向指定节点，导致报错或负载不均。
Redis集群压测不能直接套用单机 redis-benchmark 的默认命令，它不识别集群拓扑、不会自动路由、也不处理重定向（MOVED/ASK），盲目执行会大量报错或只打到少数节点。
为什么 redis-benchmark 不能直接测 Redis 集群
它本质是单点客户端：所有请求都发往你指定的 -h 和 -p，遇到 MOVED 响应就失败，不会像真实客户端那样自动重试或跳转。即使加了 -c 100，也只是 100 个连接连同一个节点，其他节点完全空闲。
- 错误现象：
WRONGTYPE Operation against a key holding the wrong kind of value或大量(error) MOVED日志 - 真实业务中，客户端（如
redis-py-cluster、JedisCluster）会缓存 slot 映射、自动重定向、支持连接池复用；redis-benchmark完全不具备这些能力 - 集群压测必须验证分片均衡性——比如用
-r生成随机 key，观察各节点INFO stats中的instantaneous_ops_per_sec是否接近
用 redis-benchmark 模拟集群请求的正确姿势
只能用于「粗粒度吞吐预估」，前提是绕过重定向逻辑，手动把请求打到不同节点上。适用于快速比对单节点性能是否一致。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 对每个集群节点单独压测：
redis-benchmark -h 192.168.1.10 -p 7000 -a pwd -t set -n 100000 -c 50，再换7001、7002… 记录各自 QPS - 务必加上
-r 1000000：避免固定 key 导致哈希冲突集中在某几个 slot，掩盖分片不均问题 - 禁用
-t pubsub：pub/sub 在集群中不跨节点广播，redis-benchmark的 pub/sub 模式在集群里根本不可用 - 不要依赖
-q输出的汇总值：它只反映当前节点负载，不是集群整体能力
真正有效的集群压测：必须用支持集群协议的客户端
Python 示例（redis-py-cluster）是最轻量、可快速验证的方式，能真实触发 slot 路由、重定向、连接池行为。
- 安装：
pip install redis-py-cluster（注意不是redis-py） - 关键配置：
startup_nodes必须包含至少 3 个不同节点（含主从），客户端才能自动发现整个拓扑 - 示例代码片段：
from rediscluster import RedisCluster startup_nodes = [{"host": "192.168.1.10", "port": "7000"}, {"host": "192.168.1.11", "port": "7001"}, {"host": "192.168.1.12", "port": "7002"}] rc = RedisCluster(startup_nodes=startup_nodes, decode_responses=True) rc.set("user:1001", "data") # 自动计算 slot 并路由到对应节点 - 压测时监控：
redis-cli -c -h 192.168.1.10 -p 7000 cluster nodes看各节点分配的 slot 数是否均匀；用INFO stats查total_commands_processed增速是否同步
压测后必须盯住的三个隐藏瓶颈点
很多人只看 QPS 和平均延迟，但集群的真实瓶颈往往藏在底层指标里：
-
client_longest_output_list：某个节点该值持续 > 1000，说明输出缓冲区堆积严重，可能是订阅者太多或网络慢，会触发client-output-buffer-limit断连 -
connected_clients接近ulimit -n设置值：连接数耗尽会导致新请求失败，而redis-benchmark默认不释放连接，容易误判 - 主从复制延迟（
INFO replication中的master_repl_offset与slave_repl_offset差值）：压测期间差值突增 > 10MB，说明从节点追不上，故障切换时可能丢数据
集群压测最易被忽略的是「key 分布真实性」：用 rand_int 生成的 key 虽然随机，但长度固定、前缀一致，实际业务 key 往往长短不一、带业务标识（如 order:20260714:uid12345），CRC32 后的 slot 分布可能严重倾斜。上线前一定要用真实 key pattern 抽样生成测试数据集。
