本文节选自即将出版的《可伸缩服务架构：框架与中间件》一书，作者：李艳鹏、杨彪、李海亮、贾博岩、刘淏。
处理分布式缓存迁移是比较困难的，通常我们将其分为平滑迁移和停机迁移。这里讲解通用的迁移方案，扩容实际上是迁移的一种特殊案例，我们在下面学习的方案全部适用。我们会在讲解该方案的过程中，以扩容为例来说明相应的步骤和实现细节。
１．平滑迁移
平滑迁移适合对可用性要求较高的场景，例如，线上的交易服务对缓存依赖较大，不能忍受停机带来的业务损失，也没有交易的低峰期，我们对此只能采用平滑迁移的方式。
平滑迁移使用的是双写方案，方案分成4个步骤：双写、迁移历史数据、切读、下双写。
这种方式还有一个变种，就是不需要迁移老数据，在第1步中双写后，在一定的时间里通过新规则对新缓存进行写入，新缓存已经有了足够的数据，这样我们就不用再迁移旧数据，直接进入第3步即可。
首先，假设我们的应用现在使用了具有两个分片的缓存集群，通过关键字哈希的方式进行路由，如图4-19所示。
因为两个分片已经不能满足缓存容量的需求，所以现在需要扩容到4个分片，达到原来两倍的缓存总大小，因此我们需要迁移。
迁移的具体过程如下。
第1步，双写。按照新规则和旧规则同时往新缓存和旧缓存中写数据，如图4-20所示。
这里，我们仍然按照旧的规则，也就是关键字哈希除以2取余来路由分片，同时按照新的规则，也就是关键字哈希除以4取余来路由到新的4个分片上，来完成数据的双写。
这个步骤有优化的空间，因为是在成倍扩容的场景下，所以我们不需要准备4个全新的分片。新规则中前两个分片的数据，其实是旧规则中两个分片数据的子集，并且规则一致，所以我们可以重用前两个分片，也就是说一共需要两个新的分片，用来处理关键字哈希取余后为2和3的情况；使用旧的缓存分片来处理关键字哈希取余后0和1的情况即可。如图4-21所示。
第2步，迁移历史数据。把旧缓存集群中的历史数据读取出来，按照新的规则写到新的缓存集群中，如图4-22所示。
在这个过程中，我们需要迁移历史数据，在迁移的过程中可能需要迁移工具，这也需要一部分开发工作量。在迁移后，我们还需要对迁移的数据进行验证，表明我们的数据迁移成功。
在某些应用场景下，缓存数据并不是应用强依赖的，在缓存里获取不到数据，可以回源到数据库获取，因此在这种场景下通过容量评估，数据库可以承受回源导致的压力增加，就可以避免迁移旧数据。在另一种场景下，缓存数据一般是具有时效性的，应用在双写期间不断向新的集群中写入新数据，历史数据会逐渐过时，并被从旧的集群中删除，在一定的时间流逝后，在新的集群中自然就有了最新的数据，也就不再需要迁移历史数据了，但是这需要进行评估和验证。
第3步，切读。把应用层所有的读操作路由到新的缓存集群上，如图4-23所示。
这一步把应用中读取的操作的缓存数据源转换成新的缓存集群，这时应用的读写操作已经完全发生在新的数据库集群上了。这一步一般不需要上线代码，我们会在一开始上双写时就实现开关逻辑，这里只需要将读的开关切换到新的集群即可。
第4步，下线双写。把写入旧的集群的逻辑下线，如图4-24所示。
这一步通常是在双写和切读后验证没有任何问题，并保证数据一致性的情况下，才把这部分代码下线的。同时可以把旧的分片下线，如果是扩容的场景，并且重用了旧的分片1和分片2，则还可以清理分片1和分片2中的冗余数据。
２．停机迁移
停机迁移的方法比较简单，通常分为停止应用、迁移历史数据、更改应用的数据源、启动应用这4个步骤，如图4-25所示。
具体的迁移步骤如下。
（1）停机应用，先将应用停止服务。
（2）迁移历史数据，按照新的规则把历史数据迁移到新的缓存集群中。
（3）更改应用的数据源配置，指向新的缓存集群。
（4）重新启动应用。
这种方式的好处是实现比较简单、高效，能够有效避免数据的不一致，但是需要由业务方评估影响，一般在晚上交易量比较小或者非核心服务的场景下比较适用。
