MySQL亿级数据量实时同步,小米如何完美hold住
點(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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Spring 和 SpringBoot
- 下一篇: SQL 性能优化梳理 —— 基本概念、创