點(diǎn)擊上方“朱小廝的博客”，選擇“設(shè)為星標(biāo)”

后臺(tái)回復(fù)”1024“獲取公眾號(hào)專屬1024GB資料

作者丨劉心光

來源丨小米云技術(shù)（ID：mi-cloud-tech）

背景

MySQL由于自身簡單、高效、可靠的特點(diǎn)，成為小米內(nèi)部使用最廣泛的數(shù)據(jù)庫，但是當(dāng)數(shù)據(jù)量達(dá)到千萬/億級(jí)別的時(shí)候，MySQL的相關(guān)操作會(huì)變的非常遲緩；如果這時(shí)還有實(shí)時(shí)BI展示的需求，對(duì)于MySQL來說是一種災(zāi)難。

為了解決sql查詢慢，查不了的業(yè)務(wù)痛點(diǎn)，我們探索出一套完整的實(shí)時(shí)同步，即席查詢的解決方案，本文主要從實(shí)時(shí)同步的角度介紹相關(guān)工作。

早期業(yè)務(wù)借助Sqoop將MySQL中的數(shù)據(jù)同步到Hive來進(jìn)行數(shù)據(jù)分析，使用過程中也帶來了一些問題：

• 雖然Sqoop支持增量同步但還屬于粗粒度的離線同步，無法滿足實(shí)時(shí)性的需求；

• 每次同步Sqoop以sql的方式向MySQL發(fā)出數(shù)據(jù)請(qǐng)求也在一定程度上對(duì)MySQL帶來一定的壓力；

• 同時(shí)Hive對(duì)數(shù)據(jù)更新的支持也相對(duì)較弱。

為了更有效地連接前端業(yè)務(wù)數(shù)據(jù)系統(tǒng)（MySQL）和后端統(tǒng)計(jì)分析系統(tǒng)（查詢分析引擎），我們需要一套實(shí)時(shí)同步MySQL數(shù)據(jù)的解決方案。

小米內(nèi)部實(shí)踐

如何能夠做到數(shù)據(jù)的實(shí)時(shí)同步呢？我們想到了MySQL主從復(fù)制時(shí)使用的binlog日志，它記錄了所有的DDL和DML語句（除了數(shù)據(jù)查詢語句select、show等），以事件形式記錄，還包含語句所執(zhí)行的消耗時(shí)間。

下面來看一下MySQL主從復(fù)制的原理，主要有以下幾個(gè)步驟：

• master（主庫）在每次準(zhǔn)備提交事務(wù)完成數(shù)據(jù)更新前，將改變記錄到二進(jìn)制日志(binary log)中；

• slave（從庫）發(fā)起連接，連接到master，請(qǐng)求獲取指定位置的binlog文件；

• master創(chuàng)建dump線程，推送binlog的slave；

• slave啟動(dòng)一個(gè)I/O線程來讀取主庫上binary log中的事件，并記錄到slave自己的中繼日志(relay log)中；

• slave還會(huì)起動(dòng)一個(gè)SQL線程，該線程從relay log中讀取事件并在備庫執(zhí)行，完成數(shù)據(jù)同步；

• slave記錄自己的binlog。

binlog記錄了Mysql數(shù)據(jù)的實(shí)時(shí)變化，是數(shù)據(jù)同步的基礎(chǔ)，服務(wù)需要做的就是遵守Mysql的協(xié)議，將自己偽裝成Mysql的slave來監(jiān)聽業(yè)務(wù)從庫，完成數(shù)據(jù)實(shí)時(shí)同步。

結(jié)合小米內(nèi)部系統(tǒng)特點(diǎn)，構(gòu)建了Mysql數(shù)據(jù)同步服務(wù)LCSBinlog，作為一種獨(dú)立的數(shù)據(jù)接入方式整合在Talos Platform中，Talos Platform作為大數(shù)據(jù)集成的基礎(chǔ)解決方案，以自研消息隊(duì)列Talos為數(shù)據(jù)總線，連接各種系統(tǒng)為主要目標(biāo)，提供豐富的數(shù)據(jù)Source輸入和數(shù)據(jù)Sink輸出，并且Talos天然支持流式計(jì)算，因此業(yè)務(wù)可以充分利用Talos Platform互聯(lián)互通的特性，并結(jié)合自身的業(yè)務(wù)需求實(shí)現(xiàn)更加高階的業(yè)務(wù)場景。

上圖是Talos Platform中的整體流程架構(gòu)，其中標(biāo)紅部分是目前LCSBinlog在小米內(nèi)部使用最廣泛的一條鏈路：Mysql --->? Talos ?--->? ?Kudu ?--->? ?BI，數(shù)據(jù)同步到kudu后借助Sparksql查詢引擎為上層BI系統(tǒng)提供即席查詢服務(wù)，Kudu和Sparksql的整合細(xì)節(jié)可以參見往期內(nèi)容：告別”紛紛擾擾”—小米OLAP服務(wù)架構(gòu)演進(jìn)。

LCSBinlog服務(wù)的主體架構(gòu)

服務(wù)一共有兩種角色：

• Master ：主要負(fù)責(zé)作業(yè)的調(diào)度；

• Worker：主要完成具體的數(shù)據(jù)同步任務(wù)

在Worker上運(yùn)行兩種作業(yè)：

• BinlogSyncJob：每一個(gè)mysql庫都會(huì)對(duì)應(yīng)這樣一個(gè)Job，將binlog日志完整地寫入到服務(wù)創(chuàng)建的Talos topic中；

• MysqlSyncJob：同步歷史數(shù)據(jù)，消費(fèi)binlog數(shù)據(jù)，過濾特定庫表數(shù)據(jù)實(shí)時(shí)同步至用戶配置的topic中。

服務(wù)整體依賴于Zookeeper來同步服務(wù)狀態(tài)，記錄作業(yè)調(diào)度信息和標(biāo)記作業(yè)運(yùn)行狀態(tài)；在kudu表中記錄作業(yè)同步進(jìn)度。

控制流程如下：

• Worker節(jié)點(diǎn)通過在Zookeeper上注冊(cè)告知自己可以被調(diào)度；

• 通過在Zookeeper上搶占EPHEMERAL臨時(shí)節(jié)點(diǎn)實(shí)現(xiàn)Master的HA；

• 用戶在融合云（Web）上注冊(cè)BinlogSource同步任務(wù)；

• Master周期性從配置服務(wù)讀取Binlog同步作業(yè)配置；

• Master更新Zookeeper中的調(diào)度信息；

• Worker節(jié)點(diǎn) 根據(jù)Zookeeper上的調(diào)度信息啟動(dòng)新分配任務(wù)，停止配置失效任務(wù)；作業(yè)啟動(dòng)后完成數(shù)據(jù)實(shí)時(shí)同步并周期性將同步進(jìn)度記錄在kudu中；

• 服務(wù)上報(bào)監(jiān)控信息到Falcon平臺(tái)，作業(yè)異常退出發(fā)送報(bào)警郵件。

如何保障數(shù)據(jù)正確性

順序性

用戶配置的每一個(gè)BinlogSource 都會(huì)綁定一個(gè)Talos的topic，在進(jìn)行消費(fèi)的時(shí)候需要保證同一條mysql記錄操作的順序性，消息隊(duì)列Talos是無法保證全局消息有序的，只能保證partition內(nèi)部有序。

對(duì)于配置分庫分表或者多庫同步任務(wù)的BinlogSource，服務(wù)會(huì)根據(jù)庫表信息進(jìn)行hash，將數(shù)據(jù)寫入相應(yīng)的partiton，保證同一張表的數(shù)據(jù)在一個(gè)partition中，使得下游消費(fèi)數(shù)據(jù)的順序性。

對(duì)于單表同步的作業(yè)目前使用一個(gè)partition保證其數(shù)據(jù)有序。

一致性

如何保證在作業(yè)異常退出后，作業(yè)重新啟動(dòng)能夠完整地將mysql中的數(shù)據(jù)同步到下游系統(tǒng)，主要依賴于以下三點(diǎn)：

• 服務(wù)會(huì)記錄作業(yè)同步的offset，重啟后從上次commit的offset繼續(xù)消費(fèi)；

• Binlog數(shù)據(jù)的順序性保證了即便數(shù)據(jù)被重復(fù)消費(fèi)（未commit的數(shù)據(jù)），也能對(duì)同一條記錄的操作以相同的順序執(zhí)行；

• 下游存儲(chǔ)系統(tǒng)kudu，Es ，Redis基于主鍵的操作能夠保證binlog重復(fù)回放后數(shù)據(jù)的最終一致性。

應(yīng)用場景??

??

有了這份數(shù)據(jù)我們可以做些什么事情呢，本節(jié)例舉了幾種常見的應(yīng)用場景。

實(shí)時(shí)更新緩存

業(yè)務(wù)查詢類服務(wù)往往會(huì)在mysql之上架設(shè)一個(gè)緩存，減少對(duì)底層數(shù)據(jù)庫的訪問；當(dāng)mysql庫數(shù)據(jù)變化時(shí)，如果緩存還沒有過期那么就會(huì)拿到過期的數(shù)據(jù)，業(yè)務(wù)期望能夠?qū)崟r(shí)更新緩存。

利用binlog服務(wù)，根據(jù)策略實(shí)時(shí)將數(shù)據(jù)同步到redis中，這樣就能夠保證了緩存中數(shù)據(jù)有效性，減少了對(duì)數(shù)據(jù)庫的調(diào)用，從而提高整體性能。

異步處理，系統(tǒng)解耦

隨著業(yè)務(wù)的發(fā)展，同一份數(shù)據(jù)可能有不同的分析用途，數(shù)據(jù)成功寫入到mysql的同時(shí)也需要被同步到其他系統(tǒng)；如果用同步的方式處理，一方面拉長了一次事務(wù)整個(gè)流程，另一方面系統(tǒng)間也會(huì)相互影響。

數(shù)據(jù)在mysql中操作成功后才會(huì)記錄在binlog中，保證下游處理到時(shí)的一致性；使用binlog服務(wù)完成數(shù)據(jù)的下發(fā)，有助于系統(tǒng)的解耦。

關(guān)于異步處理，系統(tǒng)解耦在消息隊(duì)列價(jià)值思考一文中有更深入的解讀。

即席查詢的BI系統(tǒng)

就如文章開篇提到的，mysql在一定場景下的性能瓶頸，mysql數(shù)據(jù)同步到kudu后可以借助sparksql完成性能的提升。

因?yàn)橥瑯邮莝ql接口，對(duì)使用者的切換成本也是較低的，數(shù)據(jù)同步到更適合的存儲(chǔ)中進(jìn)行查詢，也能夠避免因大查詢而對(duì)原mysql庫其他查詢的影響。

目前小米內(nèi)部穩(wěn)定運(yùn)行3000+的同步作業(yè)，使用binlog服務(wù)同步數(shù)據(jù)到kudu中；小米內(nèi)部BI明星產(chǎn)品XDATA借助整套同步流程很好地支持了運(yùn)營、sql分析同學(xué)日常統(tǒng)計(jì)分析的需求。

如何使用Binlog數(shù)據(jù)

用戶接入數(shù)據(jù)的時(shí)候要求mysql庫開啟binlog日志格式必須為Row模式：記錄的是每一行記錄的每個(gè)字段變化前后的值，雖然會(huì)造成binlog數(shù)據(jù)量的增多，但是能夠確保每一條記錄準(zhǔn)確性，避免數(shù)據(jù)同步不一致情況的出現(xiàn)。

最終通過監(jiān)聽binlog日志，LCSBinlog服務(wù)將數(shù)據(jù)轉(zhuǎn)換成如下的數(shù)據(jù)結(jié)構(gòu)，寫入用戶注冊(cè)的Topic中， 目前Sink服務(wù)使用SparkStreaming實(shí)時(shí)轉(zhuǎn)儲(chǔ)數(shù)據(jù)到kudu中，后續(xù)也將逐步遷移到Flink上以提升資源利用、降低延遲。

業(yè)務(wù)用戶也可以根據(jù)我們提供的數(shù)據(jù)格式，實(shí)時(shí)消費(fèi)Talos數(shù)據(jù)以實(shí)現(xiàn)更復(fù)雜的業(yè)務(wù)邏輯，下表為每一種數(shù)據(jù)操作，是否保存修改前后的列表。? ?

疑難雜癥

下面分享2個(gè)上線后遇到的有趣問題。

1）數(shù)據(jù)不一致問題，業(yè)務(wù)使用唯一索引

業(yè)務(wù)接入一段時(shí)間后，發(fā)現(xiàn)部分表會(huì)偶爾存在kudu表的數(shù)據(jù)條目數(shù)多于同步的mysql表的數(shù)據(jù)條目數(shù)，我們將多出來的數(shù)據(jù)與mysql產(chǎn)生的binlog日志經(jīng)過一一對(duì)比，發(fā)現(xiàn)用戶在mysql表中設(shè)置了唯一索引，通過唯一索引修改了主鍵，而kudu中的數(shù)據(jù)是通過主鍵標(biāo)識(shí)或更新一條記錄的，于是update操作變成了insert操作，這就造成了原來的1條記錄變成了2條。

解決辦法：對(duì)于這種類型的表，LCSBinlog服務(wù)會(huì)把一次Update操作轉(zhuǎn)換成一條Delete數(shù)據(jù)和一條Insert數(shù)據(jù)。

2）Full Dump同步歷史數(shù)據(jù)時(shí)，客戶端超時(shí)

服務(wù)剛上線的時(shí)候，通過jdbc 執(zhí)行sql的方式完成全量歷史數(shù)據(jù)的同步，在同步的過程中會(huì)發(fā)現(xiàn)dump任務(wù)會(huì)卡頓很長時(shí)間才會(huì)返回結(jié)果，當(dāng)數(shù)據(jù)量很大會(huì)出現(xiàn)超時(shí)同步失敗的情況，會(huì)造成數(shù)據(jù)的延遲。調(diào)研后發(fā)現(xiàn)使用mysql官方j(luò)dbc在客戶端查詢數(shù)據(jù)的時(shí)候，默認(rèn)為從服務(wù)器一次取出所有數(shù)據(jù)放在客戶端內(nèi)存中，fetch size參數(shù)不起作用，當(dāng)一條SQL返回?cái)?shù)據(jù)量較大時(shí)可能會(huì)出現(xiàn)OOM。

解決辦法：當(dāng)statement設(shè)置以下屬性時(shí)，采用的是流數(shù)據(jù)接收方式，每次只從服務(wù)器接收部份數(shù)據(jù)，直到所有數(shù)據(jù)處理完畢。優(yōu)化后歷史數(shù)據(jù)同步穩(wěn)定運(yùn)行，對(duì)mysql端的壓力也很小。? ??

總結(jié)?

? ? ? ? ? ? ??

MySQL以Binlog日志的方式記錄數(shù)據(jù)變化，基于流式數(shù)據(jù)的Change Data Caputre (CDC)機(jī)制實(shí)現(xiàn)了LCSBinlog服務(wù)。

本文主要對(duì)LCSBinlog的服務(wù)架構(gòu)、應(yīng)用場景以及在小米內(nèi)部的實(shí)踐經(jīng)驗(yàn)進(jìn)行了介紹，也和大家分享了我們實(shí)際中遇到的問題和解決方案，希望能夠幫助到大家理解服務(wù)的原理，帶來啟發(fā)，也歡迎大家和我們一起交流。

想知道更多？掃描下面的二維碼關(guān)注我

【精彩推薦】

• 五分鐘看完linux重點(diǎn)知識(shí)

• 為什么我使用了索引，查詢還是慢？

• 那些和閏年有關(guān)的bug

• 混沌工程初識(shí)
  

朕已閱?

總結(jié)

以上是生活随笔為你收集整理的MySQL亿级数据量实时同步，小米如何完美hold住的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。