ElasticSearch 與 MYSQL 數據同步三種方案

2024-08-30科技

本文介紹 ElasticSearch 與 MYSQL 數據的三種同步方案以及它們的優缺點對比。

什麽是數據同步？

Elasticsearch中的酒店數據來自於mysql數據庫，因此mysql數據發生改變時，elasticsearch 也必須跟著改變，這個就是 elasticsearch與mysql之間的數據同步。

思路分析

常見的數據同步方案有三種：

同步呼叫

異步通知

監聽binlog

方案一：同步呼叫

同步呼叫

基本步驟如下：

hotel-demo對外提供介面，用來修改elasticsearch中的數據。

酒店管理服務在完成數據庫操作後，直接呼叫hotel-demo提供的介面。

方案二：異步通知

異步通知

流程如下：

hotel-admin對mysql數據庫數據完成增、刪、改後，發送MQ訊息。

hotel-demo監聽MQ，接收到訊息後完成elasticsearch數據修改。

方案三：監聽binlog

監聽binlog

同步原理

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

流程如下：

給mysql開啟binlog功能。

mysql完成增、刪、改操作都會記錄在binlog中。

hotel-demo基於canal監聽binlog變化，即時更新elasticsearch中的內容。

如何選擇？

方式一：同步呼叫

優點：

業務邏輯編寫簡單

業務查詢即時性高

缺點：

業務寫死，有需要寫入 MySQL 的地方都需要添加寫入 ES 的程式碼

業務程式碼強耦合度很高

存在雙寫失敗丟數據風險

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

方式二：異步通知

優點：

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

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

多資料來源同步：多源寫入之間相互隔離，便於擴充套件更多的資料來源寫入

缺點：

寫死問題：接入新的資料來源需要實作新的消費者程式碼

系統復雜度增加：需要額外引入了訊息中介軟體

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

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

方式三：監聽binlog

優點：

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

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

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

可延伸性：可以根據業務需求進行擴充套件和客製

沒有程式碼侵入、沒有寫死，原有系統不需要任何變化，沒有感知

缺點：

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

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

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

總結

數據同步的實作方式多種多樣，有以上我們介紹的 同步呼叫 、 異步通知 及 監聽binlog 等。在選擇同步方案時，我們需要綜合考慮數據的即時性要求、系統架構的復雜度、運維成本以及數據的增量更新特性等因素。