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

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

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

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

同步方案

1. 同步雙寫

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

圖片

目標

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

實現方式

直接同步

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

使用中間件

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

觸發器與存儲過程

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

優缺點

• 優點

業務邏輯編寫簡單

業務查詢實時性高

• 缺點

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

業務代碼強耦合度很高

存在雙寫失敗丟數據風險

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

應用場景

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

2. 異步雙寫

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

圖片

優缺點

• 優點

提高系統可用性：即使備庫出現問題，也不會影響主庫的正常運行和數據寫入

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

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

• 缺點

硬編碼問題：接入新的數據源需要實現新的消費者代碼

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

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

數據一致性風險：由于存在異步處理的時間差，可能會出現主庫和備庫之間數據暫時不一致的情況。因此，需要采取適當的措施來確保數據的最終一致性。

應用場景

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

3. Logstash同步

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

圖片

優缺點

• 優點

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

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

• 缺點

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

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

無法實現同步刪除，需要在Elasticsearch中執行相關命令手動刪除

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

4. Binlog 實時同步

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

圖片

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

同步原理

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

優缺點

• 優點

實時性：能夠實時捕獲和同步數據庫的變更數據

一致性：確保源數據庫和目標數據庫之間數據的一致性

靈活性：支持多種數據庫和存儲系統之間的同步

可擴展性：可以根據業務需求進行擴展和定制

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

• 缺點

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

在高并發場景下，Binlog的寫入和同步可能會對數據庫性能產生一定影響

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

5. Canal數據同步

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

同步原理

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

圖片

同步流程

1. Canal 服務端向 MySQL 的 master 節點傳輸 dump 協議
2. MySQL 的 master 節點接收到 dump 請求后推送 binlog 日志給 Canal 服務端，解析 binlog 對象（原始為byte流）轉成 Json 格式
3. Canal 客戶端通過 TCP 協議或 MQ 形式監聽 Canal 服務端，同步數據到ES

執行核心流程

圖片

• canal模擬mysql slave的交互協議，偽裝自己為mysql slave，向mysql master發送dump協議
• mysql master收到dump請求，開始推送binary log給slave(也就是canal)
• canal解析binary log對象(原始為byte流)

5. 阿里云 DTS

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

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

系統架構

圖片

架構特性

系統高可用數據傳輸服務內部每個模塊都有主備架構，保證系統高可用。容災系統實時檢測每個節點的健康狀況，一旦發現某個節點異常，會將鏈路快速切換到其他節點。

數據源地址動態適配對于數據訂閱及同步鏈路，容災系統還會監測數據源的連接地址切換等變更操作，一旦發現數據源發生連接地址變更，它會動態適配數據源新的連接方式，在數據源變更的情況下，保證鏈路的穩定性。

數據同步的工作原理

圖片

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

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

DTS Serverless

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

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

Serverless實例會根據RPS（Records Per Second）、CPU、內存利用率、網絡等因素動態調整資源規格，調整的資源規格以DU（DTS Unit）數體現。在DU數調整后的60秒，系統會檢測當前資源規格是否滿足負載需求。

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

圖片

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

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