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:數據校驗異常
本方案針對數據校驗異常的情況，可以根據校驗異常出現的日期，縮小數據數據重複遷移範圍，根據歷史數據遷移條件配置化可以重複將檢驗未通過的數據進行再次遷移，直至數據校驗通過。