概述

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

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

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

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

同步方案

1. 同步雙寫

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

圖片

目標

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

實現(xiàn)方式

直接同步

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

使用中間件

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

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

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

優(yōu)缺點

• 優(yōu)點

業(yè)務邏輯編寫簡單

業(yè)務查詢實時性高

• 缺點

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

業(yè)務代碼強耦合度很高

存在雙寫失敗丟數(shù)據(jù)風險

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

應用場景

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

2. 異步雙寫

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

圖片

優(yōu)缺點

• 優(yōu)點

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

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

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

• 缺點

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

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

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

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

應用場景

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

3. Logstash同步

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

圖片

優(yōu)缺點

• 優(yōu)點

不改變原代碼，沒有侵入性、沒有硬編碼

沒有業(yè)務強耦合，不改變原來程序的性能

• 缺點

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

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

無法實現(xiàn)同步刪除，需要在Elasticsearch中執(zhí)行相關命令手動刪除

Elasticsearch中的_id字段必須與MySQL中的id字段相同

4. Binlog 實時同步

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

圖片

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

同步原理

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

優(yōu)缺點

• 優(yōu)點

實時性：能夠實時捕獲和同步數(shù)據(jù)庫的變更數(shù)據(jù)

一致性：確保源數(shù)據(jù)庫和目標數(shù)據(jù)庫之間數(shù)據(jù)的一致性

靈活性：支持多種數(shù)據(jù)庫和存儲系統(tǒng)之間的同步

可擴展性：可以根據(jù)業(yè)務需求進行擴展和定制

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

• 缺點

配置和維護同步工具可能具有一定的復雜性

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

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

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

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

同步原理

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

圖片

同步流程

1. Canal 服務端向 MySQL 的 master 節(jié)點傳輸 dump 協(xié)議
2. MySQL 的 master 節(jié)點接收到 dump 請求后推送 binlog 日志給 Canal 服務端，解析 binlog 對象（原始為byte流）轉成 Json 格式
3. Canal 客戶端通過 TCP 協(xié)議或 MQ 形式監(jiān)聽 Canal 服務端，同步數(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ù)傳輸服務DTS（Data Transmission Service）是阿里云提供的實時數(shù)據(jù)流服務，支持關系型數(shù)據(jù)庫（RDBMS）、非關系型的數(shù)據(jù)庫（NoSQL）、數(shù)據(jù)多維分析（OLAP）等數(shù)據(jù)源間的數(shù)據(jù)交互，集數(shù)據(jù)同步、遷移、訂閱、集成、加工于一體，助您構建安全、可擴展、高可用的數(shù)據(jù)架構。

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

系統(tǒng)架構

圖片

架構特性

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

數(shù)據(jù)源地址動態(tài)適配對于數(shù)據(jù)訂閱及同步鏈路，容災系統(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ù)源之間同步正在進行的數(shù)據(jù)變更。數(shù)據(jù)同步通常用于OLTP到OLAP的數(shù)據(jù)傳輸。數(shù)據(jù)同步包括以下兩個階段：

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

DTS Serverless

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

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

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

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

圖片

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

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