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
等。在選擇同步方案時,我們需要綜合考慮數據的即時性要求、系統架構的復雜度、運維成本以及數據的增量更新特性等因素。