Redis集群扩容必须先执行add-node使新节点被识别，再通过reshard迁移槽位；仅槽位分配完成不代表数据迁移结束，需看到“All keys transferred”才确认完成，否则存在数据不一致风险。
redis-cli --cluster add-node 必须先执行，否则新节点永远不被集群识别；reshard 迁移的是槽位（Slot），不是 Key，没看到 All keys transferred 就不算完成。
新节点加入前必须完成三步注册
刚启动的 Redis 实例默认是孤立进程，集群不会自动发现它。常见错误是直接跑 redis-cli --cluster reshard，结果报 No such node 或静默跳过目标节点。
- 启动前确认配置含
cluster-enabled yes和唯一cluster-config-file（如nodes-4.conf） - 执行
redis-cli --cluster add-node 192.168.1.104:6379 192.168.1.101:6379——注意顺序：新节点地址在前，已有节点在后 - 用
redis-cli -h 192.168.1.104 -p 6379 cluster nodes检查输出，该节点状态必须为master且无noaddr标记
reshard 迁移 Slot 的关键判断点
reshard 提交的是 Slot 分配计划，Key 迁移由集群后台异步触发。CLUSTER NODES 显示 Slot 已归属新节点，不等于数据已就位——这是最常误判的地方。
- 必须等
redis-cli --cluster reshard输出All keys transferred才算真正结束 - 若卡在某 Slot 不动，优先检查
16379集群总线端口是否开放，或目标节点maxmemory是否不足导致拒绝接收 - 迁移期间禁止
FLUSHALL或高频写入，否则 MOVE 请求堆积，可能触发超时重试失败
客户端无需改配置，但重定向逻辑必须健壮
连接串、IP、端口、密码全部保持原样，应用也不用重启。但如果你用的是自研客户端或老版本 redis-py（MOVED / ASK 重定向。
- 确认客户端库支持集群模式自动重试（如
redis-py的RedisCluster类） - 避免使用
--no-cluster或直连单节点模式连接集群任意节点 - 监控
redis-cli --cluster check输出中的WARN行，特别是Some keys are in wrong slot，说明部分 Key 还未完成迁移
Slot 迁移完成后容易被忽略的复制关系
新主节点虽已承载数据，但它的从节点不会自动建立复制关系。如果后续要缩容或故障切换，没有从节点会导致集群处于“无从可用”状态。
- 必须手动执行
CLUSTER REPLICATE <new-master-id>，指定新主节点的从节点 - 这个步骤无法跳过，也不能靠配置自动触发，生产环境经常漏掉
