◆歐志芳

（福富軟件 福建 350001）

基于RocketMQ實現(xiàn)異構(gòu)數(shù)據(jù)庫同步

◆歐志芳

（福富軟件 福建 350001）

在進行數(shù)據(jù)庫升級改造，都需要考慮如何把原有數(shù)據(jù)庫的數(shù)據(jù)不丟失、高性能地寫入到新數(shù)據(jù)庫，特別在涉及異構(gòu)數(shù)據(jù)庫同步時，我們更需要有成熟的經(jīng)驗來借鑒。本文通過對項目的回顧，分享基于分布式消息中間件RocketMQ來實現(xiàn)異構(gòu)數(shù)據(jù)庫的同步，總結(jié)數(shù)據(jù)不丟失的高可用實現(xiàn)機制，同時指導(dǎo)應(yīng)用如何更好地設(shè)計與約束來滿足高性能的要求。

分布式消息中間件；RocketMQ；異構(gòu)數(shù)據(jù)庫同步

0 引言

異構(gòu)數(shù)據(jù)庫同步的類型非常多，可以是關(guān)系數(shù)據(jù)庫到nosql數(shù)據(jù)庫，可以是關(guān)系數(shù)據(jù)庫到小文件存儲等，同步的方式因為項目的性質(zhì)、項目的要求等不盡相同。本文主要說明Oracle到Mysql基于相同模型的數(shù)據(jù)同步。

1 異構(gòu)數(shù)據(jù)庫同步的可選方案

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

項目改造核心是不影響原系統(tǒng)業(yè)務(wù)感知，且出現(xiàn)問題時具備快速解決，所以基本排查了方案一和方案三，采用“數(shù)據(jù)層AOP+消息中間件”的實現(xiàn)方案。

表1 三種同步方案

2 消息中間件的選型分析

由于本次異構(gòu)數(shù)據(jù)庫同步的數(shù)據(jù)是作為生產(chǎn)使用，對消息中間件的要求比較高，常用的分布式消息中間件主要包含如表2。

系統(tǒng)改造要求數(shù)據(jù)不能丟失，具備橫向擴展應(yīng)對突發(fā)業(yè)務(wù)高峰的處理能力，同時還需要考慮改造盡量少地對現(xiàn)有系統(tǒng)的性能造成影響，基于此明確選擇RocketMQ作為異構(gòu)數(shù)據(jù)同步的分布式消息中間件。

3 RocketMQ核心組件介紹

3.1 Name Server

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

Name Server是一個幾乎無狀態(tài)節(jié)點，可集群部署，節(jié)點之間無同步信息。它主要提供broker注冊、Topic路由管理等功能。

3.2 Broker

分布式消息中間件核心組件，提供消息生產(chǎn)、消費，主從同步、數(shù)據(jù)刷盤等核心功能?？梢詸M向擴展、在線擴容以提高集群性能。每個Broker與Name Server集群的所有節(jié)點建立長連接，并定時注冊Topic等信息。

3.3 Producer

生產(chǎn)者，一般為應(yīng)用調(diào)用API進行消息生產(chǎn)。Producer 與Name Server集群中的其中一個節(jié)點（隨機選擇）建立長連接，定期從Name Server取Topic路由信息，并向提供Topic服務(wù)的Master建立長連接，且定時向Master發(fā)送心跳。Producer 完全無狀態(tài)，可集群部署。

3.4 Consumer

消費者，一般為應(yīng)用調(diào)用API進行消息消費。Consumer與Producer一樣，與一個Name Server建立長連接并取Topic路由信息。Consumer與提供Topic服務(wù)的Master與Slave建立長連接，既可以從Master訂閱消息，也可以從Slave訂閱消息，訂閱規(guī)則由Broker 配置決定。

4 RocketMQ在CRM項目的應(yīng)用

4.1 異構(gòu)數(shù)據(jù)同步方案

首先實現(xiàn)ORACLE應(yīng)用的數(shù)據(jù)雙寫，其次數(shù)據(jù)寫入到分布式消息中間件，最后偵聽消息中間件的數(shù)據(jù)實現(xiàn)寫入到Mysql數(shù)據(jù)庫。

4.2 RocketMQ的高可用方案

為了保證寫入消息中間件的數(shù)據(jù)不丟失，通過集群接入高可用和消息服務(wù)高可用來實現(xiàn)。

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

通過多個集群管理服務(wù)+故障自動切換，實現(xiàn)集群接入點的高可用。

（2）消息服務(wù)高可用（Broker）

通過生產(chǎn)與消費的自動負(fù)載均衡，實現(xiàn)Failover，保證某一組服務(wù)在全掛的情況下，不影響整體業(yè)務(wù)。

4.3 應(yīng)用設(shè)計原則與約束

（1）消息模式選擇

消息模式選擇的優(yōu)先順序為：無序消息>普通有序消息>嚴(yán)格有序消息。在業(yè)務(wù)場景允許的情況下，優(yōu)先選擇無序消息，或者在業(yè)務(wù)能變通的情況下，將有序消息轉(zhuǎn)化為無序消息。

（2）隊列數(shù)選擇

Queue分布在Broker中，則能使用Broker的資源，包括存儲、IO等，一般情況下，分布在某個Broker上的Queue比例越大，則占用此broker的資源越多，Topic中的Queue分布到的broker數(shù)量越多，則性能越好、存儲越大。若broker的所在機器性能不同，可以通過調(diào)整Queue數(shù)量，達(dá)到資源調(diào)優(yōu)的目的。

（3）消息包體大小限制

建議平均消息包體在50K以下（壓縮后）；超過此包體建議通過拆包或者文件方式傳遞數(shù)據(jù)；過大的包體，會加大網(wǎng)絡(luò)超時、網(wǎng)絡(luò)擁堵等異常情況出現(xiàn)的概率。

5 結(jié)束語

技術(shù)的變化日新月異，需要我們時刻關(guān)注，并積極考慮如何與項目的需求相結(jié)合，或許一個簡單的創(chuàng)新，很多高難度要求就能迎刃而解。本文通過對基于RocketMQ進行Oralce到Mysql的數(shù)據(jù)同步的過程進行總結(jié)，說明通過簡單的新技術(shù)引入、規(guī)范及應(yīng)用，不僅可以解決項目的功能要求，還能快速實現(xiàn)對數(shù)據(jù)不丟失、處理高性能的運營要求。