天天看點

資料異構就該這樣設計,yyds

大家好,我是不才陳某~

何謂資料異構,上周交易部門商品的同僚過來做分享,又看到這個詞,他的PPT裡面是 資料庫異構。其實我們以前做的事情,也是可以稱之為資料異構。比如我們将DB裡面的資料持久化到Redis裡面去,就是一種資料異構的方式。

如果要下個定義的話:把資料按需(資料結構、存取方式、存取形式)異地建構存儲。

常見應用場景

分庫分表中有一個最為常見的場景,為了提升資料庫的查詢能力,我們都會對資料庫做分庫分表操作。比如訂單庫,開始的時候我們是按照訂單ID次元去分庫分表,那麼後來的業務需求想按照商家次元去查詢,比如我想查詢某一個商家下的所有訂單,就非常麻煩。

這個時候通過資料異構就能很好的解決此問題,如下圖:

資料異構就該這樣設計,yyds

資料異構總結起來大概有以下幾種場景

  1. 資料庫鏡像
  2. 資料庫實時備份
  3. 多級索引
  4. search build(比如分庫分表後的多元度資料查詢)
  5. 業務cache重新整理
  6. 價格、庫存變化等重要業務消息

資料異構方向

資料異構就該這樣設計,yyds

在日常業務開發中大緻可以分為以上幾種資料去向,DB-DB這種方式,一般常見于分庫分表後,聚合查詢的時候,比如我們按照訂單ID去分庫分表,那麼這個時候我們要按照使用者ID去查詢,查詢這個使用者下面的訂單就非常不友善了,當然可以使用統一加到記憶體中去,但這樣不太好。

是以我們就可以用資料庫異構的方式,重新按照使用者ID的次元來分一個表,像在上面常見應用場景中介紹的那樣。把資料異構到redis、elasticserach、slor中去要解決的問題跟按照多元度來查詢的需求差不多。這些存儲天生都有聚合的功能。當然同時也可以提高查詢性能,應對大通路量,比如redis這種抗量銀彈。

資料異構的常用方法

1. 完整克隆

這個很簡單就是将資料庫A,全部拷貝一份到資料庫B,這樣的使用場景是離線統計跑任務腳本的時候可以。缺點也很突出,不适用于持續增長的資料。

2. 标記同步

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

3. binlog方式

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

4. MQ方式

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

binlog方式

資料異構就該這樣設計,yyds

binglog是資料的日志記錄方式,每次對資料的操作都會有binlog日志。現在開源的訂閱binlog日志的元件,比如使用比較廣泛的canal,它是阿裡開源的基于mysql資料庫binlog的增量訂閱和消費元件。

由于cannal伺服器目前讀取的binlog事件隻儲存在記憶體中,并且隻有一個canal用戶端可以進行消費。是以如果需要多個消費用戶端,可以引入activemq或者kafka。如上圖綠色虛線框部分。

我們還需要確定全量對比來保證資料的一緻性(canal+mq的重試機制基本可以保證寫入異構庫之後的資料一緻性),這個時候可以有一個全量同步WORKER程式來保證,如上圖深綠色部分。

canal的工作原理

先來看下mysql主備(主從)複制原理如下圖,在此原理基礎之上我們再來了解canal的實作原理就一眼能明白了。

資料異構就該這樣設計,yyds

mysql主備(主從)複制原理,從上層來看,複制分成三步:

  1. master将改變記錄到二進制日志(binary log)中(這些記錄叫做二進制日志事件,binary log events,可以通過show binlog events進行檢視);
  2. slave将master的binary log events拷貝到它的中繼日志(relay log);
  3. slave重做中繼日志中的事件,将改變反映它自己的資料。

再來看下canal的原理,如下圖:

資料異構就該這樣設計,yyds

cannal實作原理相對比較簡單(參照上面的mysql主備複制實作原理):

  1. canal模拟mysql slave的互動協定,僞裝自己為mysql slave,向mysql master發送dump協定
  2. mysql master收到dump請求,開始推送binary log給slave(也就是canal)
  3. canal解析binary log對象(原始為byte流)

我們在部署canal server的時候要部署多台,來保證高可用。但是canal的原理,是隻有一台伺服器在跑處理,其它的伺服器作為熱備。canal server的高可用是通過zookeeper來維護的。

有關canal更具體的使用和詳細原理請參照:github.com/alibaba/can…

注意點

  • 确認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;

MQ方式

資料異構就該這樣設計,yyds

總結