必须使用 --cluster 参数启用集群模式压测，否则 redis-benchmark 仅直连单节点无法反映集群真实能力；需至少3主节点、验证 key 分布均匀性、排除 failover 或 slot 迁移干扰，并通过 --latency-dist 分析端到端延迟分布。
直接看 redis-benchmark 能跑出多少 QPS，但必须走集群路由
单节点压测结果不能代表集群真实能力——redis-benchmark 默认不识别集群拓扑，直连某个节点时，它只会打到那个节点，不会自动做 slot 计算和重定向。你看到的 120K QPS 可能只是单节点吞吐，而集群里其他节点完全空闲。
正确做法是加 -c 参数启用集群模式（注意不是连接数参数 -c 100 那个 -c）：
redis-benchmark -h 192.168.1.10 -p 6379 -c 100 -n 100000 -t set,get --cluster
这个 --cluster 是关键，它会让客户端解析 CLUSTER SLOTS 并按 key 自动路由。没加它，压测就等于在测单点。
- 必须用至少 3 个主节点组成的最小可用集群（否则
--cluster会报错退出） - 压测 IP 应该是任意一个可访问的集群节点，不是 sentinel 或 proxy 地址
- 如果遇到
MOVED重定向失败，说明客户端版本太老（redis-benchmark需 Redis 6.0+ 编译版本）
观察 INFO commandstats 里的实际命令分发是否均匀
压测跑起来后，别只盯着总 QPS。进每个主节点执行 redis-cli -h node-ip info commandstats，重点看 cmdstat_set 和 cmdstat_get 的 calls 字段。
如果某节点 calls 是其他节点的 3 倍以上，说明 key 分布严重倾斜——常见原因有：
- 业务 key 使用固定前缀（如
"user:1001"、"user:1002"），hash tag 没生效，全落到同一个 slot - 用了
{...}但括号位置错误，比如写成user{1001}:profile（正确应为user:{1001}:profile） - 集群刚扩容，slot 迁移没完成，
CLUSTER NODES里还能看到 migrating/importing 状态
此时压测结果毫无参考价值，得先 fix key 设计或等迁移结束。
用 redis-cli --latency -h 测端到端延迟，而不是只信平均值
集群里网络跳数多了一层（client → node → 可能重定向 → target node），延迟毛刺比单机明显。光看 redis-benchmark 输出的 avg_latency 容易误判。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
更准的做法是：
- 在业务服务器上运行
redis-cli -h cluster-ip --latency，持续 60 秒，看 P95/P99 是否稳定在 2ms 以内 - 同时用
redis-cli -h cluster-ip --latency-dist看分布直方图，如果 10ms+ 区间有大量采样，说明存在慢节点或网络抖动 - 对比同一台机器直连某个节点的
--latency结果，差值超过 0.5ms 就要查节点间 RTT（用ping和redis-cli -h node1 ping对比）
instantaneous_ops_per_sec 突然掉零？说明集群正在 failover 或 slot 迁移
压测过程中如果监控发现某个节点的 INFO 里 instantaneous_ops_per_sec 瞬间归零几秒，不是机器卡死，极大概率是集群触发了故障转移或人工迁 slot。
这时候立刻执行：
redis-cli -h node-ip cluster nodes | grep -E "(fail|handshake|migrating|importing)"
常见干扰项：
-
fail?行：主节点失联，从节点正在升主，期间拒绝写入 -
migrating行：该节点正把 slot 数据往外推，会阻塞对应 key 的写操作 -
importing行：该节点正接收 slot，对导入中的 key 读写都可能被 block
这种状态下的压测数据必须作废——它反映的是运维操作窗口，不是业务常态性能。
真正决定集群性能上限的，从来不是单节点硬件，而是 slot 分布合理性、跨节点网络稳定性、以及客户端是否真正理解集群协议。这三个点没对齐，加再多机器也白搭。
