一比一

一比一的迁移，没有多大意义。

n : m

这种一般存在于数据扩容过程中。 N个Redis节点无法满足容量的需求，需要扩容。注意是容量需求。当然也有可能是数据带宽或者读写性能的考虑。比如这个Redis集群存在热点key，这些热点key被路由到了同一台机器，这种是不是把这些Redis迁移到其他机器上就行了。就是上面的一比一的迁移。直接使用Redis的slaveof命令，然后进行域名切换就可以了。

假设还是处理的容量问题。

下面的这些介绍需要Redis的客户端。

最简单方式

搭建新的Redis集群，通过主从同步程序，进行全量的RDB同步，之后进行增量同步。同步校验程序，检测新旧集群是否达到某种程度的数据一致，比如新旧集群的offset在一定范围内，则通过配置中心系统，切换到新的集群上。

存在的问题：

• 因为offset是无法永远满足的，总是做不到完全没有offset的偏差，这样就会存在丢数据的情况。你可能会说切换过去之后，同步程序不停不就完了？是的，如果不停的话，虽然数据没有丢，但是可能存在数据被覆盖的情况。比如已经对新的集群进行了写命令，set key newValue，之后进行了增量同步，set key oldValue。
• 而且，通过配置中心这种切换的方式，可能存在有些客户端已经切换到了读写新，但是其他客户端还在读写旧的情况，这样那些还没感知到切换动作的客户端读到的是旧数据。

停写

其实上面的问题，主要是存在并发。那我们能不能将旧的集群停写，然后听同步程序，校验数据完全一致后，通过配置中心切换到新的集群，等所有客户端都切换完了后，再进行写操作。完美了。

存在的问题：

• 都停写了，对业务有损了。

不停写行么

• 先进行全量同步、增量同步
• 持续的增量同步着
• 切换到双写模式，此时还是读旧数据
• 数据校验，当数据一致时，关闭增量同步程序。
• 切换读新数据，如果切换后有问题，还可以回滚到读旧。
• 关闭写旧，完成同步

存在的问题：

• 由于存在增量同步和双写，那么如果有incr命令的话，新的集群数据会偏大。这种可以在数据校验时发现，但是总是无法穷尽。
• 双写的数据一致性问题，即怎么保证双写成功？