能，但必须加--cluster参数，否则仅直连单节点、无法路由key、不感知槽位，压测结果失真；加该参数后会解析CLUSTER SLOTS并按CRC16自动路由，需确保节点互通且槽分配正常。
redis-benchmark 能不能直接压测 Redis Cluster？
能，但必须加 --cluster 参数，否则它默认只连单节点，压测结果完全失真。不带该参数时，redis-benchmark -h 127.0.0.1 -p 7000 会把所有请求发到指定端口节点，既不路由 key，也不感知槽位分布，相当于在集群里随机挑一个节点反复打——这根本不是集群压测，只是单节点压力复现。
常见错误现象：ERR CROSSSLOT Keys in request don't hash to the same slot 大量报错，或 MOVED 重定向频繁出现，说明客户端没走集群协议，key 被错误分发。
-
--cluster模式下，工具内部会解析CLUSTER SLOTS响应，按 key CRC16 计算槽位，自动路由到对应节点 - 必须确保所有节点可互通，且
redis-cli --cluster check显示 slots 分配正常 - 不支持 ACL 用户认证（Redis 6+），若集群启用了用户权限，需临时切换为 default 用户或关闭 ACL 测试
如何配置 redis-benchmark 才逼近真实集群吞吐极限？
关键不在“并发数堆多”，而在模拟真实业务的 key 分布、命令组合和 pipeline 行为。默认 -t set,get 只打固定 key，缓存命中率 100%，测出来是虚假峰值。
- 强制随机 key：加
-r 1000000（生成 100 万不同 key），配合__rand_int__模板，避免热点 skew - 混合读写比例：用
-t set,get,incr,sadd替代单一命令，更贴近缓存+计数+集合类场景 - 启用 pipeline：
-P 16或-P 64，否则网络 RTT 成瓶颈；注意--cluster模式下 pipeline 仍受限于单连接路由能力，不能跨 slot 批量 - 调大压测端资源：加
--threads 4（至少匹配 CPU 核数），否则客户端自身成为瓶颈
示例命令：redis-benchmark --cluster -n 1000000 -c 200 -P 32 -t set,get,incr -r 1000000 --threads 4 -q
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
为什么压测 QPS 上不去？先看这三个隐藏指标
别只盯着 redis-benchmark 输出的 “Requests per second”，集群性能卡点往往藏在服务端状态里。跑完压测后立刻执行：
-
redis-cli -c -h node1 -p 7000 info stats | grep -E "(instantaneous_ops_per_second|rejected_connections|expired_keys)"—— 看是否因连接拒绝或过期 key 频繁触发淘汰影响吞吐 -
redis-cli -c -h node1 -p 7000 info cluster | grep "cluster_state\|fail_reports"—— 检查是否有节点被误判为 fail，导致部分 slot 不可用 -
redis-cli -c -h node1 -p 7000 info memory | grep "used_memory_human\|mem_fragmentation_ratio"—— 内存碎片 > 1.5 或 used_memory 接近 maxmemory，会显著拖慢响应
特别注意：instantaneous_ops_per_second 是瞬时值，要结合 total_commands_processed 和耗时推算平均值，避免被毛刺误导。
压测结果可信吗？必须交叉验证的两个动作
redis-benchmark --cluster 给出的是理论通道能力，不代表业务能稳住。真实瓶颈常出现在网络层或内核参数上，尤其在 Ubuntu/Debian 系统：
- 检查压测机 TCP 参数：
sysctl net.core.somaxconn应 ≥ 65535，否则大量连接 pending 导致超时 - 确认 Redis 服务端未启用
transparent_hugepage：cat /sys/kernel/mm/transparent_hugepage/enabled必须是never，否则内存分配抖动引发延迟毛刺 - 用
redis-cli --latency -h node1 -p 7000在压测中实时抓延迟，比最终报告里的平均值更能暴露长尾问题
最易被忽略的一点：集群模式下，redis-benchmark 的 -c（并发连接数）是总连接数，会被均摊到所有主节点。比如 3 主节点 + -c 300，每个节点实际只有约 100 连接——若你只关心单节点容量，这个数字要反向换算。
