仅靠移动槽位无法解决CPU压力不均，因它只调整数据分布而非请求分布；但它是负载均衡的前提。redis-cli --cluster rebalance显示“No rebalancing needed”却仍有CPU差异，因其仅按槽数量是否均衡判断，不考虑key数量、访问频次或命令复杂度。
直接结论：仅靠移动槽位无法解决 CPU 压力不均，它只调整数据分布，不改变请求分布；但它是调负载的前提，必须先做，否则后续优化全在错误基础上。
为什么 redis-cli --cluster rebalance 有时显示 “No rebalancing needed” 却仍有 CPU 差异？
因为该命令默认只按槽数量（16384 个）是否均匀分配来判断，不看每个槽实际承载的 key 数量、访问频次或命令复杂度。
- 现象：节点 A 有 5462 槽、节点 B 有 5461 槽，看似均衡，但 A 上集中了全部
user:1001:session类热点 key，每秒被读取上万次 - 根本原因：
CRC16(key) % 16384只保证 key 映射到槽的随机性，不保证业务语义上的离散性；{user_id}这类高基数字段若未加 hash tag，反而容易打散；但加了{user:1001}又会把所有该用户数据压进同一个槽 - 验证方式：用
cluster countkeysinslot {slot}扫描高槽号区间，再结合redis-cli --bigkeys看大 key 是否扎堆
真正有效的槽位迁移操作：用 --threshold 和 --weight 控制粒度
默认 rebalance 是“一刀切”，容易误迁冷数据；生产环境应显式约束迁移范围和目标权重。
- 先查当前分布：
redis-cli -c -h 127.0.0.1 -p 7000 cluster nodes | grep master，确认各节点 ID 和槽范围 - 手动指定源/目标节点，避免自动选错：
redis-cli --cluster reshard 127.0.0.1:7000 --from--to --slots 100 --yes - 用
--threshold 1.5表示允许节点间槽差不超过 1.5%，比默认 2.0% 更严格；--weight可给新节点设更高权重，引导流量倾斜过去（需客户端支持） - 注意：迁移期间
migrate命令会阻塞源节点，单次迁移 slot 数建议 ≤50，避免超时；大 key（>1MB）务必提前拆分，否则迁移失败且不报错
Lettuce 客户端不自动适配新槽位？检查拓扑刷新是否生效
槽位变了，但客户端仍往旧节点发请求，CPU 压力自然还在老地方——这是最常被忽略的环节。
- 关键参数必须显式开启：
adaptive.refresh=true+refresh.period=30s，否则默认 60 秒才轮询一次，且不响应MOVED错误触发的即时刷新 - 验证是否生效：在客户端日志里搜
Refreshing cluster topology，并确认时间戳间隔是否接近 30 秒 - 如果用了 Spring Boot，确保配置没被 profile 覆盖：
spring.redis.lettuce.cluster.refresh.adaptive=true必须写在 active profile 的 yml 中 - 极端情况可手动触发：
ClusterTopologyRefreshOptions.builder().enableAllAdaptiveRefreshTriggers().build()，强制监听MOVED/ASK/CLUSTERDOWN
槽位均衡后 CPU 还高？立刻排查三类隐藏热点
槽平均 ≠ 请求平均。以下问题不会因移动槽位消失，必须单独处理：
-
HGETALL或SMEMBERS扫描大集合：一个命令可能耗尽单核 100ms，监控看instantaneous_ops_per_sec高峰是否伴随evicted_keys上升 - 同一 hash tag 下的高频小 key：
{order:20260412}:status+{order:20260412}:log全落在一个槽，但业务上它们本可分散 - 客户端连接池未隔离：Lettuce 默认复用连接，若某节点连接池满，后续请求会排队等待，表现为 CPU 不高但延迟飙升——此时要调
max-inactive-time和min-idle
真正难的是把槽位、请求、连接这三层对齐。很多人调完槽就以为结束，结果发现慢查询日志里全是 KEYS * 或 LRANGE biglist 0 -1 ——这些命令本身就在制造不均衡，跟槽无关。
