假设我们的应用现在使用了具有两个分片的数据集群，通过关键字哈希的方式进行路由，如下图所示。
因为两个分片已经不能满足容量的需求，所以现在需要扩容到4个分片，达到原来两倍的总大小，因此我们需要迁移。
迁移的具体过程如下。
1. 双写
按照新规则和旧规则同时往新新旧数据系统中写数据，如下图所示。
这里，我们仍然按照旧的规则，也就是关键字哈希除以2取余来路由分片，同时按照新的规则，也就是关键字哈希除以4取余来路由到新的4个分片上，来完成数据的双写。
2. 迁移历史数据
把旧缓存集群中的历史数据读取出来，按照新的规则写到新的数据集群中，如下图所示。
在这个过程中，我们需要迁移历史数据，在迁移的过程中可能需要迁移工具，这也需要一部分开发工作量。在迁移后，我们还需要对迁移的数据进行验证，表明我们的数据迁移成功。
3. 切读
把应用层所有的读操作路由到新的数据集群上，如下图所示。
image.png
在这一步骤里，把应用中读取的操作的数据源转换成新的数据集群，这是应用的读写操作已经完全发生在新的数据库集群上了。这一步一般不需要上线代码，我们会在一开始上双写时就实现开关逻辑，这里只需要将读的开关切换到新的集群即可。
4. 下线双写
在这一步，我们把写入旧的集群的逻辑下线，，如下图所示。
这一步通常是在双写和切读后验证没有任何问题，并保证数据一致性的情况下，才把这部分代码下线。同时可以把旧的分片下线，如果是扩容的场景，并且重用了旧的分片1和分片2，则还可以清理分片1和分片2中的冗余数据。
可以用“软着陆”来形容双写迁移方案，这和新领导上任后，一般先招心腹，慢慢的替代老下属的职责，慢慢淘汰老下属，慢慢实现软着陆如出一辙。
更多的关于“通用架构师应该如何把控迁移技术方案”的内容，请参加艳鹏在gitchat上的唠嗑节目。
