搬槽是什么
集群扩容的核心动作是搬槽：把一部分哈希槽从旧节点迁移到新节点，槽内的键会分批用 MIGRATE 搬过去，迁移期间相关槽的请求可能收到 ASK 重定向。redis-cli 的 --cluster reshard 把「指定目标节点、选择槽、迁移、更新配置」串成一条流程，迁完再用 --cluster check 验证槽分布是否符合预期。
基本信息
| 命令 | redis-cli --cluster reshard <任意节点地址> |
|---|---|
| 关键参数 | --cluster-from / --cluster-to / --cluster-slots / --cluster-yes |
| 迁移单元 | 哈希槽，槽内键分批搬运 |
| 验证 | redis-cli --cluster check 与 CLUSTER INFO |
| 分配原则 | 按节点规格比例分配槽，而不是简单平均 |
典型使用场景
- 集群扩容后把新节点纳入负载分担
- 单节点数据倾斜，需要重新均衡槽分布
- 下线某个节点前把它的槽全部迁走
- 规格调整后按新规格重新分配容量
- 演练搬槽流程，记录不同数据量下的实际耗时
迁移流程
迁移流程
# 交互式：推荐先用它看清楚每一步提示
redis-cli --cluster reshard 10.0.0.1:6379
# 脚本化：
redis-cli --cluster reshard 10.0.0.1:6379 \
--cluster-from <源node-id> \
--cluster-to <目标node-id> \
--cluster-slots 1000 \
--cluster-yes
# 验证：
redis-cli --cluster check 10.0.0.1:6379
redis-cli -p 6379 CLUSTER INFO | grep slots_assigned阶段与风险
| 阶段 | 关注点 | 风险 |
|---|---|---|
| 选择槽数 | 按目标节点规格与数据量计算 | 一次搬太多会长时间占用带宽 |
| 迁移执行 | 槽内键分批 MIGRATE | 大槽迁移耗时以分钟甚至小时计 |
| 重定向 | 相关槽返回 ASK | 客户端不支持 ASK 会随机失败 |
| 配置更新 | 槽归属写入节点配置 | 中断流程会留下迁移中间态 |
| 验证 | check 看槽分布是否均衡 | 只看已分配槽数会漏掉倾斜 |
迁移期间要盯住客户端的 ASK 重定向比例与延迟：比例突然升高通常说明客户端对 ASK 支持不好或反复重试，应先在预发环境验证客户端能力。
不看数据量直接搬是危险的：单个大槽可能包含百万级键，迁移耗时不可预测，放在业务高峰就是事故。安排在低峰，并提前评估网络带宽与磁盘 IO。
可以用 --cluster-pipeline 控制迁移批次大小，牺牲一点速度换取对线上延迟更小的影响；迁移过程中不要中断控制台，否则要人工收尾中间态。