为什么迁移方案不能随便选
Redis数据迁移不是简单地复制一个文件就完事。不同方案对停机时间的要求、数据一致性的保障程度、对源实例性能的影响都差别很大。如果源实例还在承载线上业务，直接拷贝RDB文件很可能拿到的是不一致的数据快照；而如果在业务高峰期执行BGSAVE，fork子进程带来的延迟毛刺甚至可能引发线上告警。
选择方案前，先回答三个问题：源实例是否允许停写？能接受多长的数据延迟窗口？数据量有多大？数据量在1GB以内且允许短暂停写，最简单的方案就够了；数据量达到几十GB，或者业务不允许明显停机，就需要考虑增量同步类方案。下面这张示意图可以帮助理解各方案的整体思路。
另外还要确认两边的版本兼容性。Redis 4.0引入了混合持久化，新版RDB文件里混入了AOF格式的增量部分，低版本实例无法加载高版本生成的RDB文件。一般原则是新实例版本等于或高于源实例，跨大版本迁移前务必在测试环境验证一遍。
方案一：RDB快照拷贝，适合允许停写的场景
这是最经典的方式：触发一次快照，把dump.rdb文件复制到目标实例所在机器，配置目标实例加载后重启。整个过程可以分为停写、落盘、传输、加载、切换五个步骤。关键是停写这一步，一定要确保业务不再往源实例写入，否则落盘后新写入的数据会丢失。
具体操作流程如下，先在源实例手动触发持久化：
# 连接源实例，触发后台保存 redis-cli -h 192.168.0.10 -p 6379 bgsave # 确认后台保存完成 redis-cli -h 192.168.0.10 -p 6379 info persistence | grep rdb_bgsave_in_progress # 拷贝RDB文件到目标机器（假设目标实例已停止） scp /var/lib/redis/dump.rdb root@192.168.0.20:/var/lib/redis/dump.rdb # 修改文件属主并启动目标实例 chown redis:redis /var/lib/redis/dump.rdb systemctl start redis
目标实例的配置文件中要确认dbfilename和dir两项与文件实际位置一致，同时关掉AOF或者先把AOF相关配置关掉。因为当RDB和AOF同时开启时，Redis启动优先加载AOF，如果AOF文件是空的，你会以为数据丢了，其实是没加载RDB。这是新手最容易踩的坑之一。
这种方案的优势是简单可靠、迁移完成后数据是完全一致的快照。缺点也很明显：必须有一个停写窗口，数据量越大，传输和加载时间越长。10GB的RDB文件在千兆内网传输加加载，通常需要几分钟的停机时间。如果业务能接受半夜低峰期停写几分钟，这是性价比最高的方案。
方案二：主从复制方式全量加增量同步
Redis自带的复制机制天然就是一套数据迁移工具。把目标实例配置为源实例的从节点，它会先做全量同步拉取RDB，之后通过复制积压缓冲区持续接收增量命令，数据延迟可以控制在毫秒级。追平之后，把业务切换到目标实例，再断开复制关系，让其升为主库即可。
操作步骤如下：
# 在目标实例上执行，将其变为源实例的从节点 redis-cli -h 192.168.0.20 -p 6380 replicaof 192.168.0.10 6379 # 观察同步状态，master_link_status应为up redis-cli -h 192.168.0.20 -p 6380 info replication # 业务切换后，断开复制，目标实例升级为主库 redis-cli -h 192.168.0.20 -p 6380 replicaof no one
这种方式对业务几乎零侵入，切换窗口可以压缩到秒级，是线上不停机迁移的首选。但有几个细节必须注意。第一，源实例的repl-backlog-size要调大一些，默认1MB的复制缓冲区在写入量大时容易溢出，导致从库反复全量同步，形成一个循环。第二，如果源实例是集群模式，直接用replicaof是行不通的，需要借助第三方工具。第三，迁移完成后别忘了检查目标实例是否残留了replicaof配置，否则重启后它会继续跟着旧主库走。
还有一点常被忽略：从库同步的是命令流，如果迁移期间业务对同一个key先删除再写入，这些操作会原样回放，最终状态是一致的，这一点不用担心。但如果迁移中途目标实例被误写入数据，复制同步并不会清理这些脏数据，切换前最好用dbsize对比一下两边key数量。
方案三：redis-shake工具，应对集群和跨版本迁移
当源和目标都是Cluster集群，或者需要跨云、跨机房迁移时，原生复制机制用起来就很别扭。阿里开源的redis-shake是这类场景下的利器，它支持standalone、cluster、sentinel三种架构之间的任意组合迁移，同时具备全量同步和增量同步能力，还支持过滤特定key和库。
以从单机A同步到集群B为例，配置文件核心部分如下：
# redis-shake配置示例 source.address = 192.168.0.10:6379 source.type = standalone target.address = 192.168.0.20:6380;192.168.0.21:6380;192.168.0.22:6380 target.type = cluster # 先全量后增量 sync = true
启动后它会先用scan遍历源实例做全量导入，再解析RDB和复制流做增量追平。日志中会输出同步进度，当增量延迟稳定在很低水平时，就可以安排业务切换了。相比前两种方案，redis-shake的优势在于对集群拓扑的兼容性和断点续传能力，缺点是多引入一个组件，需要自己监控它的运行状态。
实际项目中常见的组合打法是：数据量大且不停机，用redis-shake或主从复制做双写期同步，观察一到两天的延迟和一致性；确认稳定后，选择业务低峰把读流量先切到新实例，观察无异常再切写流量，最后保留源实例几天作为回滚兜底。切忌迁移完成立刻下线源实例，给自己留一条后路永远是运维的第一原则。
迁移后的验证与收尾工作
数据切过去不代表迁移结束，验证环节同样重要。可以用dbsize对比key总数，抽样检查大key和热点key的值是否一致，也可以用redis-rdb-cli之类的工具做全量diff。对于有TTL的key，要确认过期时间在迁移后被正确保留，某些迁移工具在传输过程中会重置TTL，导致本该过期的key在新实例上永久存活，慢慢把内存吃满。
监控也要同步跟上：新实例的内存碎片率、命中命中率、慢查询日志、连接数，切换后的头几天要重点观察。如果是从哨兵或集群架构迁出，还要清理DNS、配置中心、客户端连接串里的旧地址，避免有服务还在偷偷连老实例写数据，造成两边数据悄然分叉。把整个迁移过程文档化，记录每个步骤的时间和回滚点，下次再做迁移时就是现成的操作手册。