大厂篇(1)：如何优雅的不停服的迁移数据库（千字肝文，冀看到最后）？

计算机哲学思想：在进行数据迁移的时候，要科学合理的分批次进行（要处理好全量和增量的关系，平衡数据安全和效率的问题），制定相应的失败回滚策略，并且为了保证数据不丢失，需要有验证和补偿机制作为兜底，才能保证整个过程的有序开展和进行。

应用场景

• 面对海量数据，需要将单例的数据库分库分表成多个数据库多个数据表；
• 自建的数据库需要迁移到云服务厂商提供的数据库
• 大数据方面的需求，比如：之前的MySQL数据库性能不够用，需要迁移到在线实时统计的存储系统中，例如：Hbase

直接上干货，整体步骤分两个阶段如下（以订单服务MySQL为例）：

第一阶段：参考redis的全量复制思想，复制之前数据库大部分数据

1.上线同步程序：主要负责新老数据库之间的实时同步，分批同步，避免对线上数据库（新库）造成压力 ，验证数据一致，再进行下一步，否则（回滚策略是），修复同步程序，使其新旧库的数据一致

2.对订单服务进行改造后然后发版上线新功能，使其支持双写开关功能；具体如下：

开关种类：热切换写开关，热切读开关

写开关有3个状态值：1只写旧库，2只写新库，3双写（新库旧库一块写）

读开关：1只读旧库 2只读新库

在订单服务的DAO进行改造，业务的核心逻辑不变，开关配置到配置文件，可以动态修改切换

观察一段时间，验证新的订单服务ok，再进行下一步，否则回滚到上个版本的代码即可

第二阶段：参考redis的增量复制思想，因为无法保证下线同步程序和开启双写开关的无缝衔接

3.下线同步程序，开启热切换写开关，具体如下：

先开启写开关3双写，与此同时，上线比对补偿程序进行数据对比和补偿，比对就是按着主键分条比对数据，不一致的覆盖写，以旧数据为准覆盖写新数据库，否则，如果数据还是不一致，修复比对补偿逻辑程序，热切换写开关切回到热切换写开关： 1只写旧库

4.运行一段时间，磨合稳定好，将热切换读开关开启，慢慢的将流量切到新数据进行读请求，期间有问题的话，直接切换热切换读开关： 1只读旧库

5.再运行一段时间，系统没问题后，下线比对补偿程序，同时设置热切换写开关为：2只写新库

6.运行一段时间没问题后，旧库下线，带双写功能的订单服务下线

整个过程，为了保证数据的安全，需要有回滚策略

这一节内容多而且杂乱，希望读者多读几遍，细心揣摩

细节：

• 细心的同学发现整个过程，只有步骤5是不可逆的，没有提供回滚策略，因为这步就是停掉旧的的数据库，对于在用的新的数据库并没有什么改变，实际上出问题的可能性就非常小了
• 步骤3开启双写开关，是以旧的数据库写入成功失败为准的，这么做的原因是不能让新库影响现有业务的可用性和数据准确性 旧数据库先写，再写新的数据库 情况1：旧数据库写失败，就代表写失败了， 情况2：旧数据库写成功，新数据库写失败，也代表写失败了 这个时候 比对补偿程序就扮演的重要角色

总结：

设计在线切换数据的方案时候，首先要保证数据的安全性，确保每个步骤失败，要能回滚到上个安全状态，为了不能丢数据，可以分批分步的进行迁移，并且每个阶段要有验证和补偿机制：主要实时同步程序和比对补偿程序实现

我正在参与2023腾讯技术创作特训营第二期有奖征文，瓜分万元奖池和键盘手表