当我们在初创公司或者公司的一个新的业务线的初期，通常来说不会采用分库分表的，但是随着业务发展，就会有需要分库分表的情况产生。那么针对于之前单库表中的数据我们如何迁移到新的分库分表上呢？我们最先想到的方案应该就是发公告停机停服的数据迁移。
停机停服数据迁移
比如我们已经准备好某一天要进行数据迁移了，那么我会们在当天发布公告，比如通告一下用户，凌晨12点到早上6点系统升级，服务暂不可用。那么到了凌晨12点，所有服务停机，并观察数据库中是否还有数据写入变更删除等操作，如果发现现在数据库中的数据已经静止了，那么一部分人负责升级代码，一部分人负责变更新的数据源配置，一部分人利用事先写好的数据迁移脚本，对旧库中的数据进行读取并新增到新的库表中。由于这段时间是停机停服的，所以不会有新的业务数据产生，那么当数据迁移完毕后。启动服务并观察线上环境是否有异常，进行一遍主要流程的测试工作，如果功能无异常，则迁移工作完毕。当然，这种方案很简单，对于一般系统来说，都是可以接收的，毕竟凌晨12点到6点这段时间，用户使用场景很低。但是，依然无法避免的就是，对用户的感受是不好的，毕竟系统无法使用了。那么，我们还有另一种迁移方案，即：双写方案。
双写数据迁移
针对于停机停服数据迁移的劣势，我们可以在持久层做请求拦截，将写入、修改、删除操作修改为双写，即：对旧库和新库都要做CUD操作。那么，新的数据也就会在新库中存在一份。此时，开启数据迁移工具，将数据新增到新库中。当然，这种迁移不是没有约束的，我们会根据业务表中的modify_time字段进行约束，即：只有小于某个modify_time的数据才可以进行迁移。
当然，这也无法保证新旧库中的数据完全一致，比如就是在数据迁移过程中，有旧的数据没有在新库中，但是被修改了。针对于这种情况，我们会开启第二遍的check操作，将第一遍数据迁移后的新旧库中数据再进行校验和补充修复。最终达到一致性。
今天的文章内容就这些了：
写作不易，笔者几个小时甚至数天完成的一篇文章，只愿换来您几秒钟的 点赞 & 分享 。
更多技术干货，欢迎大家关注公众号“爪哇缪斯” ~ (^o^)/ ~ 「干货分享，每天更新」
