背景
苏宁易购某原子服务系统，因历史原因，使用的是 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】
,
