Redis集群伸缩后数据迁移的核心是槽的重新分配与键值平滑搬运，支持在线操作且业务无感知；新节点加入后需通过reshard或rebalance分配槽位才能承载数据，迁移过程依赖CLUSTER GETKEYSINSLOT、MIGRATE和CLUSTER SETSLOT等命令协同完成，客户端通过MOVED重定向自动适配，验证需结合CLUSTER SLOTS、CLUSTER KEYSLOT及实际读取确认。
Redis集群伸缩后的数据迁移，核心是槽（slot）的重新分配与对应键值的平滑搬运，整个过程支持在线操作，业务无感知。
新节点加入后必须分配槽位
执行redis-cli --cluster add-node只是让新节点“入群”，它此时不持有任何槽，无法承载数据。若跳过这步直接写入，请求仍会路由到原有节点——新节点处于闲置状态。必须通过reshard或rebalance触发槽迁移，才能真正分担负载。
- 使用
redis-cli --cluster reshard进入交互式流程，手动指定迁移槽数量、目标节点ID和源节点范围 - 也可用
redis-cli --cluster rebalance自动均衡：它基于各节点当前槽数量、内存使用率等指标，计算最优分配方案 - 注意：rebalance默认只在槽分布偏差超过阈值时才触发迁移，如需强制重平衡，可加
--cluster-weight参数调整权重
迁移过程本质是键的逐批搬运
每个槽关联若干键，迁移不是复制整个槽，而是按批次获取键、迁移、确认。底层由Redis内部命令协同完成：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
CLUSTER GETKEYSINSLOT slot count：从源节点拉取一批属于该槽的键 -
MIGRATE target_host target_port key 0 timeout：将单个键原子迁移到目标节点 -
CLUSTER SETSLOT slot NODE node_id：最终将槽归属关系更新到全集群
整个过程对客户端透明，客户端收到MOVED重定向响应后自动重试，无需修改代码。
验证迁移是否真正生效
不能只看CLUSTER NODES里新节点是否有槽号，还要确认数据实际落点是否正确：
- 用
CLUSTER SLOTS查看每个节点负责的槽区间，确认新节点已分配连续或合理的槽段 - 用
CLUSTER KEYSLOT key算出某键应属槽位，再查该槽当前归属节点，交叉验证 - 随机选取几个键，用
GET key并观察返回是否来自新节点（可通过CLIENT LIST查连接来源端口辅助判断）
避免常见陷阱
迁移看似自动化，但几个细节容易引发问题：
- 网络延迟过高或超时设置过短，会导致MIGRATE失败，迁移卡住；建议调大
cluster-node-timeout至15秒以上 - 源节点内存不足或目标节点OOM，会使键迁移失败；迁移前应检查两节点剩余内存
- 若使用自定义客户端（非官方SDK），需确认其支持MOVED/ASK重定向，否则可能持续打错节点
- 不要在迁移中途执行
FLUSHALL或大规模KEYS操作，会干扰槽状态同步
