基於alibaba-canal的異構數據同步解決方案

隨着業務的發展，公司的整體架構方向向微服務演進。隨之衍生出各種問題，本文主要提供的是數據庫隔離（分庫）之後的跨庫join問題一種解決方案。

起因：

​ 商品服務的抽離，表結構細化；導致各依賴模塊出現了各種跨庫join問題。在某些複雜的業務場景下，基於原表（未分庫前的商品信息）的一次join操作，在新的表結構下需要做多次跨庫join。基於此場景，最終確定了技術方案：

• 對於簡單的跨庫join操作，使用服務層代碼進行數據組裝的方式，通過服務調用 + 數據庫in查詢的方式解決。

• 對於複雜的業務操作，使用數據異構同步的方式，將細化後的商品信息同步、聚合到依賴模塊的庫中，以滿足複雜業務的需求。

  本文主要介紹一種基於alibaba-canal的數據異構同步的解決方案。

技術清單：

• Mysql – 數據庫
• Canal– alibaba開源的數據庫日誌監聽中間件
• Zookeeper – canal高可用的依賴
• RocketMQ – 消息服務

架構設計圖：

組件分析：

canal:

​ 最初有考慮在商品服務中埋點，使用事件監聽的模型來做這個同步需求（即每次數據庫的增刪改都會觸發同步事件）。

​ 後期分析認爲，數據異構同步應採用一種脫離於業務需求之外的，不能對業務有入侵的一種方案來進行。而數據的改動最終都將落實到數據庫層面，於是最終採用了基於canal的，監聽源庫日誌的同步方式。

zookeeper：

​ canal高可用依賴。

binlog-subscribe:

​ binlog-subscribe用於監聽canal分析後的binlog日誌，經過二次篩選，解耦，將需要關注的數據庫變更信息分裝併發送到MQ組件。

​ **client訂閱過濾：**由於canal自帶的filter不能過濾到column級別，所以在本架構中，索性只負責更粗粒度的篩選-schemas；而對於不同的下游消費系統，需要關注的具體的表和字段不同，將這些下游消費系統需要關注的具體字段/表的交集寫入配置，配置成二次篩選的條件。

​ **字段映射解耦：**根據配置，將源庫的字段名與MQ消息中的實體字段名做一層映射解耦，下游系統依賴MQ消息實體中的字段名，而不依賴源表column，避免源表字段更新對下游系統造成影響。

MQ:

​ 主要用於解耦。

​ 將過濾、封裝後的數據庫變更信息寫入MQ，下游服務自行訂閱消費。

下游服務：

​ 訂閱MQ消息，處理，聚合數據。