分布式微服务改造,到底怎么做数据迁移?

设计新系统容易，但是我们处理的都是老系统和历史诗句。怎么能更平滑的迁移旧数据到新的数据库和系统，特别是在异构的数据库结构情况下，达到数据准确，迁移速度快，减少停机，对业务影响小

迁移是最容易出故障的一个点。 那么如何做数据迁移呢？

最直观的一把梭方案，即全量数据的导入/出：

如果直接复制，可以 dump 后全量导入，如果是异构数据，需要用程序处理。 优点：简单 缺点：停机时间过长，数据量不太大时适合这种方案

大部分开发采用的方案，依赖数据本身的时间戳，即版本号：

优点：极大缩短停机时间

看来已经满足绝大部分需求了，还有更流弊的方案吗？

当你的公司数据库和中间件比较完善时，推荐使用。

通过主库或从库的binlog解析和重新构造数据，利用主从复制实现扩展迁移，这需要中间件的支持。可实现多线程，断点续传，全量历史和增量数据同步。

可以达到：

当然了，既然这种需求很常见，社区肯定也有支持的框架：

MySQL不像MongoDB支持数据Auto Sharding（自动分片），当：

你都要考虑如何数据迁移。不只是对DB拆分时会做数据迁移，很多场景都要给出数据迁移方案。 比如领导突然想将应用从自建机房上云，你要考虑将所有自建机房中的数据，包括MySQL、Redis、MQ等组件中的数据全部上云！

数据迁移无非是将数据从一个DB拷到另一个DB，可通过：

这有啥复杂的呢？注意了！这两种方式只支持：单库=》单库，不支持单库=》多库多表。 即便是单库=》单库，迁移过程也需满足：

若使用Binlog同步，在同步完成后再修改代码，将主库修改为新库，这就不满足可回滚！ 一旦迁移后异常，由于已经有增量数据写入新库，未写入旧库，不可能再将DB改成旧库了。

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

这是种通用方案，无论迁移MySQL还是Redis甚至MQ的数据，都可使用该方案。

“双写”方案中主从同步和双写冲突的问题，方案是双写前要将同步断掉。

假设在夜间操作，不考虑主从延迟过高。 但

这两个操作之间：

双写方案的一种隐患是新旧二库在遇到同一资源的并发操作时，执行顺序有可能不一样，进而结果就不一样。

现代的应用部署都是基于灰度的，在写操作的代码发生切换时（从双写到写新库，或者从写旧库到写新库），做灰度发布都会带来问题吧？

双写时加开关，默认关闭双写。 上线完成后关闭同步，同时打开开关，在低峰期，数据丢失的概率不高。 再配合数据校验的工作，即可保证一致性。

“双写之前要将同步断掉”, 什么时候将同步断掉呢? 数据在不断的写入, 在将同步断掉之后和开启双写之前如果有数据写入如何处理? 所以要做数据的校验和补写，一般双写会加开关，在断掉同步时马上打开双写开关，时间窗口短，数据丢失的不会很多。

1.数据同时写入两个数据库怎么做对代码的改动比较小呢？有成熟的工具或中间件来做吗？ 2.新库在同步追上旧库的binlog后，在开始双写时需要断开吗？不然对于新库会有重复的数据。如果新库需要停止对旧库的binlog同步，和双写的开启时机这里怎么做协调呢？

迁移的过程可以随时回滚，将迁移的风险降到了最低

时间周期比较长，应用有改造的成本。

基于双写的方案我总结了2种实现： 1、基于同步写新库和旧库方案 在写入数据的时候，同步写入旧库数据，异步写入新库数据。 数据校验，对部分数据进行校验（最容易出问题的地方，需要提前准备好脚本）。 使用灰度发布方式将读流量切换到新库。 观察几天没问题后，可以改成只写新库。 2、基于Canal的迁移方案 将新库配置为源库的从库，同步数据。比如使用Canal同步数据。 数据校验，对部分数据进行校验（最容易出问题的地方，需要提前准备好脚本）。 使用灰度发布方式将读流量切换到新库。 暂停应用，将新库作为主库写入，使用Canal同步到旧库。 观察几天没问题后，撤销Canal的同步。

也简单，适合数据从自建机房向云上迁移。迁移上云最担心云上环境和自建机房环境不一。 所以我们会在自建机房准备一个备库，在云上环境上准备一个新库，通过级联同步，在自建机房留下一个可回滚DB

可先将读流量切换到备库，再暂停应用的写入，将写流量切换到备库，这样所有流量都切到了备库，即又回到自建机房环境，就可认为已回滚了。

级联迁移方案可应用在将MySQL、Redis从自建机房迁移到云上的场景。

简单易实施，在业务上基本没有改造的成本

在切写的时候需要短暂的停止写入，对于业务来说是有损的，不过如果在业务低峰期来执行切写，可以将对业务的影响降至最低。

从自建机房向云上迁移数据时，也要考虑缓存的迁移方案。 缓存本来就是作为一个中间的存储而存在的，我只需在云上部署一个空的缓存节点，云上请求也会穿透到云上数据库，然后回种缓存，对于业务没有影响。 但还要考虑缓存命中率。

如部署空缓存，那所有请求都穿透到DB，DB可能宕机，这样你的服务不可用了。所以，缓存迁移重点是保持缓存热度。

Redis数据迁移可使用双写或级联同步方案，所以这里就不考虑Redis缓存的同步了，而以Memcached为例说明。

为保证缓存可用性，可部署多个副本组尽量将请求阻挡在DB层之上。

数据的:

那么，我们就能在云上部署一个副本组，这样，云上应用服务器读取云上副本组，若副本组未查到数据，即可从自建机房部署的主从缓存上加载数据，回种到云上的副本组上。

这种方式够简单，但致命问题：若云上请求穿透云上副本组，到达自建机房的主从缓存时，这个过程需要跨越专线。

这不仅会占用大量专线带宽，同时专线延迟相比于缓存的读取时间是比较大的，即使是本地不同机房之间的延迟，也会达到2～3ms，则一次前端请求可能会访问十几次甚至几十次缓存，一次请求就会平白增加几十ms甚至过百ms延迟，极大影响接口响应时间，因此在实际项目中很少用这种方案。

但是这种方案给了思路，可以通过方案的设计在系统运行中自动完成缓存预热，所以改造副本组方案，尽量减少专线带宽占用。

改造对读写缓存的方式：

双写是DB、Redis迁移的通用方案，可直接使用。双写方案中最重要的，是通过数据校验保证数据一致性，这就能在迁移过程中随时回滚。 数据库的迁移，则数据校验应该是最需花时间解决的。

若需要将自建机房的数据迁移到云，也可考虑级联复制，会造成数据短暂停写，需在业务低峰期执行。

缓存迁移重点是保证云上缓存的命中率，你可以使用改进版的副本组方式来迁移，在缓存写入的时候异步写入云上的副本组，在读取时放少量流量到云上副本组，从而又可以迁移部分数据到云上副本组，又能尽量减少穿透给自建机房造成专线延迟。

若是自建机房迁移到云上，那么专线的带宽一定是你迁移过程中的一个瓶颈点，你需要在迁移之前梳理清楚有哪些调用需要经过专线，占用带宽的情况是怎样的，带宽的延时是否能够满足要求。你的方案中也需要尽量做到在迁移过程中同机房的服务调用同机房的缓存和数据库，尽量减少对于专线带宽资源的占用。

这里的迁移是指的旧库迁移到新库，新旧库的表结构基本一样。但如果系统重构后的迁移就很难做了。我以前遇到一个大的系统，整个db里面有几千张表。重构后采用微服务的方式，原来的一个db分成了10多个db，还做了分表。有些原来旧库的表也做了拆分，合并，字段的增加、减少等。旧库表中的有些字段名字都重新命名了。这样的数据迁移都是狗血的数据迁移。整个公司组建一个数据迁移团队，包括开发，架构师，技术总监，dba，运维等几百人，数据校验也基本都是人工校验。耗几个月才完成了数据迁移。而且问题一大推。面对如何奇葩的数据迁移，有什么好方案？ 数据的同步可以考虑解析binlog来同步。校验就真的没辙了，我之前经历的大的数据迁移都是已月为单位的。

业务不做改造的话，无论哪种方案，要想新老环境数据一致，都需要短暂的禁写。即使是业务层做改造，按不同的模块双写数据库，同时MySQL新老环境相互同步，但在具体切换的时候，也要考虑主从延迟，从这点来看，其实还是会有一段时间的禁写。

老系统为.Net+SqlServer，新系统是Java+Mysql。 业务由于是直接基于标品二次开发，所以存在新老系统的业务兼容和数据兼容，并不能简单的通过双写就解决问题。 引入kafka和两个数据同步服务，两个服务之间商定共同认可的统一业务消息体，互相实时发送增量消息，并解析对方发送来的消息结合自己的业务入库。 流量在网关层依据某个hander标识字段去分流，用apollo开关可以随时掌控切换的比例。做到随时能进能退。 数据校验：

为了验证新系统的业务准确性，还在网关层做了流量拷贝，响应对比等。