Redis部分数据迁移实战，数据迁移不断服、零丢失，高效安全完成Redis实例间数据平滑迁移

实现Redis部分数据迁移的关键，是使用RESTORE-ASKING命令结合在线数据导出与写入，确保在迁移过程中应用不断服且数据不丢失。

为什么需要部分迁移

有时候，我们并不是要把整个Redis实例的数据都搬走。比如，某个业务的数据增长太快，占用了太多内存，影响到其他业务；或者想把一些不常访问的“冷数据”移到更便宜的存储上，以节省成本。这时候，全部迁移就像为了整理一个抽屉而把整个柜子都搬走，既没必要又麻烦。我们需要的是只把特定的一部分数据移走，同时保证线上的服务还能正常访问，不能停机，数据也不能少。

迁移前的准备工作

在动手之前，先要做好计划。首先，明确要迁移哪些数据。通常可以按“键”的名字来区分，比如所有以“user:session:”开头的键，代表用户会话数据。确定好源Redis和目标Redis的地址、密码。然后，在目标Redis上准备好空间，确保有足够的内存来存放新数据。最重要的一步是告诉你的应用程序，在迁移期间，它需要配合一点小改动来保证数据一致性，这个我们后面会详细说。

核心迁移步骤

整个迁移过程可以分成几个清晰的步骤来做。

第一步，从源Redis导出数据。我们不使用会阻塞服务的SAVE命令，而是用SCAN命令分批扫描出所有符合条件（比如键名前缀匹配）的键。对每一个键，使用DUMP命令获取它的数据快照和过期时间。这个操作是逐个进行的，不会影响其他键的访问。

第二步，向目标Redis写入数据。对于上一步导出的每一个数据快照，使用RESTORE命令将其恢复到目标Redis中，并指定原来的过期时间。这样，数据就和原来一模一样了。

第三步，也是保证“不断服”和“零丢失”最关键的一步——切换与同步。当目标Redis的数据基本追平后（可以通过脚本对比关键数据量），我们需要让应用程序开始向新的目标Redis写入新数据。这里，可以使用RESTORE-ASKING命令的思路来设计。简单来说，在应用程序中设置一个开关。迁移开始时，应用程序对所有写请求（增、删、改），同时向源Redis和目标Redis各执行一次（双写）。对于读请求，仍然只从源Redis读。当确认一段时间内双写稳定、数据一致后，将读请求也切换到目标Redis。最后，经过验证无误，关闭向源Redis的写入，并下线源Redis中的旧数据。这个过程确保了即使迁移中发生问题，源Redis的数据也是完整的，可以立刻切回去。

迁移过程中的注意事项

迁移最好选在系统访问量小的时候进行，比如深夜。要密切关注源Redis和目标Redis的CPU、内存使用情况，避免迁移工具本身把资源耗尽。迁移脚本一定要有重试机制，网络偶尔抖动导致单次操作失败是正常的，重试几次就能成功。最关键的是，做好备份！在开始迁移前，务必对源Redis进行一次完整的备份，这是最后的保险。

验证迁移结果

迁移完成后，不能直接说好了。需要验证。随机抽查一批迁移过去的键，在源和目标两边分别读取，对比值是否完全一致。检查带有过期时间的键，在目标端是否正常工作。让应用程序运行一段时间，观察是否有报错或数据不一致的异常。只有这些都通过了，迁移才算真正成功。

FAQ

问：迁移过程中，如果应用程序写了数据，但目标Redis写入失败了怎么办？
答：这正是“双写”机制要解决的。在切换阶段，应用程序会同时向两个Redis写。如果向目标Redis写入失败，但向源Redis写入成功了，数据并没有丢失。我们的迁移脚本或监控程序会发现这种不一致（可以通过定期比较关键键的值），然后进行补偿，将源Redis中新增的或修改过的数据再次同步到目标Redis，直到两者一致。

问：如何确定要迁移的“部分数据”？会不会误迁？
答：确定数据范围需要谨慎。通常基于清晰的业务规则，比如键的命名规范（前缀）。在正式操作前，应该在一个隔离的测试环境，用完整的生产数据备份进行一次全流程演练。先用SCAN命令预览所有匹配的键，人工审核列表是否正确。正式迁移时，脚本也可以先进入“试运行”模式，只打印出要操作的键而不实际执行，再次确认。

问：这个方法和直接用Redis的主从复制有什么区别？
答：主从复制是把整个实例的数据全部、实时地复制到另一个实例。它适合做全量备份、读写分离或故障转移，但无法选择只复制一部分数据。我们的方法更灵活，是“精挑细选”地迁移，适用于数据分片、成本优化等只需要移动部分数据的场景。

引用来源

本文所述方法基于Redis官方文档中DUMP、RESTORE、SCAN等命令的说明，并结合了在大型互联网应用中平滑迁移缓存数据的常见工程实践。核心的“双写”及切换思路，参考了分布式系统数据迁移的通用模式，以确保服务连续性。