一种在线系统数据迁移方法

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/dalinsi/article/details/52763475

1 技术方案介绍
1.1 解决数据迁移的高效性
本方案将基于消息机制驱动数据迁移功能,实现多台机器、并发执行数据迁移,而且每台机器通过Java的多线程技术执行迁移功能,最大化的利用线上所有服务器资源来执行数据迁移任务。

1.2 简化数据迁移多台机器并行执行的方案
基于消息机制驱动数据迁移无需对待迁移的数据进行拆分,所有待迁移的数据都是同等的,将数据拆分、分片的功能交给消息系统,由消息系统实现数据的拆分,把数据拆分的功能从业务系统解耦出来;目前有很多成熟的第三方消息中间件,例如:Active Mq、Apache Kafka等,本方案将采用京东自研的JMQ消息系统来完成。

1.3 简化增量数据迁移流程、降低风险
增量数据迁移功能依赖数据库binLog日志,采用binLog解析技术提取数据库binLog的变化获取待迁移的增量数据信息,通过消息机制驱动增量数据迁移;增量数据的迁移依赖数据库binLog实现,并将对数据库binLog的监听、提取、解析进行服务化,不同的业务系统不用单独建立binLog解析应用从而简化了增量数据迁移的流程,依赖数据的binLog保证了数据变化的完整性,对于增量数据的每一次变化都能够提取到,从而保证了增量数据迁移的正确性,降低了迁移风险;binLog解析采用了Canal技术。

1.4 实现数据迁移功能的复用
以上提到的数据迁移拆分解耦、增量数据迁移服务化功能不同的业务系统都能够复用,不需要重复开发相同的功能。

2 完整技术方案
本方案主要包括基于JMQ消息驱动的历史数据迁移、binLog解析技术的增量数据迁移、数据迁移完整性校验三大部分,系统整体架构设计如下:
这里写图片描述

2.1 打开数据库binlog日志写入功能
对于一个高可用的在线系统数据库服务一般都是主从结构;以MySQL数据库为例,本方案将把应用生产数据库的MySQL从库开启binLog写入功能; Mysql binlog日志有三种模式statement、mixed以及row,其中row模式的日志会把所有的执行的语句以每行记录的修改来进行记录,比如一条update语句,修改多条记录,则binlog中每一条修改都会有记录,为了能获取数据库的变更信息,本方案将采取row模式的方式来配置从库的binLog模式。

2.2 基于JMQ消息驱动数据迁移
根据以上系统架构设计,将应用A、应用B待迁移的数据分为历史数据、增量数据两部分,其中历史数据单独开发生产迁移消息的Worker(依赖Java线程实现的定时任务),该Worker生产并向Jmq消息平台应用A对应的消息队列发送历史数据迁移消息;增量数据一直处于变化的状态,通过数据库binLog解析应用对binLog日志进行监听->提取信息->解析->组装增量数据变更消息->依赖Jmq消息分发策略将不同应用的变更消息发至消息队列,应用A、应用B分别订阅数据迁移消息队列,最终由消息订阅消费者完成数据迁移任务。
a: 消息体报文设计
数据迁移消费者需要根据消息体找到对应的数据迁移记录,根据此需求以订单表t_order为例,设计了如下通用消息体示例:{“tableName”:”t_order”,”primaryKey”:1000000001},报文统一用Json格式。
b: Jmq消息分发策略
增量迁移变更消息需要根据监听的不同应用发送至不同的Jmq消息队列,此处的设计实现上需要数据库binLog解析应用获取到监听的数据库库名,通过数据库名来区分对应的消息应该发送至哪个消息队列。

2.3 历史数据迁移方案
a:历史数据迁移条件配置化
历史数据迁移条件配置化,应用系统可以根据业务特点灵活配置历史数据迁移条件,按日期、表主键ID进行迁移。
b:历史数据迁移生产者
历史数据迁移扫描Worker扫描待迁移的历史数据,根据数据迁移消息体报文设计,组装迁移消息体,通过消息生产者调用消息中间件客户端Api(消息中间件客户端与服务端通信的接口),由消息生产者将迁移消息发送至消息平台;若消息发送消息平台失败,则插入数据迁移任务(Task),由迁移异常补漏Worker扫描该数据迁移任务直至发送消息平台成功任务结束,该机制保证了数据迁移的完整性,同时也解决了消息发送过程中的异常情况。
c:数据迁移消息消费者
以迁移订单表t_order为例,下面为表的字段结构:
这里写图片描述
应用A、应用B通过订阅获取数据迁移消息,根据消息体中的表名tableName字段对应的值:”t_order”,可以路由到待迁移数据存在数据库的订单表t_order中;然后在根据消息体中的主键primaryKey字段对应的值:1000000001;可以最终查询到具体的迁移记录并完成数据迁移。
d: 历史数据迁移流程
历史数据迁移涉及历史数据迁移扫描Worker、迁移异常补漏Worker两个分支, 历史数据迁移扫描Worker主要流程扫描待迁移历史数据并生产迁移消息,若消息发送失败或迁移失败都将插入数据迁移任务;迁移异常补漏Worker主要流程扫描数据迁移任务生产数据迁移消息直到数据迁移完成。

2.4 增量数据迁移方案
a: 基于数据库binLog解析中间件提取增量数据
通过数据库binLog解析中间件,对数据库的binlog日志进行监听->提取信息解析->组装增量数据变更信息->分发JMQ消息队列。
b: 增量数据迁移Jmq生产者
增量数据迁移的Jmq生产者,需要实现配置化,因为不同的应用系统所迁移的数据表物理表名各异,所以针对这个需求,数据库binLog解析应用需要维护应用系统、库名、迁移表名的映射关系,当解析到增量数据之后,根据映射关系组装Jmq迁移消息,调用Jmq生产者客户端Api将迁移消息发送至Jmq消息平台,此处的消息队列可以和历史数据迁移消息队列共用一个。
c: 增量数据迁移Jmq消费者
各业务系统只需要订阅数据迁移JMQ消息队即可完成增量数据迁移,基于上面提到的增量数据同步与历史数据同步共用同一个消息队列,如此可以使历史数据迁移消费者也能完成增量数据迁移,实现了数据迁移消费者的共用。

2.5 数据迁移正确性校验
a:数据迁移校验设计
对迁移完成的数据需要校验其正确性,针对不同的业务数据可以校验其主要业务的字段,按天校验总条数、总金额、总状态之和等关键字段的正确性,数据迁移校验涉及到源待迁移数据和已迁移完成的数据对比,性能上开销比较大,本方案采用Java多线程技术,按天统计关键信息比对数据。
b:数据校验异常
本方案针对数据校验异常的情况,可以根据校验异常出现的日期,缩小数据数据重复迁移范围,根据历史数据迁移条件配置化可以重复将检验未通过的数据进行再次迁移,直至数据校验通过。

猜你喜欢

转载自blog.csdn.net/dalinsi/article/details/52763475