概述

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

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

在這一過程中，確保 MySQL 數(shù)據(jù)庫與 ES 之間的數(shù)據(jù)同步成為了至關(guān)重要的一環(huán)。數(shù)據(jù)同步不僅關(guān)乎數(shù)據(jù)的實時性和準(zhǔn)確性，更是保障系統(tǒng)穩(wěn)定性和用戶體驗的基石。因此，我們需要精心設(shè)計與實施一套高效、可靠的數(shù)據(jù)同步方案。

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

同步方案

1. 同步雙寫

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

圖片

目標(biāo)

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

實現(xiàn)方式

直接同步

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

使用中間件

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

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

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

優(yōu)缺點

優(yōu)點

• 業(yè)務(wù)邏輯編寫簡單
• 業(yè)務(wù)查詢實時性高

缺點

• 業(yè)務(wù)硬編碼，有需要寫入 MySQL 的地方都需要添加寫入 ES 的代碼
• 業(yè)務(wù)代碼強(qiáng)耦合度很高
• 存在雙寫失敗丟數(shù)據(jù)風(fēng)險
• 雙寫性能較差，本來 MySQL 的性能不是很高，再加一個 ES，系統(tǒng)的性能必然會下降

應(yīng)用場景

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

2. 異步雙寫

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

圖片

優(yōu)缺點

優(yōu)點

• 提高系統(tǒng)可用性：即使備庫出現(xiàn)問題，也不會影響主庫的正常運行和數(shù)據(jù)寫入
• 降低主庫寫入延遲：由于不需要等待備庫確認(rèn)，主庫可以更快地完成寫入操作，從而提高系統(tǒng)的整體性能
• 多數(shù)據(jù)源同步：多源寫入之間相互隔離，便于擴(kuò)展更多的數(shù)據(jù)源寫入

缺點

• 硬編碼問題：接入新的數(shù)據(jù)源需要實現(xiàn)新的消費者代碼
• 系統(tǒng)復(fù)雜度增加：需要額外引入了消息中間件
• 實時性較低：由于MQ是異步消費模型，用戶寫入的數(shù)據(jù)不一定可以馬上看到，消息擠壓等會造成延時
• 數(shù)據(jù)一致性風(fēng)險：由于存在異步處理的時間差，可能會出現(xiàn)主庫和備庫之間數(shù)據(jù)暫時不一致的情況。因此，需要采取適當(dāng)?shù)拇胧﹣泶_保數(shù)據(jù)的最終一致性。

應(yīng)用場景

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

3. Logstash同步

Logstash 是一個開源的服務(wù)器端數(shù)據(jù)處理管道，可以同時從多個來源采集數(shù)據(jù)，轉(zhuǎn)換數(shù)據(jù)，然后將數(shù)據(jù)發(fā)送到您指定的存儲庫中。在實現(xiàn) MySQL 數(shù)據(jù)庫和 Elasticsearch 之間的數(shù)據(jù)同步時，Logstash 可以發(fā)揮重要作用。

圖片

優(yōu)缺點

優(yōu)點

• 不改變原代碼，沒有侵入性、沒有硬編碼
• 沒有業(yè)務(wù)強(qiáng)耦合，不改變原來程序的性能

缺點

• 時效性較差，由于是采用定時器根據(jù)固定頻率查詢表來同步數(shù)據(jù)，盡管將同步周期設(shè)置到秒級，也還是會存在一定時間的延遲
• 對數(shù)據(jù)庫有一定的輪詢壓力，一種改進(jìn)方法是將輪詢放到壓力不大的從庫上
• 無法實現(xiàn)同步刪除，需要在Elasticsearch中執(zhí)行相關(guān)命令手動刪除
• Elasticsearch中的_id字段必須與MySQL中的id字段相同

4. Binlog 實時同步

Binlog實時同步是一種數(shù)據(jù)庫同步技術(shù)，主要用于實時捕獲并同步數(shù)據(jù)庫中的變更數(shù)據(jù)。

圖片

Binlog（Binary Log）是MySQL等數(shù)據(jù)庫的一種二進(jìn)制日志，它記錄了數(shù)據(jù)庫中所有更改數(shù)據(jù)的SQL語句信息，但不包括查詢操作。這些變更包括數(shù)據(jù)的插入、更新、刪除等。Binlog主要用于數(shù)據(jù)庫的主從復(fù)制和數(shù)據(jù)恢復(fù)。

同步原理

Binlog實時同步的原理基于數(shù)據(jù)庫的復(fù)制機(jī)制。當(dāng)數(shù)據(jù)庫發(fā)生變更時，這些變更會被寫入到Binlog中。同步工具（如Canal、Maxwell等）會監(jiān)聽Binlog的變動，實時捕獲這些變更數(shù)據(jù)，并將其同步到其他數(shù)據(jù)庫或存儲系統(tǒng)中。

優(yōu)缺點

優(yōu)點

• 實時性：能夠?qū)崟r捕獲和同步數(shù)據(jù)庫的變更數(shù)據(jù)
• 一致性：確保源數(shù)據(jù)庫和目標(biāo)數(shù)據(jù)庫之間數(shù)據(jù)的一致性
• 靈活性：支持多種數(shù)據(jù)庫和存儲系統(tǒng)之間的同步
• 可擴(kuò)展性：可以根據(jù)業(yè)務(wù)需求進(jìn)行擴(kuò)展和定制
• 沒有代碼侵入、沒有硬編碼，原有系統(tǒng)不需要任何變化，沒有感知

缺點

• 配置和維護(hù)同步工具可能具有一定的復(fù)雜性
• 在高并發(fā)場景下，Binlog的寫入和同步可能會對數(shù)據(jù)庫性能產(chǎn)生一定影響
• 同步工具依賴于數(shù)據(jù)庫的Binlog功能，如果數(shù)據(jù)庫版本或配置發(fā)生變化，可能需要重新配置同步工具

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

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

同步原理

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

圖片

同步流程

1. Canal 服務(wù)端向 MySQL 的 master 節(jié)點傳輸 dump 協(xié)議
2. MySQL 的 master 節(jié)點接收到 dump 請求后推送 binlog 日志給 Canal 服務(wù)端，解析 binlog 對象（原始為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請求，開始推送binary log給slave(也就是canal)
• canal解析binary log對象(原始為byte流)

5. 阿里云 DTS

數(shù)據(jù)傳輸服務(wù)DTS（Data Transmission Service）是阿里云提供的實時數(shù)據(jù)流服務(wù)，支持關(guān)系型數(shù)據(jù)庫（RDBMS）、非關(guān)系型的數(shù)據(jù)庫（NoSQL）、數(shù)據(jù)多維分析（OLAP）等數(shù)據(jù)源間的數(shù)據(jù)交互，集數(shù)據(jù)同步、遷移、訂閱、集成、加工于一體，助您構(gòu)建安全、可擴(kuò)展、高可用的數(shù)據(jù)架構(gòu)。

相對于傳統(tǒng)數(shù)據(jù)遷移或同步工具，DTS為您提供功能更豐富、傳輸性能更強(qiáng)、易用性更高且安全可靠的服務(wù)，幫助您簡化復(fù)雜的數(shù)據(jù)交互工作，專注于上層的業(yè)務(wù)開發(fā)。

系統(tǒng)架構(gòu)

圖片

架構(gòu)特性

• 系統(tǒng)高可用

數(shù)據(jù)傳輸服務(wù)內(nèi)部每個模塊都有主備架構(gòu)，保證系統(tǒng)高可用。容災(zāi)系統(tǒng)實時檢測每個節(jié)點的健康狀況，一旦發(fā)現(xiàn)某個節(jié)點異常，會將鏈路快速切換到其他節(jié)點。

• 數(shù)據(jù)源地址動態(tài)適配

對于數(shù)據(jù)訂閱及同步鏈路，容災(zāi)系統(tǒng)還會監(jiān)測數(shù)據(jù)源的連接地址切換等變更操作，一旦發(fā)現(xiàn)數(shù)據(jù)源發(fā)生連接地址變更，它會動態(tài)適配數(shù)據(jù)源新的連接方式，在數(shù)據(jù)源變更的情況下，保證鏈路的穩(wěn)定性。

數(shù)據(jù)同步的工作原理

圖片

DTS可以在兩個數(shù)據(jù)源之間同步正在進(jìn)行的數(shù)據(jù)變更。數(shù)據(jù)同步通常用于OLTP到OLAP的數(shù)據(jù)傳輸。數(shù)據(jù)同步包括以下兩個階段：

• 同步初始化：DTS先開始收集增量數(shù)據(jù)，然后將源數(shù)據(jù)庫的結(jié)構(gòu)和存量數(shù)據(jù)加載到目標(biāo)數(shù)據(jù)庫。
• 數(shù)據(jù)實時同步：DTS同步正在進(jìn)行的數(shù)據(jù)變更，并保持源數(shù)據(jù)庫和目標(biāo)數(shù)據(jù)庫的同步。

DTS Serverless

DTS Serverless實例是數(shù)據(jù)傳輸服務(wù)DTS（Data Transmission Service）提供的資源規(guī)格可以彈性變化的實例。Serverless實例可以適應(yīng)不斷變化的業(yè)務(wù)需求，使實例資源能夠隨業(yè)務(wù)規(guī)模的變化自動調(diào)整，從而避免資源浪費和控制運維成本。

Serverless是一種動態(tài)計費方式，能夠根據(jù)實例負(fù)載情況以分鐘級別的動態(tài)調(diào)整資源，并實時計費（每小時生成一個收費訂單），您僅需要為實際用量付費，從而節(jié)省大量成本。使用Serverless計費方式購買的實例，被稱為Serverless實例。

Serverless實例會根據(jù)RPS（Records Per Second）、CPU、內(nèi)存利用率、網(wǎng)絡(luò)等因素動態(tài)調(diào)整資源規(guī)格，調(diào)整的資源規(guī)格以DU（DTS Unit）數(shù)體現(xiàn)。在DU數(shù)調(diào)整后的60秒，系統(tǒng)會檢測當(dāng)前資源規(guī)格是否滿足負(fù)載需求。

在數(shù)據(jù)傳輸量波動較大的場景下，普通實例和Serverless實例資源使用和規(guī)格變化情況如下圖所示：

圖片

由上圖可以看到，在業(yè)務(wù)波動較大的場景下：

• 普通實例：在波谷期浪費的資源較多，在高峰期資源不足，業(yè)務(wù)受損。
• Serverless實例：實例的資源規(guī)格隨負(fù)載需求動態(tài)調(diào)整，在波谷期和高峰期都能完全滿足業(yè)務(wù)需求，保證業(yè)務(wù)不受損。