高并发系统设计：数据的迁移应该如何做

由于MySQL不想MongoDB那样支持Auto Sharding(自动分片)，所以无论是将MySQL单库拆分成多个数据库，还是由于数据存储的瓶颈，不得不将多个数据库拆分成更多的数据库时，都需要考虑如何进行数据的迁移。

其实，在实际工作中，不只是对数据库拆分时会做数据迁移，很多场景都需要你给出数据迁移的方案，比如说某一天，你的老板想要将应用从自建机房迁移到云上，那么你就要考虑将所有自建机房中的数据，包括 MySQL，Redis，消息队列等组件中的数据，全部迁移到云上，这无论对哪种规模的公司来说都是一项浩瀚的工程，所以你需要在迁移之前，准备完善的迁移方案。

如何平滑的迁移数据库中的数据

你可能会认为：数据迁移无非是将数据从一个数据库拷贝到另一个数据库，可以通过MySQL主从同步的方式做到准实时的数据拷贝；也可以通过mysqldump工具将源库的数据导出，在导入到新库，这有什么复杂的呢？

其实，这两种方式都只能支持单库到单库的迁移，无法支持单库到多库多表的场景。而且即使是单库到单库的迁移，迁移过程也需要满足以下一个目标：

• 迁移应该是在线的迁移，也就是在迁移的同时还会有数据的写入
• 数据应该保持完整性，也就是说迁移之后需要保证新的库和旧的库的数据是一致的
• 迁移的过程中需要做到可以回滚，这样一旦迁移的过程中出现问题，可以立即回滚到源库，不会对系统的可用性造成影响。

如果你使用binlog同步的方式，在同步完成之后再修改代码，将主库修改为新的数据库，这样就不满足可回滚的要求，一旦迁移后发现问题，由于已经有增量的数据写入了新库而没有写入旧库，不可能再将数据库改回旧库。

一般来说，我们有两种方案可以做数据库的迁移。

“双写”方案

步骤如下：

• 将新的库配置为源库的从库，用来同步数据；如果需要将数据同步为多库多表，那么可以使用一些第三方工具获取binlog的增量日志（比如canal），在获取增量日志之后就可以按照分库分表的逻辑写入到新的库表中了
• 同时，我们需要改造业务代码，在数据写入的时候，不仅要写入旧库，也要写入新库。当然，基于性能考虑，我们可以异步的写入新库，只要保证旧库写入成功即可。但是，一定要将写入新库失败的数据记录在单独的日志中，这样方便后继对这些数据补写，保证旧库和新库的数据一致性
• 然后，我们就可以开始校验数据了。由于数据库中数据量很大，做全量的数据校验不太现实。可以抽取部分数据，具体数据量依据总体数据量而定，只要保证这些数据是一致的就可以。
• 如果一切顺利，我们就可以将读流量切换到新库了。由于担心一次切换全量读流量可能会对系统造成未知影响，所以这里最好使用灰度的方式切换。比如开始切换10%的流量，如果没有问题再切换到 50% 的流量，最后再切换到 100%。
• 由于有双写的存在，所以在切换的过程中如果出现任何问题，都可以将读写流量随时切换到旧库中，保证系统的性能
• 在观察了几天发现数据的迁移没有问题之后，就可以将数据库的双写改造成只写新库，数据的迁移也就完成了。
  

其中，最容易出问题的步骤就是数据校验的工作，建议在未开始迁移数据之前先写好数据校验的工具或者脚本，在测试环境上测试充分之后，再开始正式的数据迁移。

如果是将数据从自建机房迁移到云上，你也可以使用这个方案，只是你需要考虑的一个重要的因素是：

• 自建机房到云上的专线的带宽和延迟，你需要尽量减少跨专线的读操作
• 所以在切换读流量的时候，你需要保证自建机房的应用服务器读取本机房的数据库，云上的应用服务器读取云上的数据库。
• 这样在完成迁移之前，只要将自建机房的应用服务器停掉，并且将写入流量都切到新库就可以了

这种方案是一种比较通用的方案，无论是迁移 MySQL 中的数据，还是迁移 Redis 中的数据，甚至迁移消息队列都可以使用这种方式，在实际的工作中可以直接拿来使用。

这种方式的好处是：迁移的过程可以随时回滚，将迁移的风险降到了最低。劣势是：时间周期比较长，应用有改造的成本。

级联同步方案

这种方案也比较简单，比较适合数据从自建机房向云上迁移的场景。因为迁移上云，最担心云上的环境和自建机房的环境不一致，会导致数据库在云上运行时，因为参数配置或者硬件环境不同出现问题。

所以，我们会在自建机房准备一个备库，在云上环境准备一个新库，通过级联同步的方式在自建机房留下一个可回滚的数据库，具体的步骤如下：

• 先将新库配置为旧库的从库，用作数据同步
• 再将一个备库配置为新库的同步，用作数据的备份
• 等到三个库的写入一致后，将数据库的读流量切换到新库
• 然后暂停应用的写入，将业务的写入流量切换到新库（由于这里需要暂停应用的写入，所以需要安排在业务的低峰期）。

这种方案的回滚方案也比较简单，可以先将读流量切换到备库，再暂停应用的写入，将写流量切换到备库，这样所有的流量都切换到了备库，也就是又回到了自建机房的环境，就可以认为已经回滚了。

上面的级联迁移方案可以应用在，将 MySQL 从自建机房迁移到云上的场景，也可以应用在将 Redis 从自建机房迁移到云上的场景，如果你有类似的需求可以直接拿来应用。

这种方案优势是简单易实施，在业务上基本没有改造的成本；缺点是在切写的时候需要短暂的停止写入，对于业务来说是有损的，不过如果在业务低峰期来执行切写，可以将对业务的影响降至最低。

数据迁移时如何预热缓存

另外，在从自建机房向云上迁移数据时，我们也需要考虑缓存的迁移方案是怎么样的。那么你可能会说：缓存本来就是作为一个中间的存储而存在的，那么只需要在云上部署一个空的缓存节点，云上的缓存也会穿透到云上的数据库，然后回种缓存，对于业务是没有影响的。

是这样。但是还需要考虑缓存的命中率：如果你部署一个空的缓存，那么所有的请求就都会穿透到数据库，数据库可能会因为承受不了这么大的压力而宕机，这样你的服务就会不可用了。所以，缓存迁移的重点是保持缓存的预热

Redis 的数据迁移可以使用双写的方案或者级联同步的方案