Mysql數(shù)據(jù)實時同步實踐

關(guān)于小米內(nèi)部使用的數(shù)據(jù)庫你知道多少？

創(chuàng)新互聯(lián)建站主要從事網(wǎng)站建設(shè)、網(wǎng)站設(shè)計、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)劍川,十多年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18982081108

背景
MySQL由于自身簡單、高效、可靠的特點，成為小米內(nèi)部使用最廣泛的數(shù)據(jù)庫，但是當數(shù)據(jù)量達到千萬/億級別的時候，mysql的相關(guān)操作會變的非常遲緩；如果這時還有實時BI展示的需求，對于mysql來說是一種災(zāi)難。
為了解決sql查詢慢，查不了的業(yè)務(wù)痛點，我們探索出一套完整的實時同步，即席查詢的解決方案，本文主要從實時同步的角度介紹相關(guān)工作。
早期業(yè)務(wù)借助Sqoop將Mysql中的數(shù)據(jù)同步到Hive來進行數(shù)據(jù)分析，使用過程中也帶來了一些問題：
  • 雖然Sqoop支持增量同步但還屬于粗粒度的離線同步，無法滿足實時性的需求
  • 每次同步Sqoop以sql的方式向Mysql發(fā)出數(shù)據(jù)請求也在一定程度上對Mysql帶來一定的壓力
  • 同時Hive對數(shù)據(jù)更新的支持也相對較弱
為了更有效地連接前端業(yè)務(wù)數(shù)據(jù)系統(tǒng)（Mysql）和后端統(tǒng)計分析系統(tǒng)（查詢分析引擎），我們需要一套實時同步mysql數(shù)據(jù)的解決方案。
小米內(nèi)部實踐
如何能夠做到數(shù)據(jù)的實時同步呢？我們想到了Mysql主從復(fù)制時使用的binlog日志，它記錄了所有的 DDL 和 DML 語句（除了數(shù)據(jù)查詢語句select、show等），以事件形式記錄，還包含語句所執(zhí)行的消耗時間
下面來看一下Mysql主從復(fù)制的原理，主要有以下幾個步驟：
  1. master（主庫）在每次準備提交事務(wù)完成數(shù)據(jù)更新前，將改變記錄到二進制日志(binary log)中
  2. slave（從庫）發(fā)起連接，連接到master，請求獲取指定位置的binlog文件
  3. master創(chuàng)建dump線程，推送binlog的slave
  4. slave啟動一個I/O線程來讀取主庫上binary log中的事件，并記錄到slave自己的中繼日志(relay log)中
  5. slave還會起動一個SQL線程，該線程從relay log中讀取事件并在備庫執(zhí)行，完成數(shù)據(jù)同步
  6. slave記錄自己的binlog   

Mysql數(shù)據(jù)實時同步實踐
binlog記錄了Mysql數(shù)據(jù)的實時變化，是數(shù)據(jù)同步的基礎(chǔ)，服務(wù)需要做的就是遵守Mysql的協(xié)議，將自己偽裝成Mysql的slave來監(jiān)聽業(yè)務(wù)從庫，完成數(shù)據(jù)實時同步。
結(jié)合小米內(nèi)部系統(tǒng)特點，構(gòu)建了Mysql數(shù)據(jù)同步服務(wù)–-LCSBinlog，作為一種獨立的數(shù)據(jù)接入方式整合在Talos Platform中，Talos Platform作為大數(shù)據(jù)集成的基礎(chǔ)解決方案，以自研消息隊列Talos為數(shù)據(jù)總線，連接各種系統(tǒng)為主要目標，提供豐富的數(shù)據(jù)Source輸入和數(shù)據(jù)Sink輸出，并且Talos天然支持流式計算，因此業(yè)務(wù)可以充分利用Talos Platform互聯(lián)互通的特性，并結(jié)合自身的業(yè)務(wù)需求實現(xiàn)更加高階的業(yè)務(wù)場景。
Mysql數(shù)據(jù)實時同步實踐
上圖是Talos Platform中的整體流程架構(gòu)，其中標紅部分是目前LCSBinlog在小米內(nèi)部使用最廣泛的一條鏈路：Mysql --->  Talos  --->   Kudu  --->   BI，數(shù)據(jù)同步到kudu后借助Sparksql查詢引擎為上層BI系統(tǒng)提供即席查詢服務(wù)，Kudu和Sparksql的整合細節(jié)可以參見往期內(nèi)容：告別”紛紛擾擾”—小米OLAP服務(wù)架構(gòu)演進
LCSBinlog服務(wù)的主體架構(gòu)
服務(wù)一共有兩種角色
   Master ：主要負責作業(yè)的調(diào)度，
   Worker： 主要完成具體的數(shù)據(jù)同步任務(wù)
在Worker上運行兩種作業(yè)：
  1. BinlogSyncJob：每一個mysql庫都會對應(yīng)這樣一個Job，將binlog日志完整地寫入到服務(wù)創(chuàng)建的Talos topic中
  2. MysqlSyncJob：同步歷史數(shù)據(jù)，消費binlog數(shù)據(jù)，過濾特定庫表數(shù)據(jù)實時同步至用戶配置的topic中
服務(wù)整體依賴于Zookeeper來同步服務(wù)狀態(tài)，記錄作業(yè)調(diào)度信息和標記作業(yè)運行狀態(tài)；在kudu表中記錄作業(yè)同步進度
Mysql數(shù)據(jù)實時同步實踐
控制流程如下：
  1. Worker節(jié)點通過在Zookeeper上注冊告知自己可以被調(diào)度
  2. 通過在Zookeeper上搶占EPHEMERAL臨時節(jié)點實現(xiàn)Master的HA
  3. 用戶在融合云（Web）上注冊BinlogSource同步任務(wù)
  4. Master周期性從配置服務(wù)讀取Binlog同步作業(yè)配置
  5. Master更新Zookeeper中的調(diào)度信息
  6. Worker節(jié)點 根據(jù)Zookeeper上的調(diào)度信息啟動新分配任務(wù)，停止配置失效任務(wù)；作業(yè)啟動后完成數(shù)據(jù)實時同步并周期性將同步進度記錄在kudu中
  7. 服務(wù)上報監(jiān)控信息到Falcon平臺，作業(yè)異常退出發(fā)送報警郵件
 如何保障數(shù)據(jù)正確性
>>>>

順序性

用戶配置的每一個BinlogSource 都會綁定一個Talos的topic，在進行消費的時候需要保證同一條mysql記錄操作的順序性，消息隊列Talos是無法保證全局消息有序的，只能保證partition內(nèi)部有序。
對于配置分庫分表或者多庫同步任務(wù)的BinlogSource，服務(wù)會根據(jù)庫表信息進行hash，將數(shù)據(jù)寫入相應(yīng)的partiton，保證同一張表的數(shù)據(jù)在一個partition中，使得下游消費數(shù)據(jù)的順序性；
對于單表同步的作業(yè)目前使用一個partition保證其數(shù)據(jù)有序。
>>>>

一致性

如何保證在作業(yè)異常退出后，作業(yè)重新啟動能夠完整地將mysql中的數(shù)據(jù)同步到下游系統(tǒng)，主要依賴于以下三點
  1. 服務(wù)會記錄作業(yè)同步的offset，重啟后從上次commit的offset繼續(xù)消費   
  2. Binlog數(shù)據(jù)的順序性保證了即便數(shù)據(jù)被重復(fù)消費（未commit的數(shù)據(jù)），也能對同一條記錄的操作以相同的順序執(zhí)行
  3. 下游存儲系統(tǒng)kudu，Es ，redis基于主鍵的操作能夠保證binlog重復(fù)回放后數(shù)據(jù)的最終一致性
應(yīng)用場景  
有了這份數(shù)據(jù)我們可以做些什么事情呢，本節(jié)例舉了幾種常見的應(yīng)用場景     
>>>>

實時更新緩存

業(yè)務(wù)查詢類服務(wù)往往會在mysql之上架設(shè)一個緩存，減少對底層數(shù)據(jù)庫的訪問；當mysql庫數(shù)據(jù)變化時，如果緩存還沒有過期那么就會拿到過期的數(shù)據(jù)，業(yè)務(wù)期望能夠?qū)崟r更新緩存；
利用binlog服務(wù)，根據(jù)策略實時將數(shù)據(jù)同步到redis中，這樣就能夠保證了緩存中數(shù)據(jù)有效性，減少了對數(shù)據(jù)庫的調(diào)用，從而提高整體性能。
Mysql數(shù)據(jù)實時同步實踐
>>>>

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

隨著業(yè)務(wù)的發(fā)展，同一份數(shù)據(jù)可能有不同的分析用途，數(shù)據(jù)成功寫入到mysql的同時也需要被同步到其他系統(tǒng)；如果用同步的方式處理，一方面拉長了一次事務(wù)整個流程，另一方面系統(tǒng)間也會相互影響
數(shù)據(jù)在mysql中操作成功后才會記錄在binlog中，保證下游處理到時的一致性；使用binlog服務(wù)完成數(shù)據(jù)的下發(fā)，有助于系統(tǒng)的解耦
關(guān)于異步處理，系統(tǒng)解耦在消息隊列價值思考一文中有更深入的解讀 
>>>>

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

就如文章開篇提到的，mysql在一定場景下的性能瓶頸，mysql數(shù)據(jù)同步到kudu后可以借助sparksql完成性能的提升
因為同樣是sql接口，對使用者的切換成本也是較低的，數(shù)據(jù)同步到更適合的存儲中進行查詢，也能夠避免因大查詢而對原mysql庫其他查詢的影響
目前小米內(nèi)部穩(wěn)定運行3000+的同步作業(yè)，使用binlog服務(wù)同步數(shù)據(jù)到kudu中；小米內(nèi)部BI明星產(chǎn)品XDATA借助整套同步流程很好地支持了運營、sql分析同學日常統(tǒng)計分析的需求
如何使用Binlog數(shù)據(jù)
用戶接入數(shù)據(jù)的時候要求mysql庫開啟binlog日志格式必須為Row模式：記錄的是每一行記錄的每個字段變化前后的值，雖然會造成binlog數(shù)據(jù)量的增多，但是能夠確保每一條記錄準確性，避免數(shù)據(jù)同步不一致情況的出現(xiàn)
最終通過監(jiān)聽binlog日志，LCSBinlog服務(wù)將數(shù)據(jù)轉(zhuǎn)換成如下的數(shù)據(jù)結(jié)構(gòu)，寫入用戶注冊的Topic中， 目前Sink服務(wù)使用SparkStreaming實時轉(zhuǎn)儲數(shù)據(jù)到kudu中，后續(xù)也將逐步遷移到Flink上以提升資源利用、降低延遲
Mysql數(shù)據(jù)實時同步實踐
業(yè)務(wù)用戶也可以根據(jù)我們提供的數(shù)據(jù)格式，實時消費Talos數(shù)據(jù)以實現(xiàn)更復(fù)雜的業(yè)務(wù)邏輯，下表為每一種數(shù)據(jù)操作，是否保存修改前后的列表    
Mysql數(shù)據(jù)實時同步實踐
 疑難雜癥
下面分享2個上線后遇到的有趣問題
>>>>

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

業(yè)務(wù)接入一段時間后, 發(fā)現(xiàn)部分表會偶爾存在kudu表的數(shù)據(jù)條目數(shù)多于同步的mysql表的數(shù)據(jù)條目數(shù)，我們將多出來的數(shù)據(jù)與mysql產(chǎn)生的binlog日志經(jīng)過一一對比，發(fā)現(xiàn)用戶在mysql表中設(shè)置了唯一索引，通過唯一索引修改了主鍵，而kudu中的數(shù)據(jù)是通過主鍵標識或更新一條記錄的，于是update操作變成了insert操作，這就造成了原來的1條記錄變成了2條。
解決辦法：對于這種類型的表，LCSBinlog服務(wù)會把一次Update操作轉(zhuǎn)換成一條Delete數(shù)據(jù)和一條Insert數(shù)據(jù)
>>>>

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

服務(wù)剛上線的時候，通過jdbc 執(zhí)行sql的方式完成全量歷史數(shù)據(jù)的同步，在同步的過程中會發(fā)現(xiàn)dump任務(wù)會卡頓很長時間才會返回結(jié)果，當數(shù)據(jù)量很大會出現(xiàn)超時同步失敗的情況，會造成數(shù)據(jù)的延遲。調(diào)研后發(fā)現(xiàn)使用mysql官方j(luò)dbc在客戶端查詢數(shù)據(jù)的時候，默認為從服務(wù)器一次取出所有數(shù)據(jù)放在客戶端內(nèi)存中，fetch size參數(shù)不起作用，當一條SQL返回數(shù)據(jù)量較大時可能會出現(xiàn)OOM
解決辦法：當statement設(shè)置以下屬性時，采用的是流數(shù)據(jù)接收方式，每次只從服務(wù)器接收部份數(shù)據(jù)，直到所有數(shù)據(jù)處理完畢。優(yōu)化后歷史數(shù)據(jù)同步穩(wěn)定運行，對mysql端的壓力也很小        Mysql數(shù)據(jù)實時同步實踐    

總結(jié)

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

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

分享文章：Mysql數(shù)據(jù)實時同步實踐
轉(zhuǎn)載源于：http://bm7419.com/article46/ijpeeg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、用戶體驗、品牌網(wǎng)站制作、企業(yè)網(wǎng)站制作、商城網(wǎng)站、品牌網(wǎng)站設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)

成都網(wǎng)頁設(shè)計公司