redis-cli --cluster 是唯一无需外部依赖的生产级扩缩容原生命令，官方已弃用 redis-trib.rb；扩容前须确认 cluster-enabled yes、双向开放 cluster-port、新节点 cluster-config-file 为空、目标主节点有足够剩余槽位。
redis-cli --cluster 是当前唯一无需外部依赖、能稳定支撑生产级扩缩容的原生命令，redis-trib.rb 已被官方弃用且 Ruby 环境维护成本高，强行复用容易在节点角色分配、密码认证、拓扑更新等环节翻车。
扩容前必须确认的 4 个前提条件
脚本执行前若跳过这些检查，大概率导致槽位迁移卡死或客户端连接中断：
-
cluster-enabled yes必须在所有新旧节点的redis.conf中显式开启，仅靠命令行参数启动的节点无法持久化集群状态 - 所有节点间需双向开放
cluster-port（默认为redis-port + 10000），例如6379对应的集群通信端口是16379，防火墙常漏掉这个端口 - 新节点的
cluster-config-file必须是空文件或不存在，否则会加载残留的旧节点 ID，引发NOADDR错误 - 目标集群中至少有一个主节点剩余槽位数 ≥ 待迁移槽位数，否则
--cluster-reshard会直接报错退出，不提示具体缺多少
add-node 后不能直接 reshard：必须等待节点状态同步完成
执行 redis-cli --cluster add-node 后，新节点虽加入集群，但其 cluster nodes 输出中状态仍为 noaddr 或 handshake，此时立刻触发 --cluster-reshard 会失败。真实操作中需插入等待逻辑：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 轮询
redis-cli -c -h {any_node} cluster nodes | grep {new_node_id}，直到输出包含master或slave且无fail标记 - 超时阈值建议设为 60 秒，超过则人工介入检查网络连通性与
cluster-node-timeout参数是否一致 - 若新节点被错误识别为从节点（比如 IP 冲突或
nodes.conf复用），需先redis-cli --cluster del-node清理再重试
reshard 迁移槽时 --from all 的隐含风险
使用 --from all 让脚本自动均摊迁移压力看似省事，但实际会触发所有主节点并发迁移，极易打满带宽或触发 CLUSTERDOWN。更稳妥的做法是手动指定源节点：
- 先用
redis-cli --cluster check {host}:{port}查出各主节点当前槽位范围和负载（key 数量） - 优先从 key 数最少的主节点开始迁移，每次只迁 100～500 个槽，避免单次迁移耗时超过
cluster-node-timeout - 迁移命令中必须显式传入
--timeout 15000（单位毫秒），否则默认 60 秒超时，在大 key 或慢盘场景下必然中断 - 迁移过程中若遇到
MIGRATE target is busy，说明目标节点正在处理其他请求，需暂停 2 秒后重试，而非直接失败退出
缩容时 del-node 前必须清空槽位
redis-cli --cluster del-node 只删除节点元信息，不校验槽位归属。若目标节点仍有槽位未迁移，命令会成功返回但集群立即进入 CLUSTERDOWN 状态：
- 必须先用
redis-cli --cluster reshard将该节点全部槽位迁出，且迁移完成后执行cluster info确认cluster_slots_assigned与cluster_slots_ok相等 - 若节点是主节点，还需确保其所有从节点已通过
cluster failover手动升主或已被重新指派为其他主节点的从节点 - del-node 成功后，务必在所有节点上手动删除
nodes.conf文件并重启 Redis，否则下次启动可能因残留节点 ID 导致握手失败
add-node 完成 ≠ 可迁移，reshard 返回成功 ≠ 槽位已广播，del-node 返回成功 ≠ 节点彻底退出。所有判断都得基于 cluster nodes 实时输出，而不是命令返回码。
