结论：必须在kubernetes内部pod中运行redis-benchmark --cluster，使用redis 6.0+客户端镜像（如7.0.11）、直连分片pod ip、合理配置-c与-p参数，才能真实反映集群性能；外部压测因service转发、dns抖动、单线程限制等导致结果严重失真。
直接结论：用 redis-benchmark --cluster 在 Kubernetes 内部 Pod 中执行，而不是从集群外发起压测；否则网络跳转、DNS 解析、Service 转发都会严重稀释真实 Redis 性能。
为什么不能从本地或 JumpServer 运行 redis-benchmark
很多团队习惯在运维机上跑 redis-benchmark -h redis-cluster-svc -p 6379，结果 QPS 只有预期的 1/3～1/2。根本原因不是 Redis 慢，而是：
- Kubernetes Service（ClusterIP）引入额外 iptables 或 eBPF 规则转发，延迟增加 0.2～0.8ms/请求
- 跨节点通信时，Pod IP → Node IP → Service IP 的路径导致 TCP 连接复用率下降
-
redis-benchmark默认单线程、单连接池，无法打满多核 CPU，而外部压测机往往资源受限（比如 2C4G VM） - 集群 DNS 解析（如
redis-cluster-svc.redis-ns.svc.cluster.local）在高并发下出现解析抖动，-c 100以上就可能卡住
redis-benchmark --cluster 必须用 6.0+ 客户端镜像
Redis 5.x 官方客户端不支持 --cluster 参数，强行使用会报错：Unknown option '--cluster'。Kubernetes 环境下必须确认客户端 Pod 使用的是 Redis 6.0 或更高版本镜像：
- 博云平台实测需用
redis:7.0.11镜像（见 deployment-redis-client.yaml） - 若用
redis:5.0.14，即使加--cluster也会静默忽略，退化为单节点模式，测试结果完全失真 - 镜像中
redis-benchmark版本可通过redis-benchmark --version验证，输出应为redis-benchmark 7.0.11或类似
压测命令必须指定集群入口 IP，而非 Service 名
在 Pod 内部执行时，--cluster 模式要求直接连到某个分片的 Pod IP（不是 Headless Service 域名），否则会因重定向失败而卡死：
- 正确写法：
redis-benchmark --cluster -h 10.244.1.15 -p 6379 -a yourpass -t get,set -n 1000000 -q - 错误写法：
redis-benchmark --cluster -h redis-cluster-svc -p 6379 ...（会反复尝试解析、超时、重试） - 获取 Pod IP 方法：
kubectl get pods -n redis -o wide | grep redis，选任意一个主节点 Pod IP 即可 - 注意：
-h后填的是 Pod IP，不是 Service ClusterIP；redis-benchmark --cluster会自动发现其余节点，无需手动列全部 IP
并发数 -c 和 pipeline -P 要匹配实际负载特征
盲目调高 -c 不一定提升 QPS，反而可能触发连接风暴、TIME_WAIT 拥塞或 Redis 自身连接数限制：
- 默认
-c 50对多数场景已足够；超过 200 时建议同步调大 Redis 的maxclients（默认 10000） - 真实业务多用 pipeline，所以压测必须加
-P 16或-P 32（每连接批量发 N 条命令），否则QPS = connections × 1，完全偏离生产行为 - 如果测出延迟毛刺明显（如 P99 > 10ms），先检查是否
-c过高导致内核 socket buffer 打满，可临时改用-c 100 -P 8对比 - 务必加
-q（quiet mode），避免日志刷屏掩盖真实吞吐；结果只看最后一行xxx requests per second
真正影响压测结果的，从来不是参数拼写，而是压测位置、客户端版本、网络路径这三点。只要 Pod 内跑对版本、连对 IP、配对 -P，一次 redis-benchmark --cluster 就能暴露 Redis 集群的真实吞吐瓶颈——是 CPU？内存带宽？还是持久化阻塞？其他都是后续调优的事。
