概述

在實(shí)際的項(xiàng)目開發(fā)與運(yùn)維過程中，MySQL 常常扮演著業(yè)務(wù)數(shù)據(jù)庫(kù)的核心角色，以其強(qiáng)大的事務(wù)處理能力和數(shù)據(jù)完整性保障，支撐著系統(tǒng)的穩(wěn)定運(yùn)行。然而，隨著數(shù)據(jù)量的急劇增長(zhǎng)和查詢復(fù)雜度的不斷提升，單一依賴 MySQL 進(jìn)行高效的數(shù)據(jù)檢索顯得日益吃力，尤其是在面對(duì)海量數(shù)據(jù)的復(fù)雜查詢場(chǎng)景時(shí)，性能瓶頸愈發(fā)凸顯。

為了有效緩解這一挑戰(zhàn)，我們通常采用讀寫分離的策略，將 Elasticsearch（簡(jiǎn)稱 ES）引入作為專門的查詢數(shù)據(jù)庫(kù)。ES 以其卓越的搜索性能、靈活的數(shù)據(jù)模式以及強(qiáng)大的可擴(kuò)展性，成為處理復(fù)雜查詢需求的理想選擇。通過 ES，我們可以實(shí)現(xiàn)數(shù)據(jù)的快速檢索與分析，從而大幅提升用戶體驗(yàn)和系統(tǒng)響應(yīng)速度。

在這一過程中，確保 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)定性和用戶體驗(yàn)的基石。因此，我們需要精心設(shè)計(jì)與實(shí)施一套高效、可靠的數(shù)據(jù)同步方案。

具體而言，數(shù)據(jù)同步的實(shí)現(xiàn)方式多種多樣，包括但不限于使用 Logstash、Kafka Connect、Debezium 等工具進(jìn)行實(shí)時(shí)數(shù)據(jù)捕獲與傳輸，或通過定時(shí)任務(wù)（如 Cron Job）結(jié)合 SQL 查詢與批量導(dǎo)入的方式實(shí)現(xiàn)數(shù)據(jù)的定期同步。在選擇同步方案時(shí)，我們需要綜合考慮數(shù)據(jù)的實(shí)時(shí)性要求、系統(tǒng)架構(gòu)的復(fù)雜度、運(yùn)維成本以及數(shù)據(jù)的增量更新特性等因素。

同步方案

1. 同步雙寫

同步雙寫是一種數(shù)據(jù)同步策略，它指的是在主數(shù)據(jù)庫(kù)（如MySQL）上進(jìn)行數(shù)據(jù)修改操作時(shí)，同時(shí)將這些修改同步寫入到ES中。這種策略旨在確保兩個(gè)數(shù)據(jù)庫(kù)之間的數(shù)據(jù)一致性，并優(yōu)化系統(tǒng)的讀寫性能。

圖片

目標(biāo)

同步雙寫是指在進(jìn)行數(shù)據(jù)寫入操作時(shí)，同時(shí)向兩個(gè)或多個(gè)數(shù)據(jù)庫(kù)寫入相同的數(shù)據(jù)。在MySQL與ES的同步場(chǎng)景中，其主要目的是將MySQL中的業(yè)務(wù)數(shù)據(jù)實(shí)時(shí)同步到ES中，以便利用ES的高效查詢能力來應(yīng)對(duì)復(fù)雜的查詢需求，同時(shí)減輕MySQL的查詢壓力。

實(shí)現(xiàn)方式

直接同步

在業(yè)務(wù)代碼中，每次對(duì)MySQL數(shù)據(jù)庫(kù)進(jìn)行寫入操作時(shí)，同時(shí)執(zhí)行對(duì)ES的寫入操作。這種方式簡(jiǎn)單直接，但可能增加代碼的復(fù)雜性和出錯(cuò)的風(fēng)險(xiǎn)。

使用中間件

利用消息隊(duì)列（如Kafka）、數(shù)據(jù)變更捕獲工具（如Debezium）或ETL工具（如Logstash）等中間件來捕獲MySQL的數(shù)據(jù)變更事件，并將這些事件轉(zhuǎn)發(fā)到ES進(jìn)行同步。這種方式可以解耦業(yè)務(wù)代碼與數(shù)據(jù)同步邏輯，提高系統(tǒng)的可擴(kuò)展性和可維護(hù)性。

觸發(fā)器與存儲(chǔ)過程

在MySQL中設(shè)置觸發(fā)器或編寫存儲(chǔ)過程，在數(shù)據(jù)發(fā)生變更時(shí)自動(dòng)觸發(fā)ES的寫入操作。這種方式可以減少業(yè)務(wù)代碼的侵入性，但可能會(huì)增加MySQL的負(fù)擔(dān)并影響性能。

優(yōu)缺點(diǎn)

• 優(yōu)點(diǎn)

業(yè)務(wù)邏輯編寫簡(jiǎn)單

業(yè)務(wù)查詢實(shí)時(shí)性高

• 缺點(diǎn)

業(yè)務(wù)硬編碼，有需要寫入 MySQL 的地方都需要添加寫入 ES 的代碼

業(yè)務(wù)代碼強(qiáng)耦合度很高

存在雙寫失敗丟數(shù)據(jù)風(fēng)險(xiǎn)

雙寫性能較差，本來 MySQL 的性能不是很高，再加一個(gè) ES，系統(tǒng)的性能必然會(huì)下降

應(yīng)用場(chǎng)景

同步雙寫策略適用于對(duì)數(shù)據(jù)一致性要求較高且需要優(yōu)化查詢性能的場(chǎng)景。例如，在電商系統(tǒng)中，可以將商品信息、訂單數(shù)據(jù)等存儲(chǔ)在MySQL中，同時(shí)將這些數(shù)據(jù)同步到ES中以支持復(fù)雜的搜索和分析需求。

2. 異步雙寫

異步雙寫也是一種數(shù)據(jù)同步策略，它允許在主數(shù)據(jù)庫(kù)（如MySQL）進(jìn)行數(shù)據(jù)修改操作時(shí)，異步地將這些修改寫入到多個(gè)數(shù)據(jù)源（如ES）中。與同步雙寫相比，異步雙寫具有降低主數(shù)據(jù)庫(kù)寫入延遲、提高系統(tǒng)性能以及避免因備庫(kù)問題而影響主庫(kù)性能等優(yōu)點(diǎn)。

圖片

優(yōu)缺點(diǎn)

• 優(yōu)點(diǎn)

提高系統(tǒng)可用性：即使備庫(kù)出現(xiàn)問題，也不會(huì)影響主庫(kù)的正常運(yùn)行和數(shù)據(jù)寫入

降低主庫(kù)寫入延遲：由于不需要等待備庫(kù)確認(rèn)，主庫(kù)可以更快地完成寫入操作，從而提高系統(tǒng)的整體性能

多數(shù)據(jù)源同步：多源寫入之間相互隔離，便于擴(kuò)展更多的數(shù)據(jù)源寫入

• 缺點(diǎn)

硬編碼問題：接入新的數(shù)據(jù)源需要實(shí)現(xiàn)新的消費(fèi)者代碼

系統(tǒng)復(fù)雜度增加：需要額外引入了消息中間件

實(shí)時(shí)性較低：由于MQ是異步消費(fèi)模型，用戶寫入的數(shù)據(jù)不一定可以馬上看到，消息擠壓等會(huì)造成延時(shí)

數(shù)據(jù)一致性風(fēng)險(xiǎn)：由于存在異步處理的時(shí)間差，可能會(huì)出現(xiàn)主庫(kù)和備庫(kù)之間數(shù)據(jù)暫時(shí)不一致的情況。因此，需要采取適當(dāng)?shù)拇胧﹣泶_保數(shù)據(jù)的最終一致性。

應(yīng)用場(chǎng)景

異步雙寫適用于對(duì)數(shù)據(jù)一致性要求不是特別高但對(duì)系統(tǒng)性能要求較高的場(chǎng)景。例如，在電商平臺(tái)中，可以將用戶訂單信息、商品庫(kù)存等關(guān)鍵數(shù)據(jù)實(shí)時(shí)同步到主數(shù)據(jù)庫(kù)中，同時(shí)將一些非關(guān)鍵數(shù)據(jù)（如用戶瀏覽記錄、商品點(diǎn)擊量等）異步地同步到備數(shù)據(jù)庫(kù)中用于數(shù)據(jù)分析。這樣可以在保證關(guān)鍵數(shù)據(jù)一致性的同時(shí)提高系統(tǒng)的整體性能。

3. Logstash同步

Logstash 是一個(gè)開源的服務(wù)器端數(shù)據(jù)處理管道，可以同時(shí)從多個(gè)來源采集數(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，沒有侵入性、沒有硬編碼

沒有業(yè)務(wù)強(qiáng)耦合，不改變?cè)瓉沓绦虻男阅?/p>

• 缺點(diǎn)

時(shí)效性較差，由于是采用定時(shí)器根據(jù)固定頻率查詢表來同步數(shù)據(jù)，盡管將同步周期設(shè)置到秒級(jí)，也還是會(huì)存在一定時(shí)間的延遲

對(duì)數(shù)據(jù)庫(kù)有一定的輪詢壓力，一種改進(jìn)方法是將輪詢放到壓力不大的從庫(kù)上

無法實(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語句信息，但不包括查詢操作。這些變更包括數(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ì)被寫入到Binlog中。同步工具（如Canal、Maxwell等）會(huì)監(jiān)聽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ò)展和定制

沒有代碼侵入、沒有硬編碼，原有系統(tǒng)不需要任何變化，沒有感知

• 缺點(diǎn)

配置和維護(hù)同步工具可能具有一定的復(fù)雜性

在高并發(fā)場(chǎng)景下，Binlog的寫入和同步可能會(huì)對(duì)數(shù)據(jù)庫(kù)性能產(chǎn)生一定影響

同步工具依賴于數(shù)據(jù)庫(kù)的Binlog功能，如果數(shù)據(jù)庫(kù)版本或配置發(fā)生變化，可能需要重新配置同步工具

5. Canal數(shù)據(jù)同步

Canal是阿里巴巴集團(tuán)提供的一個(gè)開源產(chǎn)品，能夠通過解析數(shù)據(jù)庫(kù)的增量日志，提供增量數(shù)據(jù)的訂閱和消費(fèi)功能。Canal的功能原理及詳細(xì)說明請(qǐng)參見Canal。使用Canal模擬成MySQL的Slave，實(shí)時(shí)接收MySQL的增量數(shù)據(jù)binlog，然后通過RESTful API將數(shù)據(jù)寫入到阿里云ES實(shí)例或ES Serverless應(yīng)用中，適用于對(duì)數(shù)據(jù)同步的實(shí)時(shí)性要求較高的場(chǎng)景。

同步原理

Canal 原理就是偽裝成 MySQL 的從節(jié)點(diǎn)，從而訂閱 master 節(jié)點(diǎn)的 Binlog 日志。通過訂閱binlog的方式實(shí)現(xiàn)數(shù)據(jù)實(shí)時(shí)同步，在不影響源數(shù)據(jù)庫(kù)的情況下，同步延遲可降至毫秒級(jí)別。

圖片

同步流程

1. Canal 服務(wù)端向 MySQL 的 master 節(jié)點(diǎn)傳輸 dump 協(xié)議
2. MySQL 的 master 節(jié)點(diǎn)接收到 dump 請(qǐng)求后推送 binlog 日志給 Canal 服務(wù)端，解析 binlog 對(duì)象（原始為byte流）轉(zhuǎn)成 Json 格式
3. Canal 客戶端通過 TCP 協(xié)議或 MQ 形式監(jiān)聽 Canal 服務(wù)端，同步數(shù)據(jù)到ES

執(zhí)行核心流程

圖片

圖片

• canal模擬mysql slave的交互協(xié)議，偽裝自己為mysql slave，向mysql master發(fā)送dump協(xié)議
• mysql master收到dump請(qǐng)求，開始推送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ù)交互工作，專注于上層的業(yè)務(wù)開發(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先開始收集增量數(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)買的實(shí)例，被稱為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ī)格是否滿足負(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)整，在波谷期和高峰期都能完全滿足業(yè)務(wù)需求，保證業(yè)務(wù)不受損。