最近有个老朋友跟我聊起他们公司的技术选型，说Redis数据库迁移这事儿快把团队逼疯了。数据量撑到几 GB 时还能勉强用导出导入糊弄过去，但一上到几百 GB 甚至上 TB，那叫一个头大。我听完笑了笑，这事我太熟了——以前在创业公司干过，半夜爬起来搞Redis迁移，结果数据丢了小半，老板第二天开会脸都是绿的。其实Redis迁移，说白了就是个“搬箱子”的活，箱子有大有小，搬法得跟着变。很多人一上来就想找个万能方案，结果往往是捡了芝麻丢了西瓜。
先说说最常见的“导出导入法”。这招适合数据量不大、业务能停几分钟的场景。操作不复杂：用 SAVE 或 BGSAVE 命令生成 RDB 快照文件，然后拷到新机器上，再启动新 Redis 实例加载。听着挺顺溜，是吧？但坑就藏在细节里。比如 RDB 文件格式跟 Redis 版本有关，老版本导出的文件，新版可能读不了。更糟的是，如果忘了关闭写操作，旧库还在跑，新库一启动，数据就乱套了。我见过一个哥们，导完数据没检查，结果新库里少了几万条用户 Session，线上直接炸了。所以这方法虽然简单，但必须提前规划好停服窗口，还要做校验：比如对比 key 总数、随机抽查几个 value。别图省事，数据这东西，丢不起。
那如果业务不能停呢？就得请出“主从复制”。这方案就像给 Redis 找个“分身”，先让新实例当从库，从旧库全量同步数据，然后再切主。好处是迁移过程几乎不影响线上，读写照常。但麻烦也不少。全量同步时，旧库会把内存里的数据全部吐出来，瞬间就会占用几 GB 甚至几十 GB 的流量。我有个客户，公司带宽只有 100 M，结果同步时把办公网都卡崩了。还有内存问题：新实例在同步期间需要同时保存快照和增量修改，两份数据加在一起可能直接 OOM。于是使用前必须先算好：旧库数据有多大？带宽够不够？新机器内存是否至少是数据量的两倍？别到时候搬着搬着，两边都挂了。
还有一种办法是“哨兵模式”配合迁移。如果你的 Redis 已经搭了哨兵集群，迁移就多了一层保障。思路是：先在新机房架一组 Redis 实例，然后把它们加到哨兵的监控列表里，再逐台切换主从关系。好处是哨兵会自动处理故障转移，迁移过程中如果旧主挂了，能自动切到新主。但坑在于哨兵的配置很容易出错。比如哨兵对主的“主观下线”判断时间默认是 30 秒，如果网络抖动一下，哨兵就会误以为主挂了，直接触发切换，导致旧主仍在跑，数据出现分裂。我见过一个案例，迁移时忘了调这个参数，结果线上出现了两个主库，两边数据各写各的，花了两天手工合并。所以玩哨兵迁移，必须先在小环境里跑几遍流程，彻底弄清每个参数的含义。
说到这，有人会问：有没有更“无感”的方案？有，用 Redis Cluster。Cluster 自带分片和自动故障转移，迁移数据时可以动态调整槽位分配。具体操作是：加新节点、迁移槽位、下线旧节点。听起来高大上，但实际操作时，槽位迁移的粒度是按“槽”来的，一个槽里可能有几百万个 key。如果网络不好或某个 key 太大，一个槽可能要迁半小时。更崩溃的是，迁移过程中如果某个 key 被客户端访问，还得处理重定向。我遇到过最惨的情况：一次电商大促前做 Cluster 扩容，结果槽位迁移时，一个大 key 拖慢了整个集群，商品详情页响应超时，用户直接骂娘。所以 Cluster 迁移适合数据分布均匀的场景；如果你的数据存在热点 key，必须先拆分，否则迁移就是给自己挖坑。
还有些人喜欢用第三方工具，比如 redis‑migrate‑tool、RedisShake。这些工具号称能“在线迁移、断点续传”，听起来很香。但实话实说，用工具像开盲盒——运气好一次过，运气差各种奇葩 bug。比如 RedisShake 通过解析 Redis 的 AOF 文件来同步数据，如果旧库的 AOF 文件太大或格式不规范，工具会直接报错退出。我有个同事，用 RedisShake 迁移一个 50 GB 的实例，跑了三天三夜，结果一步报了“内存不足”，查了半天才发现是工具本身的内存泄漏。所以使用工具前，一定要先在小数据集上测试，观察日志是否有异常。千万别直接上生产，否则数据丢了，工具可不会帮你背锅。
说到数据安全，迁移完后最关键的步骤是“校验”。很多人觉得数据过去了就完事，结果等出问题时旧库已经清掉，想恢复来不及。校验分两步：第一步是数量校验，用 DBSIZE 或 INFO 统计 key 总数，两边对比；第二步是内容校验，随机抽取一批 key，用 DUMP 命令导出 value，再对比 CRC 校验码。如果发现不一致，就得赶紧回滚或增量同步。我见过一个团队，迁移完没校验，过了两周才发现某业务线的缓存数据全乱了，加班三天才修好。所以校验这事，宁可多花一小时，也别省一分钟。
说点务实的建议。Redis 迁移没有银弹。小数据量用导出导入，中等数据量用主从复制，大数据量用 Cluster，敏感环境可以考虑第三方工具但一定要测试。但不管用哪种方案，都别忽视“人”的因素：团队里要有懂 Redis 源码级别原理的成员，了解 RDB 与 AOF 的区别，懂复制偏移量的含义。为什么？因为迁移出问题时，能快速定位的不是百度，而是你对 Redis 内部机制的熟悉程度。比如全量同步卡住了，你得能判断是网络问题还是内存问题；增量同步延迟了，你得知道是写压力大还是复制积压缓冲区太小。这些东西，工具不会告诉你，文档也写不清，只有靠自己踩坑、总结。
所以我的建议是：先别急着开干，花一天时间画个迁移流程图，标出每个环节的风险点和回滚方案。然后建个群，把运维、DBA、业务方都拉进来，明确各自职责。迁移当天，准备好监控和报警，时刻盯着内存、带宽、QPS 等指标。只要数据没有通过校验，就别宣布迁移成功。记住，Redis 迁移不是单纯的技术活，而是管理活——管理好风险，管理好人，管理好预期。只要做到这三点，不管多少 GB 的数据，都能稳稳搬过去。
