redis集群qps分布不均主因是客户端未及时刷新拓扑映射，导致请求集中到首个连接节点；需检查jediscluster、lettuce、redis-py-cluster等客户端的自动刷新配置并强制重载cluster slots。
Redis集群中QPS分布不均，先确认客户端是否识别了完整拓扑
集群节点QPS严重倾斜（比如 7001 节点 QPS 8 万，7002/7003 接近 0），大概率不是数据分布问题，而是客户端压根没走集群路由——它把所有请求都发给了第一个连上的节点，误当成单机用。
Redis 客户端（如 JedisCluster、Lettuce、redis-py-cluster）依赖 CLUSTER SLOTS 或 CLUSTER NODES 响应来构建本地 slot→node 映射表。这个映射不是永久有效的：节点上下线、故障转移、reshard 后，旧映射会失效。如果客户端没启用自动刷新，就会持续往过期的地址发请求，造成“假性热节点”。
- Java JedisCluster 默认开启拓扑刷新，但需确认是否禁用了：
new JedisCluster(..., new GenericObjectPoolConfig(), 2000, 2000, "password", Protocol.DEFAULT_PROTOCOL)中若传入refreshPeriod≤ 0，则关闭刷新 - Lettuce 的
ClusterClientOptions必须显式设置autoReconnect(true).topologyRefreshOptions(TopologyRefreshOptions.builder().enableAllAdaptiveRefreshTriggers().build())，否则默认只在连接断开时刷新一次 - redis-py-cluster 默认不自动刷新，需手动调用
client.nodes_manager.reset()或启用startup_nodes+skip_full_coverage_check=True并配合定时重载
验证客户端是否命中了错误节点
直接抓包或打日志看请求目标 IP 和端口。更轻量的方法是登录高负载节点，执行 client list，检查 addr 字段是否大量集中于某几个客户端 IP+端口（尤其是同一个进程多个连接），且 cmd 列全是 get/set 这类简单命令——这是典型“绕过集群直连”的特征。
再对比低负载节点的 client list，如果几乎没连接，或只有 ping/cluster 类管理命令，基本坐实拓扑未刷新。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 不要只信监控里的“QPS per node”，有些监控工具本身依赖客户端上报，可能失真；以
redis-cli -h 7001 -p 7001 client list | wc -l实际连接数为准 - 若发现高负载节点上存在大量
addr=10.0.1.5:54321连接，而该客户端配置里明明写了三个 seed 节点，说明它连上第一个后就没再查 slot 表
强制触发拓扑刷新并观察效果
不重启服务也能验证：让客户端主动丢弃旧映射，重新拉取 CLUSTER SLOTS。不同客户端操作不同，但核心都是“清空缓存+触发重发现”。
- JedisCluster：调用
cluster.refreshNodes()（非 public 方法，需反射）或更稳妥地重建实例（注意连接池复用问题） - Lettuce：调用
redisClusterClient.reloadPartitions()，它会同步阻塞直到新拓扑加载完成 - Go redigo-cluster：需手动调用
cluster.Refresh()，否则永远用初始 seed
刷新后立刻观察各节点 instantaneous_ops_per_sec，30 秒内应快速趋于均衡。如果仍不均，问题不在拓扑，转查 KEYS、热 Key 或客户端哈希逻辑（比如硬编码了 key % 3）。
为什么拓扑刷新容易被忽略
这个问题隐蔽性强：业务上线初期集群稳定，客户端能正确建立映射；但某次主从切换后，旧 master 的 IP 被新节点复用，或运维手动 CLUSTER FAILOVER，客户端却因刷新间隔太长（如设为 60 秒）或触发条件不足（如只监听 MOVED 不监听 ASK），导致映射卡在错误状态长达数小时。
最麻烦的是部分 SDK 文档模糊，比如某 Python 客户端声称“自动刷新”，实际只在连接异常时尝试重连，不主动轮询 CLUSTER SLOTS。线上跑一周不出问题，一出就是雪崩级倾斜。
