高效實(shí)時(shí)同步 MySQL 數(shù)據(jù)至 Elasticsearch
在實(shí)際的項(xiàng)目開(kāi)發(fā)與運(yùn)維過(guò)程中,MySQL 常常扮演著業(yè)務(wù)數(shù)據(jù)庫(kù)的核心角色,以其強(qiáng)大的事務(wù)處理能力和數(shù)據(jù)完整性保障,支撐著系統(tǒng)的穩(wěn)定運(yùn)行。然而,隨著數(shù)據(jù)量的急劇增長(zhǎng)和查詢(xún)復(fù)雜度的不斷提升,單一依賴(lài) MySQL 進(jìn)行高效的數(shù)據(jù)檢索顯得日益吃力,尤其是在面對(duì)海量數(shù)據(jù)的復(fù)雜查詢(xún)場(chǎng)景時(shí),性能瓶頸愈發(fā)凸顯。
為了有效緩解這一挑戰(zhàn),我們通常采用讀寫(xiě)分離的策略,將 Elasticsearch(簡(jiǎn)稱(chēng) ES)引入作為專(zhuān)門(mén)的查詢(xún)數(shù)據(jù)庫(kù)。ES 以其卓越的搜索性能、靈活的數(shù)據(jù)模式以及強(qiáng)大的可擴(kuò)展性,成為處理復(fù)雜查詢(xún)需求的理想選擇。通過(guò) ES,我們可以實(shí)現(xiàn)數(shù)據(jù)的快速檢索與分析,從而大幅提升用戶(hù)體驗(yàn)和系統(tǒng)響應(yīng)速度。
在這一過(guò)程中,確保 MySQL 數(shù)據(jù)庫(kù)與 ES 之間的數(shù)據(jù)同步成為了至關(guān)重要的一環(huán)。數(shù)據(jù)同步不僅關(guān)乎數(shù)據(jù)的實(shí)時(shí)性和準(zhǔn)確性,更是保障系統(tǒng)穩(wěn)定性和用戶(hù)體驗(yàn)的基石。因此,我們需要精心設(shè)計(jì)與實(shí)施一套高效、可靠的數(shù)據(jù)同步方案。
具體而言,數(shù)據(jù)同步的實(shí)現(xiàn)方式多種多樣,包括但不限于使用 Logstash、Kafka Connect、Debezium 等工具進(jìn)行實(shí)時(shí)數(shù)據(jù)捕獲與傳輸,或通過(guò)定時(shí)任務(wù)(如 Cron Job)結(jié)合 SQL 查詢(xún)與批量導(dǎo)入的方式實(shí)現(xiàn)數(shù)據(jù)的定期同步。在選擇同步方案時(shí),我們需要綜合考慮數(shù)據(jù)的實(shí)時(shí)性要求、系統(tǒng)架構(gòu)的復(fù)雜度、運(yùn)維成本以及數(shù)據(jù)的增量更新特性等因素。
同步方案
1. 同步雙寫(xiě)
同步雙寫(xiě)是一種數(shù)據(jù)同步策略,它指的是在主數(shù)據(jù)庫(kù)(如MySQL)上進(jìn)行數(shù)據(jù)修改操作時(shí),同時(shí)將這些修改同步寫(xiě)入到ES中。這種策略旨在確保兩個(gè)數(shù)據(jù)庫(kù)之間的數(shù)據(jù)一致性,并優(yōu)化系統(tǒng)的讀寫(xiě)性能。
圖片
目標(biāo)
同步雙寫(xiě)是指在進(jìn)行數(shù)據(jù)寫(xiě)入操作時(shí),同時(shí)向兩個(gè)或多個(gè)數(shù)據(jù)庫(kù)寫(xiě)入相同的數(shù)據(jù)。在MySQL與ES的同步場(chǎng)景中,其主要目的是將MySQL中的業(yè)務(wù)數(shù)據(jù)實(shí)時(shí)同步到ES中,以便利用ES的高效查詢(xún)能力來(lái)應(yīng)對(duì)復(fù)雜的查詢(xún)需求,同時(shí)減輕MySQL的查詢(xún)壓力。
實(shí)現(xiàn)方式
直接同步
在業(yè)務(wù)代碼中,每次對(duì)MySQL數(shù)據(jù)庫(kù)進(jìn)行寫(xiě)入操作時(shí),同時(shí)執(zhí)行對(duì)ES的寫(xiě)入操作。這種方式簡(jiǎn)單直接,但可能增加代碼的復(fù)雜性和出錯(cuò)的風(fēng)險(xiǎn)。
使用中間件
利用消息隊(duì)列(如Kafka)、數(shù)據(jù)變更捕獲工具(如Debezium)或ETL工具(如Logstash)等中間件來(lái)捕獲MySQL的數(shù)據(jù)變更事件,并將這些事件轉(zhuǎn)發(fā)到ES進(jìn)行同步。這種方式可以解耦業(yè)務(wù)代碼與數(shù)據(jù)同步邏輯,提高系統(tǒng)的可擴(kuò)展性和可維護(hù)性。
觸發(fā)器與存儲(chǔ)過(guò)程
在MySQL中設(shè)置觸發(fā)器或編寫(xiě)存儲(chǔ)過(guò)程,在數(shù)據(jù)發(fā)生變更時(shí)自動(dòng)觸發(fā)ES的寫(xiě)入操作。這種方式可以減少業(yè)務(wù)代碼的侵入性,但可能會(huì)增加MySQL的負(fù)擔(dān)并影響性能。
優(yōu)缺點(diǎn)
- 優(yōu)點(diǎn)
業(yè)務(wù)邏輯編寫(xiě)簡(jiǎn)單
業(yè)務(wù)查詢(xún)實(shí)時(shí)性高
- 缺點(diǎn)
業(yè)務(wù)硬編碼,有需要寫(xiě)入 MySQL 的地方都需要添加寫(xiě)入 ES 的代碼
業(yè)務(wù)代碼強(qiáng)耦合度很高
存在雙寫(xiě)失敗丟數(shù)據(jù)風(fēng)險(xiǎn)
雙寫(xiě)性能較差,本來(lái) MySQL 的性能不是很高,再加一個(gè) ES,系統(tǒng)的性能必然會(huì)下降
應(yīng)用場(chǎng)景
同步雙寫(xiě)策略適用于對(duì)數(shù)據(jù)一致性要求較高且需要優(yōu)化查詢(xún)性能的場(chǎng)景。例如,在電商系統(tǒng)中,可以將商品信息、訂單數(shù)據(jù)等存儲(chǔ)在MySQL中,同時(shí)將這些數(shù)據(jù)同步到ES中以支持復(fù)雜的搜索和分析需求。
2. 異步雙寫(xiě)
異步雙寫(xiě)也是一種數(shù)據(jù)同步策略,它允許在主數(shù)據(jù)庫(kù)(如MySQL)進(jìn)行數(shù)據(jù)修改操作時(shí),異步地將這些修改寫(xiě)入到多個(gè)數(shù)據(jù)源(如ES)中。與同步雙寫(xiě)相比,異步雙寫(xiě)具有降低主數(shù)據(jù)庫(kù)寫(xiě)入延遲、提高系統(tǒng)性能以及避免因備庫(kù)問(wèn)題而影響主庫(kù)性能等優(yōu)點(diǎn)。
圖片
優(yōu)缺點(diǎn)
- 優(yōu)點(diǎn)
提高系統(tǒng)可用性:即使備庫(kù)出現(xiàn)問(wèn)題,也不會(huì)影響主庫(kù)的正常運(yùn)行和數(shù)據(jù)寫(xiě)入
降低主庫(kù)寫(xiě)入延遲:由于不需要等待備庫(kù)確認(rèn),主庫(kù)可以更快地完成寫(xiě)入操作,從而提高系統(tǒng)的整體性能
多數(shù)據(jù)源同步:多源寫(xiě)入之間相互隔離,便于擴(kuò)展更多的數(shù)據(jù)源寫(xiě)入
- 缺點(diǎn)
硬編碼問(wèn)題:接入新的數(shù)據(jù)源需要實(shí)現(xiàn)新的消費(fèi)者代碼
系統(tǒng)復(fù)雜度增加:需要額外引入了消息中間件
實(shí)時(shí)性較低:由于MQ是異步消費(fèi)模型,用戶(hù)寫(xiě)入的數(shù)據(jù)不一定可以馬上看到,消息擠壓等會(huì)造成延時(shí)
數(shù)據(jù)一致性風(fēng)險(xiǎn):由于存在異步處理的時(shí)間差,可能會(huì)出現(xiàn)主庫(kù)和備庫(kù)之間數(shù)據(jù)暫時(shí)不一致的情況。因此,需要采取適當(dāng)?shù)拇胧﹣?lái)確保數(shù)據(jù)的最終一致性。
應(yīng)用場(chǎng)景
異步雙寫(xiě)適用于對(duì)數(shù)據(jù)一致性要求不是特別高但對(duì)系統(tǒng)性能要求較高的場(chǎng)景。例如,在電商平臺(tái)中,可以將用戶(hù)訂單信息、商品庫(kù)存等關(guān)鍵數(shù)據(jù)實(shí)時(shí)同步到主數(shù)據(jù)庫(kù)中,同時(shí)將一些非關(guān)鍵數(shù)據(jù)(如用戶(hù)瀏覽記錄、商品點(diǎn)擊量等)異步地同步到備數(shù)據(jù)庫(kù)中用于數(shù)據(jù)分析。這樣可以在保證關(guān)鍵數(shù)據(jù)一致性的同時(shí)提高系統(tǒng)的整體性能。
3. Logstash同步
Logstash 是一個(gè)開(kāi)源的服務(wù)器端數(shù)據(jù)處理管道,可以同時(shí)從多個(gè)來(lái)源采集數(shù)據(jù),轉(zhuǎn)換數(shù)據(jù),然后將數(shù)據(jù)發(fā)送到您指定的存儲(chǔ)庫(kù)
中。在實(shí)現(xiàn) MySQL 數(shù)據(jù)庫(kù)和 Elasticsearch 之間的數(shù)據(jù)同步時(shí),Logstash 可以發(fā)揮重要作用
圖片
優(yōu)缺點(diǎn)
- 優(yōu)點(diǎn)
不改變?cè)a,沒(méi)有侵入性、沒(méi)有硬編碼
沒(méi)有業(yè)務(wù)強(qiáng)耦合,不改變?cè)瓉?lái)程序的性能
- 缺點(diǎn)
時(shí)效性較差,由于是采用定時(shí)器根據(jù)固定頻率查詢(xún)表來(lái)同步數(shù)據(jù),盡管將同步周期設(shè)置到秒級(jí),也還是會(huì)存在一定時(shí)間的延遲
對(duì)數(shù)據(jù)庫(kù)有一定的輪詢(xún)壓力,一種改進(jìn)方法是將輪詢(xún)放到壓力不大的從庫(kù)上
無(wú)法實(shí)現(xiàn)同步刪除,需要在Elasticsearch中執(zhí)行相關(guān)命令手動(dòng)刪除
Elasticsearch中的_id字段必須與MySQL中的id字段相同
4. Binlog 實(shí)時(shí)同步
Binlog實(shí)時(shí)同步是一種數(shù)據(jù)庫(kù)同步技術(shù),主要用于實(shí)時(shí)捕獲并同步數(shù)據(jù)庫(kù)中的變更數(shù)據(jù)。
圖片
Binlog(Binary Log)是MySQL等數(shù)據(jù)庫(kù)的一種二進(jìn)制日志,它記錄了數(shù)據(jù)庫(kù)中所有更改數(shù)據(jù)的SQL語(yǔ)句信息,但不包括查詢(xún)操作。這些變更包括數(shù)據(jù)的插入、更新、刪除等。Binlog主要用于數(shù)據(jù)庫(kù)的主從復(fù)制和數(shù)據(jù)恢復(fù)。
同步原理
Binlog實(shí)時(shí)同步的原理基于數(shù)據(jù)庫(kù)的復(fù)制機(jī)制。當(dāng)數(shù)據(jù)庫(kù)發(fā)生變更時(shí),這些變更會(huì)被寫(xiě)入到Binlog中。同步工具(如Canal、Maxwell等)會(huì)監(jiān)聽(tīng)Binlog的變動(dòng),實(shí)時(shí)捕獲這些變更數(shù)據(jù),并將其同步到其他數(shù)據(jù)庫(kù)或存儲(chǔ)系統(tǒng)中。
優(yōu)缺點(diǎn)
- 優(yōu)點(diǎn)
實(shí)時(shí)性:能夠?qū)崟r(shí)捕獲和同步數(shù)據(jù)庫(kù)的變更數(shù)據(jù)
一致性:確保源數(shù)據(jù)庫(kù)和目標(biāo)數(shù)據(jù)庫(kù)之間數(shù)據(jù)的一致性
靈活性:支持多種數(shù)據(jù)庫(kù)和存儲(chǔ)系統(tǒng)之間的同步
可擴(kuò)展性:可以根據(jù)業(yè)務(wù)需求進(jìn)行擴(kuò)展和定制
沒(méi)有代碼侵入、沒(méi)有硬編碼,原有系統(tǒng)不需要任何變化,沒(méi)有感知
- 缺點(diǎn)
配置和維護(hù)同步工具可能具有一定的復(fù)雜性
在高并發(fā)場(chǎng)景下,Binlog的寫(xiě)入和同步可能會(huì)對(duì)數(shù)據(jù)庫(kù)性能產(chǎn)生一定影響
同步工具依賴(lài)于數(shù)據(jù)庫(kù)的Binlog功能,如果數(shù)據(jù)庫(kù)版本或配置發(fā)生變化,可能需要重新配置同步工具
5. Canal數(shù)據(jù)同步
Canal是阿里巴巴集團(tuán)提供的一個(gè)開(kāi)源產(chǎn)品,能夠通過(guò)解析數(shù)據(jù)庫(kù)的增量日志,提供增量數(shù)據(jù)的訂閱和消費(fèi)功能。Canal的功能原理及詳細(xì)說(shuō)明請(qǐng)參見(jiàn)Canal。使用Canal模擬成MySQL的Slave,實(shí)時(shí)接收MySQL的增量數(shù)據(jù)binlog,然后通過(guò)RESTful API將數(shù)據(jù)寫(xiě)入到阿里云ES實(shí)例或ES Serverless應(yīng)用中,適用于對(duì)數(shù)據(jù)同步的實(shí)時(shí)性要求較高的場(chǎng)景。
同步原理
Canal 原理就是偽裝成 MySQL 的從節(jié)點(diǎn),從而訂閱 master 節(jié)點(diǎn)的 Binlog 日志。通過(guò)訂閱binlog的方式實(shí)現(xiàn)數(shù)據(jù)實(shí)時(shí)同步,在不影響源數(shù)據(jù)庫(kù)的情況下,同步延遲可降至毫秒級(jí)別。
圖片
同步流程
- Canal 服務(wù)端向 MySQL 的 master 節(jié)點(diǎn)傳輸 dump 協(xié)議
- MySQL 的 master 節(jié)點(diǎn)接收到 dump 請(qǐng)求后推送 binlog 日志給 Canal 服務(wù)端,解析 binlog 對(duì)象(原始為byte流)轉(zhuǎn)成 Json 格式
- Canal 客戶(hù)端通過(guò) TCP 協(xié)議或 MQ 形式監(jiān)聽(tīng) Canal 服務(wù)端,同步數(shù)據(jù)到ES
執(zhí)行核心流程
圖片
- canal模擬mysql slave的交互協(xié)議,偽裝自己為mysql slave,向mysql master發(fā)送dump協(xié)議
- mysql master收到dump請(qǐng)求,開(kāi)始推送binary log給slave(也就是canal)
- canal解析binary log對(duì)象(原始為byte流)
5. 阿里云 DTS
數(shù)據(jù)傳輸服務(wù)DTS(Data Transmission Service)是阿里云提供的實(shí)時(shí)數(shù)據(jù)流服務(wù),支持關(guān)系型數(shù)據(jù)庫(kù)(RDBMS)、非關(guān)系型的數(shù)據(jù)庫(kù)(NoSQL)、數(shù)據(jù)多維分析(OLAP)等數(shù)據(jù)源間的數(shù)據(jù)交互,集數(shù)據(jù)同步、遷移、訂閱、集成、加工于一體,助您構(gòu)建安全、可擴(kuò)展、高可用的數(shù)據(jù)架構(gòu)。
相對(duì)于傳統(tǒng)數(shù)據(jù)遷移或同步工具,DTS為您提供功能更豐富、傳輸性能更強(qiáng)、易用性更高且安全可靠的服務(wù),幫助您簡(jiǎn)化復(fù)雜的數(shù)據(jù)交互工作,專(zhuān)注于上層的業(yè)務(wù)開(kāi)發(fā)。
系統(tǒng)架構(gòu)
圖片
架構(gòu)特性
系統(tǒng)高可用數(shù)據(jù)傳輸服務(wù)內(nèi)部每個(gè)模塊都有主備架構(gòu),保證系統(tǒng)高可用。容災(zāi)系統(tǒng)實(shí)時(shí)檢測(cè)每個(gè)節(jié)點(diǎn)的健康狀況,一旦發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)異常,會(huì)將鏈路快速切換到其他節(jié)點(diǎn)。
數(shù)據(jù)源地址動(dòng)態(tài)適配對(duì)于數(shù)據(jù)訂閱及同步鏈路,容災(zāi)系統(tǒng)還會(huì)監(jiān)測(cè)數(shù)據(jù)源的連接地址切換等變更操作,一旦發(fā)現(xiàn)數(shù)據(jù)源發(fā)生連接地址變更,它會(huì)動(dòng)態(tài)適配數(shù)據(jù)源新的連接方式,在數(shù)據(jù)源變更的情況下,保證鏈路的穩(wěn)定性。
數(shù)據(jù)同步的工作原理
圖片
DTS可以在兩個(gè)數(shù)據(jù)源之間同步正在進(jìn)行的數(shù)據(jù)變更。數(shù)據(jù)同步通常用于OLTP到OLAP的數(shù)據(jù)傳輸。數(shù)據(jù)同步包括以下兩個(gè)階段:
- 同步初始化:DTS先開(kāi)始收集增量數(shù)據(jù),然后將源數(shù)據(jù)庫(kù)的結(jié)構(gòu)和存量數(shù)據(jù)加載到目標(biāo)數(shù)據(jù)庫(kù)。
- 數(shù)據(jù)實(shí)時(shí)同步:DTS同步正在進(jìn)行的數(shù)據(jù)變更,并保持源數(shù)據(jù)庫(kù)和目標(biāo)數(shù)據(jù)庫(kù)的同步。
DTS Serverless
DTS Serverless實(shí)例是數(shù)據(jù)傳輸服務(wù)DTS(Data Transmission Service)提供的資源規(guī)格可以彈性變化的實(shí)例。Serverless實(shí)例可以適應(yīng)不斷變化的業(yè)務(wù)需求,使實(shí)例資源能夠隨業(yè)務(wù)規(guī)模的變化自動(dòng)調(diào)整,從而避免資源浪費(fèi)和控制運(yùn)維成本。
Serverless是一種動(dòng)態(tài)計(jì)費(fèi)方式,能夠根據(jù)實(shí)例負(fù)載情況以分鐘級(jí)別的動(dòng)態(tài)調(diào)整資源,并實(shí)時(shí)計(jì)費(fèi)(每小時(shí)生成一個(gè)收費(fèi)訂單),您僅需要為實(shí)際用量付費(fèi),從而節(jié)省大量成本。使用Serverless計(jì)費(fèi)方式購(gòu)買(mǎi)的實(shí)例,被稱(chēng)為Serverless實(shí)例。
Serverless實(shí)例會(huì)根據(jù)RPS(Records Per Second)、CPU、內(nèi)存利用率、網(wǎng)絡(luò)等因素動(dòng)態(tài)調(diào)整資源規(guī)格,調(diào)整的資源規(guī)格以DU(DTS Unit)數(shù)體現(xiàn)。在DU數(shù)調(diào)整后的60秒,系統(tǒng)會(huì)檢測(cè)當(dāng)前資源規(guī)格是否滿(mǎn)足負(fù)載需求。
在數(shù)據(jù)傳輸量波動(dòng)較大的場(chǎng)景下,普通實(shí)例和Serverless實(shí)例資源使用和規(guī)格變化情況如下圖所示:
圖片
由上圖可以看到,在業(yè)務(wù)波動(dòng)較大的場(chǎng)景下:
- 普通實(shí)例:在波谷期浪費(fèi)的資源較多,在高峰期資源不足,業(yè)務(wù)受損。
- Serverless實(shí)例:實(shí)例的資源規(guī)格隨負(fù)載需求動(dòng)態(tài)調(diào)整,在波谷期和高峰期都能完全滿(mǎn)足業(yè)務(wù)需求,保證業(yè)務(wù)不受損。