資料異構的武器-BINLOG+MQ

發表於2017-09-12
MQ

1、定義

何謂資料異構，上週交易部門商品的同事過來做分享，又看到這個詞，他的PPT裡面是 資料庫異構。其實我們以前做的事情，也是可以成為資料異構。比如我們將DB裡面的資料持久化到REDIS裡面去，就是一種資料異構的方式。如果要下個定義的話：把資料按需（資料結構、存取方式、存取形式）異地構建儲存。

2、常見應用場景

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

異構維度.png

異構維度

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

  1. 資料庫映象
  2. 資料庫實時備份
  3. 多級索引
  4. search build（比如分庫分表後的多維度資料查詢）
  5. 業務cache重新整理
  6. 價格、庫存變化等重要業務訊息

3、資料異構方向

異構的幾種方向.png

幾種異構方式

在日常業務開發中大致可以分為以上幾種資料去向，DB-DB這種方式，一般常見於分庫分表後，聚合查詢的時候，比如我們按照訂單ID去分庫分表，那麼這個時候我們要按照使用者ID去查詢，查詢這個使用者下面的訂單就非常不方便了，當然可以使用統一加到記憶體中去，但這樣不太好。所以我們就可以用資料庫異構的方式，重新按照使用者ID的維度來分一個表，像在上面常見應用場景中介紹的那樣。把資料異構到redis、elasticserach、slor中去要解決的問題跟按照多維度來查詢的需求差不多。這些儲存天生都有聚合的功能。當然同時也可以提高查詢效能，應對大訪問量，比如redis這種抗量銀彈。

4、資料異構的常用方法

3.1、完整克隆

這個很簡單就是將資料庫A，全部拷貝一份到資料庫B，這樣的使用場景是離線統計跑任務指令碼的時候可以。缺點也很突出，不適用於持續增長的資料。

3.2、標記同步

這個是業務場景比較簡單的時候，理想情況下資料不會發生改變，比如日誌資料，這個時候可以去標記，比如時間戳，這樣當發生故障的時候還可以回溯到上一次同步點，開始重新同步資料。

3.3、BINLOG方式

通過實時的訂閱mysql的binlog日誌，消費到這些日誌後，重新構建資料結構插入一個新的資料庫或者是其他儲存比如es、slor等等。訂閱binlog日誌可以比較好的能保證資料的一致性。

3.4、MQ方式

業務資料寫入DB的同時，也傳送MQ一份，也就是業務裡面實現雙寫。這種方式比較簡單，但也很難保證資料一致性，對簡單的業務場景可以採用這種方式。

5、binlog和mq方式重點介紹

5.1、binlog

5.1.1、訂閱binglog日誌異構流程圖

canal異構方式.png

canal異構方式

5.1.2、使用說明

binglog是資料的日誌記錄方式，每次對資料的操作都會有binlog日誌。現在開源的訂閱binlog日誌的元件，比如使用比較廣泛的canal，它是阿里開源的基於mysql資料庫binlog的增量訂閱和消費元件。由於cannal伺服器目前讀取的binlog事件只儲存在記憶體中，並且只有一個canal客戶端可以進行消費。所以如果需要多個消費客戶端，可以引入activemq或者kafka。如上圖綠色虛線框部分。我們還需要確保全量對比來保證資料的一致性（canal+mq的重試機制基本可以保證寫入異構庫之後的資料一致性），這個時候可以有一個全量同步WORKER程式來保證，如上圖深綠色部分。

5.1.3、canal的工作原理

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

mysql主備複製實現原理.jpg

mysql主備複製實現原理

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.4、注意點
  • 1、確認MySQL開啟binlog，使用show variables like ‘log_bin’; 檢視ON為已開啟
  • 2、確認目標庫可以產生binlog，show master status 注意Binlog_Do_DB，Binlog_Ignore_DB引數
  • 3、確認binlog格式為ROW，使用show variables like ‘binlog_format’; 非ROW模式登入MySQL執行 set global binlog_format=ROW; flush logs; 或者通過更改MySQL配置檔案並重啟MySQL生效。
  • 4、為保證binlake服務可以獲取Binlog，需新增授權，執行 GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON . TO ‘admin’@’%’ identified by ‘admin’; FLUSH PRIVILEGES;

5.2、mq方式

MQ異構方式.png

MQ異構方式

mq的方式，就相對簡單，實際上是在業務邏輯中寫DB的同時去寫一次MQ，但是這種方式不能夠保證資料一致性，就是不能保證跨資源的事務。注：呼叫第三方遠端RPC的操作一定不要放到事務中。

6、總結

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

相關文章