来，先说个场景：某个线上服务半夜报警，Redis内存和CPU一路飙升，三分片的Cluster已经跑了大半年，马上要接一波活动流量，扩容的事情已经拖了三周。真到要动的时候，问题就来了——存量在线的数据怎么平滑迁到新节点？Redis Cluster数据迁移，这是每次扩容、缩容、均衡slot时绕不开的一关，也是运维手里最容易翻车的操作之一。
这篇文章就围绕“Redis Cluster数据迁移”这件事展开，讲清楚迁移到底在搬什么、有哪些工具和方案可选、一次完整的在线迁移该怎么操作，同时把我这些年踩过的坑一并列出来。不管你是刚接手集群的运维，还是准备做架构改造的开发者，看完之后至少能知道：动手前要确认什么、迁移中怎么盯、出问题怎么收场。
1. 先搞懂一件事：Redis Cluster迁移到底在搬什么？
很多同学第一次做数据迁移，第一反应是“把数据从一个节点复制到另一个节点”，这个理解不能说错，但很容易让你在真正操作时抓瞎。因为Redis Cluster的数据搬迁，本质上不是“节点对节点”的数据复制，而是“slot所有权”的转移。
1.1 slot是数据分布的最小单位
Redis Cluster把整个键空间切成16384个哈希槽（hash slot），每个key通过CRC16算法计算出一个值，再对16384取模，落到对应的slot上。这个计算是写死在客户端逻辑里的，任何Redis实例都能独立算出来。
一个Cluster集群启动后，我们做的第一件事就是把16384个slot分配给各个主节点。比如三个主节点，理想情况下每个节点分到大约5461个slot，数据也就跟着slot散布到各个节点上。slot和node之间的归属关系，构成了整个集群的路由表。
所以在Cluster的世界里，迁移的最小单位不是key，而是slot。我们要搬数据，实际上是在问：某个slot现在归A节点管，我想让它归B节点管，那么借着所有权转移的机会，把这个slot里的key从A搬到B。
1.2 一次slot迁移包含三个阶段
从操作表象上看，一次slot迁移是下面这个过程：
- 在目标节点上，把一个slot标记为
IMPORTING状态，表示“我准备接收这个slot”。 - 在源节点上，把同一个slot标记为
MIGRATING状态，表示“我准备把这个slot送走”。 - 源节点把这个slot里的key逐个通过
MIGRATE命令搬到目标节点。 - key全部搬完后，在目标节点上执行
CLUSTER SETSLOT <slot> NODE <目标节点ID>，正式宣布这个slot归目标节点所有。 - 在源节点上也执行同样的归属变更，让源节点放行这个slot，并向集群广播新的路由。
这个流程要盯住的关键点是：迁移不是“切一刀”立刻完成，而是有个中间态。在中间态下，如果客户端访问这个slot里的key，源节点会看这个key是否已经搬走——没搬走就直接服务；搬走了就会返回一个ASK重定向，让客户端去目标节点取。这是Cluster正常运作的一部分，也是在线迁移能不停机的根本原因。
1.3 什么时候需要迁移数据
我归纳下来，日常运维里大概有四类场景：
- 扩容：集群规模跟不上业务增长，加新节点后必须从旧节点匀一部分slot过去，这才是真正意义上的扩容。
- 缩容：业务量下降，想把部分节点退掉，需要先把这台节点上的slot全部搬到别的节点，再把节点从集群里剔除。
- 平衡调度：新增节点后没做均衡，或者历史原因导致某些节点slot数量严重不均、单节点热点明显，需要重新分配slot。
- 节点替换：某台老机器要下线、硬件要升级或机房要调整，也要先把数据迁走再替换。
- 跨集群同步：比如上云、两套集群之间做数据同步，这种更接近“整体数据复制”，和前面几种的机制不太一样，后面细说。
搞清楚了“迁移=搬slot”这个本质，后面所有操作、参数、坑，你都能串联起来。
2. 动手前先想清楚：在线还是离线，用什么工具
很多人在迁移前最纠结的就是“用哪个命令、怎么敲”。其实在我看来，工具是次要的，方案选型才是决定成败的那一步。你选在线还是离线，决定了你能接受多长的停机时间、要预留多少带宽、出了事怎么回滚。
2.1 在线迁移：默认选择，但不是无脑选择
在线迁移的好处很明显：业务不用停，数据一边搬一边服务，整体过程用户无感或者感知很小。Redis 3.0之后，Cluster自带的redis-trib.rb（Redis 5.0之后集成到redis-cli --cluster）走的就是在线迁移路线，这也是我最常用、最推荐的方案。
但在线迁移不是没有代价。它有两个硬约束：
- 带宽。数据是实打实从源节点往目标节点传的，如果业务流量本身就大，迁移会和你正常的读写抢带宽。我见过一次迁移把内网带宽打满，业务超时率直接飙升的事故。
- 目标节点内存。迁过去的key要落在目标节点上，目标节点的内存必须能接住这些数据，建议预留20%到30%的余量，别顶到maxmemory才想起来不够。
在线迁移还有一个隐含要求：尽量避开业务高峰。虽然它不用停服，但峰值期间做迁移，key一热，MIGRATE命令在源节点上搬运热key时可能会短暂阻塞，用户能感知到延迟抖动。所以我的习惯是：凌晨低峰期做在线迁移，白天做验证和观察。
2.2 离线迁移：什么时候选它
离线迁移意味着要停写或者停服，把数据打成快照搬到新集群。典型场景是：老旧集群版本太低、Cluster结构差异太大（比如从单机/主从架构迁到Cluster）、跨机房整体搬迁，或者目标集群和源集群之间的协议版本差距过大，在线同步不可控。
常用的做法是：源集群用 RDB 持久化文件或者redis-cli --rdb导出一份快照，再通过导入工具恢复到目标集群。如果数据量不大、业务能接受一段维护窗口，这个方案比在线迁移简单直接得多，回滚也清晰——导入出问题就再导一次。
不过要注意，RDB快照是某个时间点的数据，导入期间如果有新写入，这些增量会丢。所以离线迁移通常要配合停写窗口，或者在导入完成后做一轮增量补偿。整体上，离线迁移适合“可以停机”的场景，在线迁移适合“不能停机”的场景，二者没有绝对的优劣。
2.3 工具选型与迁移成本估算
先看看有哪些工具可用。
redis-cli --cluster系列命令：Redis 5.0开始官方钦定的运维工具，包含reshard、rebalance、fix、add-node、del-node等。绝大多数在线迁移用这一套就够了。- 旧版
redis-trib.rb：老集群升级前，如果你还停留在Redis 3.x/4.x，那只能用它。本质是一个Ruby脚本，封装的逻辑和redis-cli --cluster基本一致。 - 开源的数据同步工具：适合跨集群场景，原理通常是解析源库RDB做全量复制，再模拟从库协议或读取增量命令做增量同步。好处是能实时追平增量，比“RDB导入+补偿”更省心，但这类工具配置相对复杂，需要结合版本去验证。
工具尘埃落定之后，我建议先做一个粗略的迁移成本估算，别上来就搬。估算公式不复杂：
迁移耗时 ≈ 待迁移数据量 ÷ 平均迁移速度举个例子：一个12分片的集群，总数据量约800GB，要扩容到15分片。假设你决定从所有旧节点各匀一部分slot，那么待迁移数据量大概是总数据量的三分之一，约270GB。实测在万兆内网、普通SSD、key平均大小1KB左右的情况下，在线迁移速度大约每秒5到10MB，取个中间值8MB/s，理论耗时大约9个小时。
这个9小时只是一个非常粗糙的量级参考——大key越多、源节点负载越高、业务流量越大，实际速度只会更慢。但它足以说明一件事：百GB级别的在线迁移，不是喝杯咖啡就能等完的，必须按照“通宵窗口+分批次执行+过程监控”的节奏来规划，千万不要排成白天两小时搞完。
3. 完整实操：扩容、均衡、缩容的一次迁移记录
方案定好了，工具选好了，接下来就是动手环节。我尽量把一次完整的“扩容+迁移”过程写出来，里面包含命令、参数含义和现场经验，你照着做基本能复现。
3.1 扩容第一步：把新节点加进集群
假设现在有两台新机器，IP分别为10.0.0.5和10.0.0.6，我们要把它们作为两个主节点加入现有的三主集群。
先看集群现状：
redis-cli -h 10.0.0.1 -p 6379 cluster nodes记下各节点的节点ID（node-id），后面很多命令都要用到。然后用add-node把新节点加进来：
redis-cli --cluster add-node 10.0.0.5:6379 10.0.0.1:6379 redis-cli --cluster add-node 10.0.0.6:6379 10.0.0.1:6379命令的第一个地址是新节点，第二个地址是集群里任意一个老节点。执行完之后，新节点已经出现在集群节点列表里，但它还没有分配到任何slot，此时它是个“光杆主节点”，不持有数据、不承担读写。
有的架构为了高可用，会给新主节点加从节点。做法是先登录从机执行cluster meet建立握手，再执行：
redis-cli -h 10.0.0.7 -p 6379 cluster replicate <新主节点ID>replicate会让这台从机去复制指定主节点的数据。对于扩容场景，我习惯先只加主节点，等slot迁移完成、验证数据正常之后，再补从节点。因为迁移过程本身会产生大量数据同步，如果一开始就挂从库，从库复制压力和被迁移数据量叠加，容易拖慢节奏。
3.2 重新分片：一条命令完成在线迁移
新节点加进来、cluster nodes能看到全貌之后，在线迁移的核心操作就是reshard。
redis-cli --cluster reshard 10.0.0.1:6379 \ --cluster-from <源节点ID1>,<源节点ID2>,<源节点ID3> \ --cluster-to <新节点ID1> \ --cluster-slots 4096 \ --cluster-yes命令参数拆开看：
10.0.0.1:6379：集群中任意一个节点地址，工具会从这里读取集群拓扑。--cluster-from：指定从哪些源节点搬slot。可以指定多个节点ID，用逗号分隔；如果不指定，工具会按当前slot分布自动从所有主节点均匀抽取。--cluster-to：目标节点ID，也就是新加入的节点。--cluster-slots：要迁移的slot数量。5个主节点的理想分布是每个节点约3277个slot，所以给新节点补4096个只是第一步，之后还需要再跑一轮rebalance让分布更均匀。更稳妥的做法是先迁移一部分，观察性能和状态，再继续。--cluster-yes：跳过交互确认。不加这个参数，工具会先打印一份迁移计划，让你输入 yes 确认。新手阶段我建议先不加，看清楚它要搬哪些slot再确认。
reshard执行过程中会输出进度信息：正在迁移哪个slot、从哪个节点到哪个节点、还剩多少key。如果迁移量大，建议开个终端挂着日志，另开一个终端做监控。
3.3 手工迁移的底层流程，理解一次就够
只看reshard命令的日志，可能还是觉得它是黑盒。我建议你至少手工跑通一次小范围的slot迁移，这样以后工具出了问题，你知道它内部在干什么，也知道怎么手动收尾。
手工迁移的核心命令如下，用bash脚本示意：
SRC_HOST=10.0.0.1 DST_HOST=10.0.0.5 SRC_ID=<源节点ID> DST_ID=<目标节点ID> SLOT=1234 # 第一步：目标节点标记 importing redis-cli -h $DST_HOST cluster setslot $SLOT importing $SRC_ID # 第二步：源节点标记 migrating redis-cli -h $SRC_HOST cluster setslot $SLOT migrating $DST_ID # 第三步：循环取key并迁移 while true; do KEYS=$(redis-cli -h $SRC_HOST cluster getkeysinslot $SLOT 10) if [ -z "$KEYS" ]; then break fi redis-cli -h $SRC_HOST migrate $DST_HOST 6379 "" 0 5000 replace $KEYS done # 第四步：宣布新归属 redis-cli -h $DST_HOST cluster setslot $SLOT node $DST_ID redis-cli -h $SRC_HOST cluster setslot $SLOT node $DST_ID这段脚本有几点需要解释：
getkeysinslot <slot> <count>是从源节点批量取出该slot下最多count个key。MIGRATE命令格式是：MIGRATE 目标地址 目标端口 "" 超时时间 [选项] [KEY...]。Redis 3.0.6之后支持一次携带多个key，效率远高于逐key迁移。脚本里取一批、迁一批，直到这个slot的key取完，正好对应工具内部的做法。replace选项的作用是：如果目标节点上已经存在同名key，直接覆盖。迁移重试场景下必须加，否则会报BUSYKEY错误。- 迁移代码的关键循环是“每个slot的key是有限的”，所以
getkeysinslot不可能永远返回key，总会在某次返回空，循环自然结束。
手工做完整套流程，你对reshard工具背后的逻辑就心里有数了。万一工具中途崩溃、留下了一堆MIGRATING/IMPORTING状态，你也能看清状态、手动推进或回退。
3.4 缩容：把要退的节点搬空再摘掉
缩容是扩容的逆操作，逻辑更简单，但很多人会翻车。唯一的区别是：缩容前必须把待下线节点上的所有slot全部迁走，迁到剩下节点中，然后再做物理下线。
具体步骤：
- 记下待下线节点的节点ID。
- 用
reshard把这个节点上的slot迁到别的节点：
redis-cli --cluster reshard 10.0.0.1:6379 \ --cluster-from <待下线节点ID> \ --cluster-to <保留节点ID> \ --cluster-slots <该节点当前slot总数> \ --cluster-yes- 确认该节点不再持有任何slot：
redis-cli -h 10.0.0.1 -p 6379 cluster nodes- 从集群中移除该节点：
redis-cli --cluster del-node 10.0.0.1:6379 <待下线节点ID>del-node 会同时做两件事：发送CLUSTER FORGET让其他节点遗忘它，并尝试关闭该节点实例。如果这台节点上还有从节点，记得先下线或迁移从节点。
这条流程中最容易犯的错是：还没把slot迁干净就执行del-node，结果del-node直接报错，其实还好。真正危险的是你图省事，直接把节点kill掉，留下大量未指派的slot，在默认cluster-require-full-coverage yes的情况下整个集群会进入CLUSTERDOWN拒绝服务。节点可以“粗暴”下线，后果必须提前想清楚。
3.5 跨集群迁移和它的补充方案
前面讲的都是集群内部的slot迁移，也就是同一套Cluster里的数据搬移。但实际工作中还会遇到跨集群的场景，比如自建集群往云上迁、两套独立Cluster之间合并。
跨集群迁移和slot迁移是两个量级的事，通常有两条路：
- 一条是停写窗口+RDB全量导入。优点是最简单，缺点是窗口长、增量难补。
- 另一条是用开源同步工具做全量+增量同步。工具会先拉取源集群的全量数据写入目标集群，再通过模拟从库增量或解析命令流的方式追平源集群的写入，等追平后再切换流量。
如果业务允许，我建议优先考虑“同步工具全量+增量”方案，因为它的切换窗口可以压缩到分钟级。使用这类工具前，要特别关注源和目标Redis版本的兼容性，以及Cluster模式下的key路由是否保留一致。能复用一套同步链路，尽量不要手动造轮子，这类工具踩过的坑比我们临时想的方案多得多。
4. 迁移中的坑与排障实录
迁移本身的命令不难，难的是中间态和异常处理。这一节我把实际运维中遇到最多的几类问题整理成速查表，再挑几个典型的现场展开讲讲。
4.1 高频问题速查表
| 现象 | 根本原因 | 处理建议 |
|---|---|---|
集群整体CLUSTERDOWN，所有请求失败 | 迁移中断遗留下未指派slot，且cluster-require-full-coverage保持默认yes | 用redis-cli --cluster fix修复slot分配；如果不想全网停服，评估是否设置cluster-require-full-coverage no |
客户端大量收到MOVED重定向 | 目标节点接管slot后，客户端路由表还没刷新 | 升级到支持Cluster路由刷新的客户端，检查客户端集群拓扑更新配置 |
客户端收到ASK重定向 | slot处于迁移中间态，key已被搬到目标节点 | 正常现象，新客户端会自动跟随；老客户端要人工重试 |
| 迁移速度突然变慢，甚至卡住不动 | 源节点出现大key；单个key的迁移耗时被MIGRATE超时限制卡住 | 迁移前扫描大key，提前拆key或单独处理；调大--cluster-timeout |
| 目标节点内存飙升到maxmemory，触发淘汰或OOM | 没做容量评估，迁移数据量超过目标节点承载 | 迁移前计算目标节点剩余内存，预留20%以上余量 |
| 迁移期间业务读写延迟抖动 | 迁移占满内网带宽，或热key被迁移时短暂阻塞 | 低峰期操作；分批迁移；必要时做限速，比如每个slot迁移完sleep一段时间 |
4.2 三个印象深刻的现场
现场一：漏了一个slot，集群直接雪崩
有一次做节点替换，我先把旧节点的slot迁走了大半，打算第二天再收尾。结果半夜有个脚本触发了一次cluster failover，集群里某个节点状态异常，恢复后gossip选举出现了问题，几个slot的归属信息丢失，集群直接CLUSTERDOWN。业务方当晚疯狂打电话，我赶到现场第一件事是用fix把未指派的slot重新分配，恢复后才去查根因。
这个教训让我记住两条：第一，迁移要么一口气干完，别留半截；第二，中途休息或切换状态前，先用redis-cli --cluster check确认所有slot都有归属，再离开现场。
现场二：一个大key卡住整个slots队列
做一次reshard时，日志停在某个slot上不动了，进度条纹丝不动。排查发现这个slot里有一个几十MB的value，MIGRATE单次传输这个key耗时极长，超过了默认的迁移超时，工具反复重试、反复超时，后面的key全部堵住。
解决方式不复杂：提前用redis-cli --bigkeys或scan扫描大key，把明显超出常规大小的key单独拎出来处理——有的拆成多个小key，有的先用业务手段降频写入，再迁移。从那以后，“迁前扫大key”列入了我的标准动作。
现场三：80%带宽被迁移吃掉，业务超时飙升
白天临时起意做个扩容，想着在线迁移“不用停服”，结果忽略了对带宽的占用。集群几台节点之间互相传数据，内网流量一路飙到峰值，正常的读写请求被挤得超时。那一次是紧急暂停迁移、让业务恢复稳定之后，老老实实改到凌晨再做，并且做了分批迁移。
后来我再做在线迁移，都会先看一眼内网流量监控，规划好迁移速率，必要时用脚本在每批slot之间加上间隔，把瞬时带宽压下去。工具给了统一的--cluster-pipeline参数可以调整批量大小，但很多时候现场的限速还得靠自己的节奏控制。
5. 迁移之后：验证、回滚与复盘
迁移完成不是终点，真正的终点是你确认新集群状态稳定、业务无感、回滚方案可执行。这一节说几个迁移后必须做的事。
5.1 迁移后的验证清单
第一步，先跑一遍官方检查：
redis-cli --cluster check 10.0.0.5:6379它会检查所有节点的主从状态、slot覆盖率、每台节点的slot数量是否均衡。如果有slots not covered之类的输出，说明迁移还没真正完成。
第二步，对比迁移前后的数据量。以源节点为例，迁移前记录它的dbsize，迁移后看它的slot占用是否等于0或者符合预期；目标节点的新增数据量要和迁入slot数量大致匹配。更细一点，可以用CLUSTER COUNTKEYSINSLOT <slot>抽查几个边缘slot。
第三步，业务侧做读写验证。我通常会挑夜里流量低谷时，让测试脚本对原集群和新集群写入同一批key，再读出来对比。如果业务有多套环境，优先在预发环境先跑一轮完整的迁移演练，再上生产。演练不仅能验证方案，还能顺便测出迁移耗时的真实值，方便后面规划窗口。
5.2 回滚预案别等出事了再想
在线迁移的优势之一是相对容易回滚。扩容场景下如果发现新节点有问题，最简单的回滚是把迁移过去的slot再搬回旧节点，也就是反向再执行一次reshard。由于数据都在，这个操作可以在分钟级到小时级完成。这就是为什么我建议迁移过程中保留源节点的配置和数据，不要急着删旧节点、清旧数据。
如果你做的是缩容，回滚就麻烦一些。退出集群的节点如果已经FORGET并从物理上关闭，数据还在，但重新加入集群需要重建复制关系，通常只能作为新节点重新来。所以缩容前我强烈建议备份。
离线迁移场景的回滚更加依赖备份。导入目标集群后，保留源集群的完整状态至少一周，确认目标集群稳定后再清理，不要迁移完当天就把源集群拆了。
5.3 几条经验，踩过坑才换得回来
最后分享几条个人经验，不涉及华丽的架构理论，都是日常操作中沉淀下来的习惯。
第一，迁移前给每个节点ID、slot分布、dbsize、内存水位留一份快照。等下线和上报问题时，这份快照能帮你快速判断“迁移到底动了哪些东西、有没有意外覆盖”。
第二，迁移过程中不要随便在源节点上执行FLUSHALL或FLUSHDB。听着像废话，但真有同事在调试脚本时手滑，清掉了还没迁完的key。如果你必须清理节点，一定先确认目标集群数据完整。
第三，控制迁移节奏而不是追求一把梭。一次迁几千个slot和分几次迁，后者对业务影响更小，诊断问题也更容易。尤其是首次在一个不熟悉的集群上做迁移，节奏要慢，观察窗口要长。
第四，不要光盯着Redis自身的监控。迁移期间的客户端ERROR、超时率、内网流量、源和目标节点的基础负载指标，都要同屏看。数据迁移是Redis的事，但受影响的是整个业务链路。
Redis Cluster数据迁移这件事，说到底是“slot所有权转移+key搬运”的组合拳。工具已经帮你封装好了大部分细节，但真正决定成败的，是你对流程的理解、对异常的处理，以及那些写不进文档的现场经验。希望这篇内容能帮你少踩几个坑，真到要动手的时候，心里有底。
