基于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消息，處理，聚合資料。