Redis存储迁移方案

搬运自本人知乎:https://zhuanlan.zhihu.com/p/42384904

摘要

现在互联网公司的体系架构中，redis存储是必不可少的。有很多公司在创业初期的时候，由于技术积累或研发成本等原因，选择使用云上的Redis存储作为NOSQL。通常云上的Redis都是分布式的Redis存储，具有高吞吐量、高可用、可水平伸缩等特性，这为研发人员提供了很大便利。随着公司规模的发展、技术的壁垒等因素，希望把在云上的Redis存储数据迁移到内部的机房等其他地方。市面上已经有了一些Redis迁移工具，但是这些工具的使用场景有限，有时并不满足迁移时的使用需求。这时就需要一个较为完善的Redis迁移工具来完成这件事情。

在这里，我们会介绍已经在生产环境验证多次的Redis迁移工具的设计，然后描述应用级透明、低开销、高可用、数据一致性这四个设计目标是如何实现的。之后会描述这个迁移工具的一些限制和弊端，还会介绍一些其他的迁移方法。最后会讨论一些可以优化的地方来提高整体效率和稳定性。

1 介绍

我们开发了一个Redis迁移工具来把在云上的Redis存储迁移到自建的Redis存储或Codis集群，我们把自建Redis存储或Codis集群这类存储称为目标存储。在很多情况下，使用云上的Redis存储的业务服务是不可以停机的。另外，可能由于网络异常、服务故障等不可预测的因素导致数据迁移过程会随时中断，所以数据迁移被中断不应该影响业务服务的正常使用。从这些条件中推倒出来了几个具体的设计目标：

• 应用级透明：当进行迁移时， 正在运行的服务不应该意识到迁移正在进行，这意味着开发人员不需要对代码做任何改动，业务服务也不需要停机。
• 低开销：这个迁移工具不应该明显地影响进行迁移的服务的性能。在迁移的时候，执行Redis命令请求所花费的时间不应该影响业务的可用性。
• 高可用：如果在数据迁移过程中发生了异常，那么不应该影响业务服务的可用性，只需要重新启动迁移过程就可以继续迁移。
• 迁移后的数据一致：在迁移的过程中， 云上的Redis存储的状态在随时发生着变化。当迁移的过程结束时， 我们需要保证目标存储的最终状态要与在云上的Redis存储的状态保持一致。

我们的Redis迁移工具的一个额外的设计目标是高吞吐量，因为不同的服务使用Redis存储的读写模式不同，某些服务大多数Redis请求是读请求，写请求只占很小的一部分。而有些服务的请求大部分是写请求。为了实现上述四个设计目标，写请求的吞吐量成为了这个迁移工具的性能瓶颈。由于写请求吞吐量的限制，所以我们无法在保证业务服务高可用的前提下进行迁移超出写请求吞吐量限制的业务服务。

当业务服务进行迁移时，虽然应用级透明这个设计目标保证了开发人员不需改动代码，但是开发或运维人员需要多次对服务进行重新配置来更改Redis存储的服务器的地址。