Redis 集群槽位迁移如何避免业务抖动：节点扩缩容、迁移窗口与失败复查

线上 Redis Cluster 准备扩容新增节点的时候，最容易被大伙漏掉的根本不是“槽位能不能迁”，而是迁移过程中业务侧的请求到底会收到什么反馈。要是刚好碰上有热点槽位在迁移半道，客户端随时可能收到重定向指令；要是迁移窗口没做限速，出问题的失败槽位也没单独留记录，等扩缩容操作完看似集群状态全绿，线上接口的延迟还是会随机抖动。

先把“业务抖动”拆成三个可观察信号

扩缩容操作的时候出现延迟升高，至少要拆分出三种不同的诱因：第一种是客户端正在拉取最新集群拓扑做重试，第二种是数据迁移本身占用了节点CPU和带宽资源，第三种是热点槽位刚好集中了大量业务访问。三种情况的处理方式完全不一样，混在一起瞎排查只会反复做无效重试。

我更建议动手之前先录一段变更前的基线数据：普通请求的P95/P99耗时、错误率、节点CPU和网络使用率、全局重定向计数，还有每个待迁移槽位的总键数量。基线不用做的多复杂，但至少要能明确回答“迁移开始之后第一个异常波动的监控指标是哪个”。

迁移窗口怎么准备：先验证客户端，再移动槽位

正式开迁之前先做完四项检查：

1. 确认源节点和目标节点都处于正常可服务状态，整个集群当前没有遗留的未处理失败槽位。
2. 确认业务使用的客户端支持Cluster拓扑自动刷新，能正确处理MOVED和ASK这类重定向返回。
3. 把所有待迁移槽位按热点程度分成不同批次，先挑低峰期、热度最低的一小批做试迁移。
4. 提前约定好强制停止条件，比如P99耗时连续多次超过基线、错误率明显上升或者重定向量异常暴涨的时候，立刻暂停下一批迁移。

这里别着急一口气把所有槽位搬完。第一批试迁移的核心目的是验证客户端的实际表现和监控指标的统计口径，不是比谁迁移速度快。试迁移全部走完之后，至少等一个完整的观察窗口，确认请求延迟和错误率都回到可接受的范围，再继续扩大迁移的批次规模。

迁移进行中：同时看状态变化和请求代价

整个迁移阶段要把集群状态指标和业务侧指标放在同一个时间轴上对照着看。一个很好用的迁移过程记录格式如下：

时间点       槽位阶段       重定向量       P99延迟       决策
10:00        试迁移开始     基线附近       42ms          继续观察
10:05        数据搬运中     明显上升       86ms          暂停下一批
10:12        迁移完成       回落           45ms          复查并恢复

要是重定向请求量短暂上涨但延迟很快就回落，一般说明客户端已经完成了拓扑更新；如果重定向数量和P99耗时一起持续往上涨，就得优先排查客户端连接池、拓扑刷新逻辑和热点槽位情况，别硬着头皮继续推进迁移。

迁移过程里的“完成”不能只靠某个集群命令返回成功就判定。要核对槽位归属是不是真的已经切换、源节点和目标节点有没有残留未处理的迁移状态，还要抽样去访问几个原本落在这些槽位里的业务键。能正常读到键只是最低要求，还要确认写入操作、超时重试逻辑没有出现异常堆积。

热点槽位导致抖动时，先减小批次再谈提速

要是某一批次的迁移操作总伴随明显的延迟尖峰，优先往热点槽位的方向排查，别想着靠无脑提升并行度解决问题。可以把热点槽位拆成更小的迁移单元，拉长每批次之间的观察间隔，同时把业务高峰时段完全排除在迁移窗口之外。

迁移速度和业务稳定性是两个互相关联的指标。对于缓存命中率很高、读写非常集中或者大键很多的槽位，短时间内强行搬运大量数据，反而会造成更久的尾延迟上涨。宁可让整个迁移窗口多持续几个小时，也别在业务错误率已经上升的时候还想着加速赶进度。

失败槽位怎么收尾：保留现场，逐项复查

迁移过程中碰到失败的槽位，别着急立刻清掉日志或者直接重跑整批迁移。先把槽位编号、源节点地址、目标节点地址、失败发生的阶段、客户端当时返回的错误还有对应时段的监控指标快照全部存下来。后面排查的时候才能确定到底是网络波动、节点资源不足、客户端拓扑没刷新，还是某一个超大热点键拖慢了整个迁移流程。

复查的顺序可以固定成下面五步：

1. 确认失败槽位当前的实际归属，以及集群本身报告的状态。
2. 确认源节点、目标节点的资源占用和连接状态已经恢复到基线附近。
3. 针对单个失败槽位做小范围重试，同步观察业务请求指标会不会再次出现抖动。
4. 重试完成后抽样做读写业务键的验证，确认客户端不会陷入重定向循环。
5. 把复查结果更新到变更记录里，标记成已完成、待观察或者需要回滚。

发布检查：用业务结果确认扩缩容真的完成

最终的验收环节至少要覆盖节点健康、槽位覆盖、失败记录、重定向趋势和业务接口这五项。所有节点都在线根本不代表扩缩容已经做完；只要还有未处理的失败槽位、重定向循环或者尾延迟没回落到基线水平，就应该保留当前的变更状态，别把还没收敛的集群直接放到下一次业务发布的操作窗口里。

• 集群报告的全量槽位覆盖完整，新增节点正常承接了规划好的对应槽位。
• 迁移期间记录下来的所有失败槽位都有明确的处理结果，没有“暂时先放着不管”的情况。
• 重定向请求量在客户端拓扑刷新完成后明显回落，没有出现客户端持续重试的情况。
• 核心读写接口的P95/P99耗时、错误率和超时率已经恢复到变更前的可接受范围。
• 完整的变更记录里提前写好了暂停条件、回滚边界和后续的观察时间点。

常见问题

迁移时收到 MOVED 是不是一定代表故障？

不一定。槽位归属变化之后，客户端需要更新本地集群拓扑来刷新路由，短暂的重定向上涨本身是正常现象；要是重定向量持续走高还伴随延迟或者错误率上升，就得检查客户端的拓扑刷新逻辑和连接池配置。

为什么集群状态正常，接口延迟还没有恢复？

集群状态只能反馈节点和槽位本身是否可用，根本代替不了业务侧指标。热点槽位访问集中、重试请求堆积或者客户端本地路由缓存没更新，都可能导致业务接口的尾延迟一直居高不下。

失败槽位应该整批重试吗？

不建议直接整批重试。先保存好失败现场，确认节点资源和运行状态都恢复正常，再针对小范围的单独槽位做重试同时观察业务指标，更容易定位到问题复现的根本原因。

什么时候应该暂停扩缩容？

当P99耗时持续超过基线、错误率明显上升、重定向形成死循环，或者失败槽位的数量持续扩大的时候，就该暂停下一批迁移，先让当前的集群状态完全收敛，做完所有复查工作再继续推进操作。

Redis Cluster扩缩容的安全感从来都来自可观察、可暂停、可复查。把迁移窗口规则、客户端适配行为、热点访问的代价和失败槽位复查流程全部放进验收清单里，整体迁移速度可能慢一点，但每一步你都清楚发生了什么，也给后续回滚和下一次变更留好了明确的操作边界。