零宕机扩容可行但须严格遵循slot分配、网络连通与状态确认流程；新节点需完成注册→握手→身份确认三步，缺一不可；reshard迁移slot非key，须待“all keys transferred”提示才完成；客户端无需改配置，但须适配moved重定向。
零宕机扩容在生产环境是可行的，但前提是严格遵循 Slot 分配逻辑、网络连通性与状态确认流程；任何跳过 redis-cli --cluster add-node 握手或忽略 All keys transferred 提示的操作，都会导致客户端持续收到 MOVED 重定向甚至请求失败。
新节点必须完成注册→握手→身份确认三步，缺一不可
刚启动的新 Redis 实例只是个孤立进程，集群完全“看不见”它。常见错误是启动后直接跑 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，不是 Key；迁移未完成时客户端必然被重定向
reshard 命令提交的是 Slot 分配计划，Key 迁移由集群后台异步触发。CLUSTER NODES 显示 Slot 已归属新节点，不等于数据已就位。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须等待
redis-cli --cluster reshard输出All keys transferred才算真正结束 - 若卡在某 Slot 不动，先检查
Connection refused或超时——大概率是 16379 集群总线端口未开放，或目标节点maxmemory不足拒绝接收 - 迁移期间禁止
FLUSHALL或高频写入，否则 MOVE 请求堆积，可能触发超时重试失败
客户端完全无需改配置，但需适配重定向逻辑
连接串、IP、端口、密码全部保持原样，应用也不用重启。但如果你用的是自研客户端或老版本 redis-py（ASK/MOVED 重定向。
- 确认客户端库支持集群模式自动重试（如
redis-py的RedisCluster类） - 避免使用
--no-cluster或直连单节点模式连接集群任意节点 - 监控
redis-cli --cluster check输出中的WARN行，特别是Some keys are in wrong slot，说明部分 Key 还未完成迁移
最易被忽略的点：Slot 迁移完成后，新节点虽已承载数据，但它的从节点尚未自动建立复制关系。如果后续要缩容或故障切换，必须手动执行 CLUSTER REPLICATE <new-master-id></new-master-id> 指定新主节点的从节点，否则集群会处于“无从可用”状态。
