◆欧志芳

（福富软件 福建 350001）

基于RocketMQ实现异构数据库同步

◆欧志芳

（福富软件 福建 350001）

在进行数据库升级改造，都需要考虑如何把原有数据库的数据不丢失、高性能地写入到新数据库，特别在涉及异构数据库同步时，我们更需要有成熟的经验来借鉴。本文通过对项目的回顾，分享基于分布式消息中间件RocketMQ来实现异构数据库的同步，总结数据不丢失的高可用实现机制，同时指导应用如何更好地设计与约束来满足高性能的要求。

分布式消息中间件；RocketMQ；异构数据库同步

0 引言

异构数据库同步的类型非常多，可以是关系数据库到nosql数据库，可以是关系数据库到小文件存储等，同步的方式因为项目的性质、项目的要求等不尽相同。本文主要说明Oracle到Mysql基于相同模型的数据同步。

1 异构数据库同步的可选方案

主要的同步方案有如下三种：

项目改造核心是不影响原系统业务感知，且出现问题时具备快速解决，所以基本排查了方案一和方案三，采用“数据层AOP+消息中间件”的实现方案。

表1 三种同步方案

2 消息中间件的选型分析

由于本次异构数据库同步的数据是作为生产使用，对消息中间件的要求比较高，常用的分布式消息中间件主要包含如表2。

系统改造要求数据不能丢失，具备横向扩展应对突发业务高峰的处理能力，同时还需要考虑改造尽量少地对现有系统的性能造成影响，基于此明确选择RocketMQ作为异构数据同步的分布式消息中间件。

3 RocketMQ核心组件介绍

3.1 Name Server

表2 常用的分布式消息中间件

Name Server是一个几乎无状态节点，可集群部署，节点之间无同步信息。它主要提供broker注册、Topic路由管理等功能。

3.2 Broker

分布式消息中间件核心组件，提供消息生产、消费，主从同步、数据刷盘等核心功能。可以横向扩展、在线扩容以提高集群性能。每个Broker与Name Server集群的所有节点建立长连接，并定时注册Topic等信息。

3.3 Producer

生产者，一般为应用调用API进行消息生产。Producer 与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer 完全无状态，可集群部署。

3.4 Consumer

消费者，一般为应用调用API进行消息消费。Consumer与Producer一样，与一个Name Server建立长连接并取Topic路由信息。Consumer与提供Topic服务的Master与Slave建立长连接，既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker 配置决定。

4 RocketMQ在CRM项目的应用

4.1 异构数据同步方案

首先实现ORACLE应用的数据双写，其次数据写入到分布式消息中间件，最后侦听消息中间件的数据实现写入到Mysql数据库。

4.2 RocketMQ的高可用方案

为了保证写入消息中间件的数据不丢失，通过集群接入高可用和消息服务高可用来实现。

（1）集群接入高可用（NameServer）

通过多个集群管理服务+故障自动切换，实现集群接入点的高可用。

（2）消息服务高可用（Broker）

通过生产与消费的自动负载均衡，实现Failover，保证某一组服务在全挂的情况下，不影响整体业务。

4.3 应用设计原则与约束

（1）消息模式选择

消息模式选择的优先顺序为：无序消息>普通有序消息>严格有序消息。在业务场景允许的情况下，优先选择无序消息，或者在业务能变通的情况下，将有序消息转化为无序消息。

（2）队列数选择

Queue分布在Broker中，则能使用Broker的资源，包括存储、IO等，一般情况下，分布在某个Broker上的Queue比例越大，则占用此broker的资源越多，Topic中的Queue分布到的broker数量越多，则性能越好、存储越大。若broker的所在机器性能不同，可以通过调整Queue数量，达到资源调优的目的。

（3）消息包体大小限制

建议平均消息包体在50K以下（压缩后）；超过此包体建议通过拆包或者文件方式传递数据；过大的包体，会加大网络超时、网络拥堵等异常情况出现的概率。

5 结束语

技术的变化日新月异，需要我们时刻关注，并积极考虑如何与项目的需求相结合，或许一个简单的创新，很多高难度要求就能迎刃而解。本文通过对基于RocketMQ进行Oralce到Mysql的数据同步的过程进行总结，说明通过简单的新技术引入、规范及应用，不仅可以解决项目的功能要求，还能快速实现对数据不丢失、处理高性能的运营要求。