21世纪了还愚公移山？数据库这么迁移更稳定！

当然分表分库也有负面影响，就是表结构变更及相关管理相比单表麻烦，有一定风险，具体如何决择，还是要根据实际情况来分析。

TDDL关键原理不多做介绍，但是在数据库迁移过程中主键冲突风险是故障重要风险点，这里简要介绍下TDDL的全局唯一主键生成原理。

如上图，TDDL Sequence是基于数据库更新＋内存分配：每次操作批量分配id，分配id的数量就是sequence的内步长，而原有id值就加上外部长值，后续的分配直接就在内存里拿，这样的优势：简单高效 缺点：无法保证自增顺序。

另外数据迁移过程中，在新库中，为了保证跟原数据库主键非冲突，需要设置一个跃迁比较大的主键，防止出现两个库中的主键冲突，这是后续迁移中要注意的关键点之一。

但围绕这个过程细化下去，我们会遇到不少问题，如：

1、数据我们该如何迁移，是一次性？还是分阶段？

2、如何校验数据迁移过程的正确性?

3、我们业务改造有问题怎么办？如何尽早发现？如何回滚？

4、我们的新库性能如何？

带着这些问题，我们进一下细化梳理迁移方案。

如上图所示，整个方案分为几个部份：

1、系统改造，包括 SQL 改造，双写开关，新库sequence创建。

SQL改造：加载两套TDDL数据源，一套是给老库的，一套是给新库的，并且生成两套mybatis sql 模板。

双写开关：设置好写新库，写老库的开关，用于线上迁移过程中双写过程及遇到问题及时回滚。

sequence创建：迁移sequence表时，需要抬升新库的sequence表中的值，用于防止主键冲突，并且需要按照主键消耗量评估一个安全值，这是非常重要的一个细节，再次强调一下。

2、稳定性保障，迁库是大事，改造过程中，稳定性重中之重，主要有系统压测，线上流量回放，故障演练。

系统压测：主要针对新库进行性能测，防止新库有意外情况。

线上流量回放：Edsger W. Dijkstra说过如果调试程序是一种标准的可以铲除BUG的流程，那么，编程就是把他们放进来的流程。通过引入线上数据在测试环境回放，可以尽可能的发现问题，保证改造后的稳定性。

故障演练：通过注入一些人为故障，如写新库失败，新库逻辑有问题，及时的演练回滚策略。

3、数据迁移 ，主要利用阿里云数据传输服务DTS[3]的数据迁移能力，涉及到全量迁移、增量迁移、一致性校验及反向任务。

全量迁移:数据迁移首要目标如何将历史全量数据迁移到新库中，我们的做法是指定一个时间点，再根据这个时间点查找每张源表的最大及最小id,然后分别批量导到目标库中，如图：

整个过程都是查询在线库的备库，因此不影响在线业务的数据库服务。

增量迁移:由于迁移过程中业务服务一直运行，因此全量迁移完全成，并且要将全量时间点后的数据追回来，这里核心原理是同步全量时间位点后binlog日志数据来保证数据一致性，需要注意的是增量时间需要前移一小断时间(如5分钟)，其主要原因是全量迁移启动的那刻会有时间差，需要增量前移来保证数据最终一致性，如下图:

一致性校验：通过全量及增量的迁移后，此时源库跟目标的数据理论上是一致的,但实际上应用在经过功能测试，线上流量回放等阶段，数据在这个过程中有可能会现不一致的情况,因此正式上线前，需要做数据一致性校验，其原理是分批查询源表(跟全量迁移的查询方式类似)，再跟目标库进行比对,如图所示：

反向任务：迁移到新库后，会有一线离线业务对老库还有依赖，需要建立从新库到老库的回流任务，原理跟增量迁移一样，只是变更一下原库及目标库。

1、DTS数据追平，即全量同步完成，开启增量同步，并且延迟在秒级以内。

2、上线前校验，主要有线上流量回放、压测、一致性校验，故障演练。

3、线上开双写，线上同时写新库及老库，这时需要关闭增量同步任务，防止无效覆盖。

4、线上校验，执行预先准备的测试脚本并结合一致性校验工具，同时将读流量慢慢切到新库，验证双写逻辑。

5、切换数据源，关闭双写并正式写入新库。

6、创建反向任务，数据回流老库。

方案二：

1、DTS数据追平，即全量同步完成，开启增量同步，并且延迟在秒级以内。

2、上线前校验，主要有线上流量回放、压测、一致性校验，故障演练。

3、线上切开关，写新库， 同时需要关闭增量同步任务，防止无效覆盖。

4、创建反向任务，数据回流老库。

方案优缺点对比：

总结起来方案1迁移流程相对复杂，对迁移的控制力度更细，适合业务复杂，底层改造比较多，想精细化控制迁移步骤的场景，方案2迁移相对简单，过程快速，适合业务流程相对简单，可控，想快速切换的场景，具体选选择哪个方案，同学们可以根据自身的业务情况做选择。

这里考虑到闲鱼商品业务复杂，底层改造较多，从稳定性的角度考虑，最终选择方案1。

方案1，最关键的是3、4、5步骤，因此需要预先做好回滚计划。