背景

苏宁易购某原子服务系统，因历史原因，使用的是 DB2 数据库。当时的设计：业务表分 2 个库、100 分表模式。如图：

数据库示意图

随着业务的发展，该系统数据量由百万级到千万级，再到亿级别，单个分表的数据量已经达到百万级。这样的数据库分表策略已经难以满足业务发展的需求。

此外，作为典型的收费数据库，DB2 的使用成本和维护成本，随着数据量的增加，也是十分高昂的。

对此，系统面临两个紧迫的诉求：

• 使用 MySQL 数据库替换 DB2
• 数据库横向扩展

该系统作为核心的原子服务系统，是要做到 7*24 小时无间断运行的，因此我们要做到不停机的迁移和扩展。这是数据迁移的前提条件。

常规双库方案

要使用 MySQL 数据库替换 DB2，且服务不中断，则需保证业务系统一段时间内，同时支持新、老数据库操作。

最简单的做法是同时配置两种数据库连接，业务代码判断、控制走 DB2 还是 MySQL 库。我们可以在代码中增加路由模块，根据路由关键字判断使用 DB2 数据库的连接，还是使用 MySQL 数据库连接。如图示：

代码实现双库切换

这种方法实现简单，但是代码耦合度太高，业务代码包含了很多与业务无关的内容，当迁移完成后，还要清理无关功能代码，有一定风险。

苏宁双库方案

另外一种思路，就是把路由功能抽取出来，让某个单独的组件去做。这里使用的中间件是 MyCat。如图：

MyCat 路由

这样，极大的减少了业务侵入性。我们这里使用的 MyCat，是我司中间件开发小组，根据业务需求，在开源 MyCat 基础上做了定制开发（例如具体的分库分表算法实现等）。路由规则通过配置文件 +SQL 解析实现。

路由方案实现

我们先了解下 MyCat 几个核心的配置文件：

• schema.xml： 包括逻辑表与物理表映射关系；数据库信息；通过一个大节点下包含多个虚拟节点方式，将 DB2 库和 MySQL 库的表整合在一起；
• rule.xml： 逻辑表映射到物理表的规则文件。这里根据我们业务的分库分表规则，定制开发了路由规则类；
• partition.txt： 路由规则，配置符合条件的 SQL 路由到 schema 中的哪个虚拟节点；
• server.xml： MyCat 服务的端口、账号等信息配置；此配置为系统级配置，与业务无关。

MyCat 解析 SQL 的示意图：

MyCat 解析 SQL 简图

由图可见，路由是通过配置文件控制的。当 DB2 和 MySQL 并存时，可以通过调整配置文件的方式，实现单个商品、批量商品（例如取余或者固定尾号等）的路由规则动态切换到 MySQL。

数据迁移常规方法

双库路由方案确定好后，第二个要解决的问题是 DB2 数据库数据迁移到 MySQL 库。

常规数据割接，可以通过将数据导出再导入的方式实现。如图：

数据迁移常规方案

此方案是数据割接的常规方案，适用数据量较小，且一比一的数据迁移。但是需要业务停机、数据静默一段时间，而且作为数据量 10 亿级的在线系统。这两点对于我们这个大数据量核心系统来说，都是不可接受的。

苏宁数据迁移方法

最终数据迁移解决方案是通过 CDC+RDRS+MyCat 协同方式实现。

关于 CDC 和 RDRS 工具的简单说明：CDC，是 IBM 公司提供的付费工具，可以 1 比 1 实现 DB2 数据库数据到 MySQL 数据库的数据迁移。

RDRS，是我司开发的一款，支持实时数据订阅及数据实时复制等，多种数据传输能力的工具。

MyCat，在 RDRS 做数据传输的过程中，实现数据重新路由到指定分库、分表的功能。

总体数据迁移示意图如下：

苏宁 CDC+RDRS+MyCat 数据迁移方法

注：1) 这里的 MyCat 是将中间库数据规整、分发到目标库上的，与上面提及的业务使用的 MyCat 用途不一样。2) DB2 的数据变化会同步到 MySQL，MySQL 数据变化不会同步到 DB2（避免数据回路问题）。

在这个阶段，我们关注的两个问题：

• 同步效率如何
• 如何比对同步结果

关于效率问题，一方面通过精简数据同步规模方式，只同步必要的业务数据；另一方面，多开几个并发任务的方式，提高效率。

具体的实现方案包括：取消日志表、归档表数据的迁移；在不影响业务库磁盘 IO 和网络带宽的情况下，适当提升并发任务数。

为了进一步降低数据同步对业务的影响，也可考虑在夜间业务量较小的时段进行，若一个晚上时间不够，还可以将任务拆成多段，分多个晚上执行。

数据对比的问题，一方面 CDC 和 RDRS 各自保证自己关联的两端数据准确性（即，DB2 到中间库的对比，以及中间库到目标 MySQL 的对比），另一方面，我们通过我司大数据平台，写 Spark 程序实现两边业务数据库数据的比对。

最终系统现状

经过各个部门协同奋战，我们于 5 月份上线。上线后的系统关系图如下：

系统关系图

刚上线时，所有流量在 DB2 侧，确认系统稳定、业务正常后，开始数据复制迁移工作。我们花了 3 个晚上，将 DB2 全量数据迁移到 MySQL，之后增量任务持续进行。

数据迁移之后，经过一段时间的对比工作，确认迁移无误。接下来通过 MyCat 路由切换配置文件，逐步将业务流量切到 MySQL 端。

最终，经过半个月的切换，所有流量均已切到 MySQL，DB2 数据库顺利下线，退出历史舞台。

小结

回顾这次数据迁移规整，解决的核心问题可以拆解为：

• 数据迁移问题：CDC+RDRS 解决
• N:M 数据规整：RDRS+MyCat+MyCat 实现
• 流量分阶段切换处理：MyCat 配置实现

可见，MyCat 适用数据规整，及多数据库平滑过渡的场景。CDC 适用 DB2 数据到其他数据库 1:1 迁移的场景。RDRS+MyCat 可实现 MySQL 数据库间的 N:M 迁移。

这样，我们解决问题的思路也就清晰了：将一个复杂目标拆解成多个简单问题，再逐个解决简单问题，最终实现复杂目标。

作者：毛小勇

简介：2009 年毕业于安徽大学计算机科技专业，苏宁易购中台研发中心高级技术经理，主要负责平台库存、开发管理工作，经历和见证了苏宁易购电商平台的演进历程，对电商中后台业务逻辑有较深入的理解。对系统大数据、高并发、低延时等的解决方案有较丰富的经验。

【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】