记住这五步，数据迁移稳稳稳

柔情只为你懂 2022-10-10 11:18 146阅读 0赞

我的小伙伴们，还好吗？有没有想我？我更新了^\_^

今天跟大家聊聊数据迁移这点破事！你有没有遇到需要做数据做迁移的任务？肯定遇到过，就算今天没有，明天也会有！常见的迁移有：

*  从 MySQL a 将数据搬到 b ；
 *  从 Redis a 将数据搬到 b ；
 *  甚至还有数据异构的场景，将数据从 MySQL 迁移到 TiDB。

遇到这种迁移工作的时候你怎么办？你有没有一个思路来指导接下来的工作？还是每次都 case by case 的看？今天我就介绍一个业务通用的数据迁移指南，帮你轻松工作，六点下班（那是不可能的，最多六点半下~\_~）。

先看为什么老是有这种迁移来迁移去的需求。原因基本上就是三种：

1.  原来的容量不够了，需要迁移到更大容量；比较典型的是原来单库单表，现在做了拆分成为分库分表；
2.  项目开始的时候很多服务共用一个存储，随着微服务的拆分进程，需要对彼此数据拆分隔离；
3.  业务发展到新的阶段，原来的存储设计存在缺陷，更换了新的存储基础设施或者新的结构；

而一般迁移都会有一个目标：不能停机，不能影响线上业务。以前经常看到各种网站做升级时，首页会挂一个 **xx~xx 系统不可用**；这在互联网行业很难被接受的。那么对飞行中的飞机换油箱，怎么操作？

我今天就位大家介绍一下这个框架（不是我总结的，算是业内共识）。整个过程分为五步，如下图：

![72c204d693f3b20d65eec4fcdf62ab6a.png][]

下面对每一步再进行详细的讲解，大家可以结合上图反复揣摩一下这个框架怎么实际应用。

#### 步骤一：双写增量数据 ####

意思很明确，不管我们迁移的同构数据存储还是异构的。首先把增量的数据往两个存储都写进去。这时的效果就是新、老存储都有最新的增量数据。

不过这又有另外一个新的问题，现在存储变成分布式的了，没办法保证事务。解决这个问题常用的手段也无非如下几种。

##### 同步双写 #####

同步双写需要注意一个逻辑，如果老存储写失败，新存储不应该继续写入。否则你做diff的时候不知道以谁为准。

搞一个异步任务对 a、b 存储的增量数据做对比，此时肯定还是以老的为准，如果发现新的某数据不对（缺失、错误），就做以老存储的数据覆盖新存储的数据。

##### 异步双写 #####

异步写，一般逻辑是老的存储写正确后，会发一个消息出去，然后新存储消费这个消息写入新存储，如果失败就不断重试。超过阈值就人工介入。不过这里也有一个坑，由于是异步写要特别注意时序问题（这里也有很多套路，比如添加version，或者收到消息时直接读老库数据然后填充到新库）。

异步写增量数据的diff过程也与同步一致。

不管是同步还是异步写入，一定要关注新存储的容量、性能问题是否符合预期。把每个问题尽早发现解决，后面的步骤才能更顺利。

#### 步骤二：迁移存量数据 ####

当我们双写的diff符合预期，新的存储表现稳定时，此时就可以将存量数据做迁移了。存量数据迁移肯定是一个异步的过程，不管是通过日志回放、还是脚本扫都是逐步的过程。这个阶段一定要注意的是持续的diff两个库的不一致问题。

到目前为止经过双写+迁移，新老数据库理论上数据应该都是全量且一致的。经历过双写后，接下来就到了双读阶段。

#### 步骤三：双读+diff ####

这是什么意思呢？上面我们的异步diff工具一直在持续的工作，不过一般正常情况下，由于数据量非常大，diff工具很难做全量的diff，会在某个阶段采用抽样或者只做增量diff。所以我们在这里添加一个双读+diff的过程，通过线上的实际case来帮我们发现问题。这一步如果做得足够好，可以避免 99% 的事故。

具体说下这步的操作，以前只需要读老的存储，然后返回数据。现在在准备切到新的存储时，我们正常还是读老库数据+返回。不过在这个之间需要插入一个步骤：读老库数据+【读新库数据+异步diff+上报】+返回。

老库读完后，异步读新库，然后对两份数据做diff，并把结果打点上报，方便我们从监控中发现问题。注意，一定是异步读+diff，否则会影响线上性能。

#### 步骤四：切读到新的存储 ####

当经过第三步稳妥的线上流量对比后（比如达到5个9的一致率，不要抬杠要100%，你想想不可能做到），我们可以开始切读的操作了。此时注意：双写不能停，如果发生了那 1% 的问题，我们还能有一条后路。

其实到这一步基本工作基本上差不多了，主要的还是持续观察。这一步最可能发生的就是新库容量、性能存在问题，需要切回去处理后再切回来。

#### 步骤五：下掉老存储 ####

没什么好说的，一切都稳定了，干掉老存储的写、读逻辑。让代码保持干净。

整个数据的迁移，基本上都可以归纳到这五步中，如果你以前有过迁移经验可以对照想想看，是不是这样一个流程。如果不是这个流程你还没出事故，只能说你NB（运气好）！

今天的文章就结束了，争取今年还能再写两篇，哈哈~~

打个广告呀，有想看机会的联系我，抖音电商商品中心：缺人缺人缺人！业务发展快，挑战大。有意向的私聊我啊！亲自提供面试指导！职位信息如下：

![e85b13a439d9d1a2cd0145e8a288468f.png][]

--------------------

**程序改变的不止是世界**

**也改变了你我的头发**

公众号ID

dayuTalk

![aefba5c02573aa3ee0419f417d6a79c4.png][]

[72c204d693f3b20d65eec4fcdf62ab6a.png]: /images/20221005/7b25c0a8c74943a39a24fa163b5ab89d.png
[e85b13a439d9d1a2cd0145e8a288468f.png]: /images/20221005/d0cd8ee7d6104fb5b457a624c4769c9c.png
[aefba5c02573aa3ee0419f417d6a79c4.png]: /images/20221005/3f5a8fb130494d8bb44c09c6bd71db87.png