我们都要活到老，学到老！

增量数据迁移

存量数据的迁移方案比较有限，但是增量的数据迁移方法就是百花齐放了，一般来说我们有下面的几种方法：

• DTS: 阿里云的DTS算是一条龙服务了，在提供存量数据迁移的同时也提供了增量数据迁移，只不过需要按量收费。
• 服务双写：比较适合于系统没有切换的迁移，也就是只换了存储但是系统还是同一个，比如说分库分表，redis数据同步等，这个的做法比较简单直接在代码里面同步的去写入需要迁移的数据，但是由于不是同一个数据库就不能保证事务，有可能导致迁移数据的时候会出现数据丢失，这个过程通过后续的数据校验会进行解决。
• MQ异步写入：这个可以适用于所有的场景，当有数据修改的时候发送一个MQ消息，消费者收到这个消息之后再进行数据更新。这个和上面的双写有点类似，但是他把数据库的操作变成了MQ异步了出问题的概率就会小很多
• 监听binlog: 我们可以使用之前说过的canal或者其他的一些开源的如databus去进行binlog监听，监听binlog的方式 就和上面的消息MQ方式一样，只是发送消息的这一步被我们省略了。这个方式的一个开发量来说基本是最小的。

这么多种方式我们应该使用哪种呢?我个人来说是比较推荐监听binlog的做法的，监听binlog减少开发成本，我们只需要实现consumer逻辑即可，数据能保证一致性，因为是监听的binlog这里不需要担心之前双写的时候不是一个事务的问题。

数据校验

前面所说的所有方案，虽然有很多是成熟的云服务(dts)或者中间件(canal)，但是他们都有可能出现一些数据丢失，出现数据丢失的情况整体来说还是比较少，但是非常难排查，有可能是dts或者canal不小心抖了一下，又或者是接收数据的时候不小心导致的丢失。既然我们没有办法避免我们的数据在迁移的过程中丢失，那么我们应该通过其他手段来进行校正。

通常来说我们迁移数据的时候都会有数据校验这一个步骤，但是在不同团队可能会选取不同的数据校验方案：

• 之前在美团的时候，我们会做一个双读，也就是我们所有的读取都会从新的里面读取一份，但是返回的还是老的，这个时候我们需要做这部分数据的校验，如果有问题可以发出报警人工修复或者自动修复。通过这种方式，我们常用的数据就能很快的进行一个修复，当然也会不定时的去跑一个全量的数据check，只是这种check出来修复数据的时间就比较滞后。
• 现在在猿辅导之后，我们没有采用之前的那种方式，因为双读check虽然能很快发现数据的不对，但是我们并没有对这部分数据有那么高的一个实时性校验并且双读的一个代码开发量还是稍微比较大的，但是又不能依靠不定时全量check去保证，这样就会导致我们的数据校验时间会非常的延长。我们采取了一个折中的方法，我们借鉴了对账里面的T+1的一个思路，我们每天凌晨获取老数据库中昨天更新的数据，然后和我们新数据库中的数据做一一比对，如果有数据不一样或者数据缺失，我们都可以立马进行一个修复。

当然在实际开发过程中我们也需要注意下面几点：

• 数据校验任务的一个正确性如何保证，校验任务本来就是去校正其他数据的，但是如果他自身出现了问题，就失去了校验的意义，这里目前来说只能靠review代码这种方式去保证校验任务的正确性。
• 校验任务的时候需要注意日志的打印，有时候出现问题可能是直接所有数据出现问题，那么校验任务就有可能会打出大量的错误日志，然后进行报警，有可能会将系统打挂，或者说影响其他人的服务。这里如果要简单一点搞，可以将一些非人工处理的报警搞成warn，复杂一点搞得话，可以封装一个工具，某个error打印再某个时间段超过一定量然后就不用再打印了。

校验任务注意不要影响线上运行的服务，通常校验任务会写很多批查询的语句，会出现批量扫表的情况，如果代码没有写好很容易导致数据库挂掉。

切流

当我们数据校验基本没有报错了之后，说明我们的迁移程序是比较稳定的了，那么我们就可以直接使用我们新的数据了吗?当然是不可以的，如果我们一把切换了，顺利的话当然是很好的，如果出现问题了，那么就会影响所有的用户。

（编辑：四平站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!