压测前必须确认的3个拓扑细节：节点状态全为connected、master槽位无重叠或空缺、slave flags含slave且指向正确master id。
Redis集群压测前必须确认的3个拓扑细节
不检查集群拓扑就开压，90% 的「压测失败」其实和性能无关，而是节点角色错配或槽位未均匀分布导致请求被重定向甚至拒绝。CLUSTER NODES 输出里每个节点状态必须是 connected，且 master 节点的 slots 范围不能有重叠或空缺；redis-cli --cluster check 是唯一可信的校验方式，别信控制台里的“健康”图标。
- 用
redis-cli -c -h {node} -p {port} cluster slots逐节点核对槽位分配是否连续、无缺口 - 确保所有
slave节点的flags包含slave且指向正确的masterid，不是noflags或fail - 客户端连接必须带
-c（cluster mode），否则MULTI/EXEC和哈希标签（{key}）会直接报错CROSSSLOT Keys in request don't hash to the same slot
用 redis-benchmark 模拟真实流量的关键参数组合
redis-benchmark 默认是单 key 单线程打一个节点，完全无法反映集群路由开销和跨槽压力。要测出瓶颈，得强制它打满所有 master 节点并触发重定向逻辑。
- 加
-c 100（连接数）+-t set,get,mset（混合命令）+-r 1000000（key 范围足够大，避免本地缓存干扰） - 必须用
-P 10（pipeline 批次）提升吞吐，否则网络 RTT 成主要延迟源，掩盖真实服务端压力 - 禁用
-q（quiet 模式），保留每秒统计，观察requests per second是否在某节点 CPU 达到 70% 后断崖下跌——那是槽迁移或主从复制拖慢了响应
chaos-mesh kill node 后业务中断的 2 种典型表现及定位路径
不是所有「连接超时」都等于故障；Redis 集群的 failover 有默认 5 秒检测窗口，这期间客户端行为取决于 SDK 实现。常见问题根本不在 Redis 侧，而在客户端重试策略。
- 现象：kill slave 后写入立刻报错
MOVED或ASK——说明客户端没启用ASKING指令支持，或缓存了旧的 slot 映射（如 Jedis 的ClusterCommand未刷新） - 现象：kill master 后 5 秒内读写全挂，但 6 秒后恢复 ——这是正常 failover 周期，但如果业务要求亚秒级切换，就得调小
cluster-node-timeout（注意：低于 3000ms 可能引发误判脑裂） - 验证方法：在 client 侧抓包看是否发出
CLUSTER SLOTS请求；用redis-cli -c手动连新 master 测试能否执行GET，排除配置同步延迟
为什么用 chaosblade 做网络分区比直接 kill 更贴近生产故障
真实机房故障极少是整机宕机，更多是网卡丢包、DNS 解析失败、TLS 握手超时这类「软性隔离」。直接 kill 节点只会触发 failover，但掩盖了客户端因短暂抖动反复重连、连接池耗尽的真实雪崩路径。
- 用
chaosblade create network delay --interface eth0 --time 3000 --offset 500模拟高延迟，观察业务方timeout配置是否覆盖了cluster-node-timeout + 网络毛刺 - 用
chaosblade create network loss --percent 30测试客户端连接池是否自动剔除不可用节点（Lettuce 支持，Jedis 不支持） - 关键检查点：压测中
redis-cli -c cluster nodes输出里是否有节点状态卡在handshake或noaddr——说明 gossip 协议已断裂，但进程还在，此时集群看似「活着」，实则无法达成共识
真正难测的不是扛住多少 QPS，而是当 1 个 master 和它对应的 2 个 slave 同时网络不可达时，剩余节点能否维持读写、客户端会不会把请求发向已失联节点并堆积连接。这些得靠持续 10 分钟以上的混沌实验才能暴露，不是跑一遍脚本就能确认的。
