數據異構的武器-BINLOG+MQ

轉自：https://my.oschina.net/wangxindong/blog/1531596

一、定義

何謂數據異構，上週交易部門商品的同事過來作分享，又看到這個詞，他的PPT裏面是 數據庫異構。其實咱們之前作的事情，也是能夠成爲數據異構。好比咱們將DB裏面的數據持久化到REDIS裏面去，就是一種數據異構的方式。若是要下個定義的話：把數據按需（數據結構、存取方式、存取形式）異地構建存儲。

二、常見應用場景

分庫分表中有一個最爲常見的場景，爲了提高數據庫的查詢能力，咱們都會對數據庫作分庫分表操做。好比訂單庫，開始的時候咱們是按照訂單ID維度去分庫分表，那麼後來的業務需求想按照商家維度去查詢，好比我想查詢某一個商家下的全部訂單，就很是麻煩。這個時候經過數據異構就能很好的解決此問題，好比下圖

異構維度.png

總結起來大概有如下幾種場景

1. 數據庫鏡像
2. 數據庫實時備份
3. 多級索引
4. search build（好比分庫分表後的多維度數據查詢）
5. 業務cache刷新
6. 價格、庫存變化等重要業務消息

三、數據異構方向

異構的幾種方向.png

 

在平常業務開發中大體能夠分爲以上幾種數據去向，DB-DB這種方式，通常常見於分庫分表後，聚合查詢的時候，好比咱們按照訂單ID去分庫分表，那麼這個時候咱們要按照用戶ID去查詢，查詢這個用戶下面的訂單就很是不方便了，固然可使用統一加到內存中去，但這樣不太好。因此咱們就能夠用數據庫異構的方式，從新按照用戶ID的維度來分一個表，像在上面常見應用場景中介紹的那樣。把數據異構到redis、elasticserach、slor中去要解決的問題跟按照多維度來查詢的需求差很少。這些存儲天生都有聚合的功能。固然同時也能夠提升查詢性能，應對大訪問量，好比redis這種抗量銀彈。

四、數據異構的經常使用方法

3.一、完整克隆

這個很簡單就是將數據庫A，所有拷貝一份到數據庫B，這樣的使用場景是離線統計跑任務腳本的時候能夠。缺點也很突出，不適用於持續增加的數據。

3.二、標記同步

這個是業務場景比較簡單的時候，理想狀況下數據不會發生改變，好比日誌數據，這個時候能夠去標記，好比時間戳，這樣當發生故障的時候還能夠回溯到上一次同步點，開始從新同步數據。

3.三、BINLOG方式

經過實時的訂閱mysql的binlog日誌，消費到這些日誌後，從新構建數據結構插入一個新的數據庫或者是其餘存儲好比es、slor等等。訂閱binlog日誌能夠比較好的能保證數據的一致性。

3.四、MQ方式

業務數據寫入DB的同時，也發送MQ一份，也就是業務裏面實現雙寫。這種方式比較簡單，但也很難保證數據一致性，對簡單的業務場景能夠採用這種方式。

五、binlog和mq方式重點介紹

5.一、binlog

5.1.一、訂閱binglog日誌異構流程圖

canal異構方式.png

5.1.二、使用說明

binglog是數據的日誌記錄方式，每次對數據的操做都會有binlog日誌。如今開源的訂閱binlog日誌的組件，好比使用比較普遍的canal，它是阿里開源的基於mysql數據庫binlog的增量訂閱和消費組件。因爲cannal服務器目前讀取的binlog事件只保存在內存中，而且只有一個canal客戶端能夠進行消費。因此若是須要多個消費客戶端，能夠引入activemq或者kafka。如上圖綠色虛線框部分。咱們還須要確保全量對比來保證數據的一致性（canal+mq的重試機制基本能夠保證寫入異構庫以後的數據一致性），這個時候能夠有一個全量同步WORKER程序來保證，如上圖深綠色部分。

5.1.三、canal的工做原理：

先來看下mysql主備（主從）複製原理以下圖，在此原理基礎之上咱們再來理解canal的實現原理就一眼能明白了。

 

mysql主備複製實現原理.jpg

mysql主備（主從）複製原理，從上層來看，複製分紅三步：

1. master將改變記錄到二進制日誌(binary log)中（這些記錄叫作二進制日誌事件，binary log events，能夠經過show binlog events進行查看）；
2. slave將master的binary log events拷貝到它的中繼日誌(relay log)；
3. slave重作中繼日誌中的事件，將改變反映它本身的數據。
   再來看下canal的原理，以下圖：
   

   canal工做原理.jpg

   
   cannal實現原理相對比較簡單（參照上面的mysql主備複製實現原理）：
4. canal模擬mysql slave的交互協議，假裝本身爲mysql slave，向mysql master發送dump協議
5. mysql master收到dump請求，開始推送binary log給slave(也就是canal)
6. canal解析binary log對象(原始爲byte流)
   咱們在部署canal server的時候要部署多臺，來保證高可用。可是canal的原理，是隻有一臺服務器在跑處理，其它的服務器做爲熱備。canal server的高可用是經過zookeeper來維護的。
   有關canal更具體的使用和詳細原理請參照：https://github.com/alibaba/canal

5.1.四、注意點

• 一、確認MySQL開啓binlog，使用show variables like 'log_bin'; 查看ON爲已開啓
• 二、確認目標庫能夠產生binlog，show master status 注意Binlog_Do_DB，Binlog_Ignore_DB參數
• 三、確認binlog格式爲ROW，使用show variables like 'binlog_format'; 非ROW模式登陸MySQL執行 set global binlog_format=ROW; flush logs; 或者經過更改MySQL配置文件並重啓MySQL生效。
• 四、爲保證binlake服務能夠獲取Binlog，需添加受權，執行 GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON . TO 'admin'@'%' identified by 'admin'; FLUSH PRIVILEGES;

5.二、mq方式

MQ異構方式.png

mq的方式，就相對簡單，其實是在業務邏輯中寫DB的同時去寫一次MQ，可是這種方式不可以保證數據一致性，就是不能保證跨資源的事務。注：調用第三方遠程RPC的操做必定不要放到事務中。

六、總結

本文主要敘述了數據異構的使用場景，方法。這裏面涉及到的activemq以及canal並無深刻分析，關於這塊的內容能夠直接參考相關具體文檔，文中已給了連接地址。根據數據異構的定義，將數據異地構建存儲，咱們能夠應用的地方就很是多，文中說的分庫分表以後按照其它維度來查詢的時候，咱們想脫離DB直接用緩存好比redis來抗量的時候。數據異構這種方式都可以很好的幫助咱們來解決諸如此類的問題。
轉載請註明出處，並附上連接 https://my.oschina.net/wangxindong/blog/1531596
參考資料：https://github.com/alibaba/canal