Redis 7.0 中 redis-cli --cluster reshard 是唯一安全、在线、可控的槽位不均修复手段；需严格按“选目标、定数量、挑来源、确认执行”四步操作，避开客户端缓存未刷新、源节点负载突增、目标节点内存不足三大陷阱，并交叉验证 slots 与 keys 分布比值及内存真实水位。
槽位分配不均 ≠ 数据倾斜，但它是数据倾斜的放大器；Redis 7.0 的 redis-cli --cluster reshard 是唯一安全、在线、可控的修复手段，别碰手动 CLUSTER SETSLOT 或脚本遍历迁移。
怎么确认是真·槽位不均，而不是假警报
很多团队看到 redis-cli --cluster info 里某节点 slots: 3277、另一节点 slots: 3276 就以为“基本均匀”，其实危险信号已经出现——slots 差不到1%，但 keys 差5倍以上，说明槽位虽平，数据却扎堆。必须交叉验证：
- 用
redis-cli --cluster info 192.168.1.10:7001查各节点keys和slots数，算 keys/slots 比值，偏离均值 ±20% 就要警惕 - 用
redis-cli -h 192.168.1.10 -p 7001 info memory | grep used_memory_human看真实内存占用，避开mem_fragmentation_ratio > 1.5导致的“假高水位”干扰 - 跑
redis-cli -h 192.168.1.10 -p 7001 --bigkeys -i 0.01，一个 8MB 的String或含 20 万成员的Hash就足以让单节点 CPU 持续 90%
为什么 reshard 是 Redis 7.0 唯一推荐方式
Redis 7.0 废弃了旧版集群管理工具，redis-cli --cluster reshard 是官方唯一保留的在线槽迁移入口，它自动处理 MIGRATE、SETNODE、ADDSLOTS 等底层命令组合，规避人为漏步风险。常见错误包括：
- 填迁移槽数量时输错：不能为
0，也不能超过16384，输错直接退出，无提示 - 目标节点 ID 复制不全：必须从
redis-cli -c -h 192.168.1.10 -p 7001 cluster nodes输出中完整复制（如2728a594a0498e98e4b83a537e19f9a0a3790f38），少一位或大小写错都报No such node - 源节点填
all后卡住：如果某主节点正在执行BGSAVE或内存不足，reshard 会停在Source node 1:不动，需先redis-cli -h 节点IP -p 端口 info persistence检查 RDB 状态
reshard 后客户端还在打老节点？不是命令失败，是路由没刷新
这是 Redis 7.0 集群最常被误判的问题：reshard 成功不代表流量立刻切走。Lettuce、Redisson 等客户端只在收到 MOVED 响应时才永久更新 slot-node 映射，而迁移过程中返回的是 ASK（临时重定向），不会触发路由表刷新。结果就是：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 已复用的连接池里的旧连接，仍按迁移前的 slot 表发请求，持续打错节点 30–90 秒，直到连接自然超时重建
- 业务代码若用了
@Bean public LettuceClientConfigurationBuilderCustomizer但没配DynamicNodesProvider，则永远不感知新拓扑 - 测试用
redis-cli -c没问题，是因为每次命令都是新连接，能立即收到MOVED
验证方法：在客户端侧加日志，捕获 RedisCommandExecutionException 是否含 MOVED 字样；线上可临时 redis-cli -c -h 192.168.1.10 -p 7001 get somekey 看是否返回 MOVED 并跳转成功。
什么时候该用 rebalance 而不是 reshard
redis-cli --cluster rebalance 是自动计算型操作，适合“整体偏斜但无明确目标”的场景；reshard 是人工指定型，适合精准补槽、扩容加节点、缩容清空某节点。关键区别：
-
rebalance默认只在主节点间搬槽，若你刚加了一个空 master 节点，必须显式加--cluster-use-empty-masters，否则它永远分不到槽 -
rebalance一次可能搬上千槽，引发短时带宽和 CPU 尖峰；reshard可控到精确数字（比如只搬 128 个），更适合生产环境灰度 - 跨机房/跨可用区节点混布时，
rebalance会拒绝迁移（防跨区域流量），而reshard允许你手选源节点 ID，强制执行
真正难的从来不是“怎么搬槽”，而是搬完后要不要改 HashTag、要不要拆 bigkey、客户端连接池要不要 reload ——这些动作不跟上，槽位再平均，负载照样歪。
