在我的《高并发系统设计目标之可扩展性》博文中提到，随着业务的发展，我们会沿着AKF的Y轴进行微服务化的改造。但是沿着Y轴的重构过程中往往涉及到分库分表。那么这时就需要进行数据库的迁移了。沿着AKF的Z轴也类似，那么迁移有什么原则呢？
数据迁移原则
1、迁移的过程应该是在线的，也就是线上的服务应该能够正常的提供服务；
2、迁移完成后，数据应该是完整的，也就是迁移后新库与旧库的数据应该要保持一致；
3、迁移过程中如果出现问题，应该是可以回滚。
数据迁移之双写方案
其流程如下图：
1、设置新库同步旧库（快照+binlog方式），如果新库的库表结构有修改，则需要引入第三方软件如canal订阅旧库的binlog，然后解析出binlog根据修改规则插入数据到新库；
2、同步完成后，校验数据是否一致，如果不一致则停止迁移，一致保存快照；
3、打开双写功能，同时关闭新旧库的同步。如果对性能比较敏感，新库可以异步写的方式，但是如果新库写失败，应该记录下错误的日志，以供分析，然后停止迁移，问题解决后根据之前保存的快照信息，从第1点重新开始binlog同步；
4、双写工作一阵子后，校验数据的一致性（可以边写边校验，需要写好校验的工具），一致，则保存快照，否则停止迁移，问题解决后根据之前保存的快照信息同步binlog，同步完成后重新从第3点开始；
5、缓慢灰度读流量到新库，如果新库在云上，为了避免云上服务器与自建机房的延迟，应该是云上的应用访问云上新库，自建机房的应用访问自建机房的读库；如果灰度过程一直都没有问题，则继续；否则解决问题后重新开始灰度；
6、灰度完成后，关闭双写，改成只写新库。
这个过程中只有第6步不能灰度，但是经过前面几步的校验，最后一步出现问题的概率还是很小的。但是新库如果部署在云上，且库表结构没有变化，由于云上机房与自建机房通信的延迟比较大，双写方案可能就不怎么适合了，此时可以用级联同步的方案。
数据迁移之级联同步方案
级联同步方案的流程图如下：
1、把云上新库作为自建机房的备库，同步自建机房的数据；同时在自建机房新建备库同步云上新库；
2、数据同步完成后，将读流量缓慢灰度到云上新库（为了降低延迟，需要注意的是云上新库的读请求应该是云上的应用发起的，自建机房也类似），如果一切顺利则继续，否则停止灰度；
3、将写流量切换到云上新库，由于切写的时候，会停服，故要在业务低峰时候做；如果切换写流量后，出现问题，可以回滚到自建机房的备库，这也是为什么要在自建机房建立备库同步云上新库的原因；
4、关闭云上新库与自建机房旧库的同步逻辑，自此整个迁移过程就完成了。
