這是一個或許對你有用的社群
《專案實戰(影片)》:從書中學,往事上“練” 《網際網路高頻面試題》:面朝簡歷學習,春暖花開 《架構 x 系統設計》:摧枯拉朽,掌控面試高頻場景題 《精進 Java 學習指南》:系統學習,網際網路主流技術棧 《必讀 Java 原始碼專欄》:知其然,知其所以然
這是一個或許對你有用的開源專案
國產 Star 破 10w+ 的開源專案,前端包括管理後臺 + 微信小程式,後端支援單體和微服務架構。功能涵蓋 RBAC 許可權、SaaS 多租戶、資料許可權、商城、支付、工作流、大屏報表、微信公眾號、ERP、CRM、AI 大模型等等功能:
Boot 多模組架構:https://gitee.com/zhijiantianya/ruoyi-vue-pro Cloud 微服務架構:https://gitee.com/zhijiantianya/yudao-cloud 影片教程:https://doc.iocoder.cn 【國內首批】支援 JDK 17/21 + SpringBoot 3.3、JDK 8/11 + Spring Boot 2.7 雙版本
概述
在實際的專案開發與運維過程中,MySQL 常常扮演著業務資料庫的核心角色,以其強大的事務處理能力和資料完整性保障,支撐著系統的穩定執行。然而,隨著資料量的急劇增長和查詢複雜度的不斷提升,單一依賴 MySQL 進行高效的資料檢索顯得日益吃力,尤其是在面對海量資料的複雜查詢場景時,效能瓶頸愈發凸顯。
為了有效緩解這一挑戰,我們通常採用讀寫分離的策略,將 Elasticsearch(簡稱 ES)引入作為專門的查詢資料庫。ES 以其卓越的搜尋效能、靈活的資料模式以及強大的可擴充套件性,成為處理複雜查詢需求的理想選擇。透過 ES,我們可以實現資料的快速檢索與分析,從而大幅提升使用者體驗和系統響應速度。
在這一過程中,確保 MySQL 資料庫與 ES 之間的資料同步成為了至關重要的一環。資料同步不僅關乎資料的即時性和準確性,更是保障系統穩定性和使用者體驗的基石。因此,我們需要精心設計與實施一套高效、可靠的資料同步方案。
具體而言,資料同步的實現方式多種多樣,包括但不限於使用 Logstash、Kafka Connect、Debezium 等工具進行即時資料捕獲與傳輸,或透過定時任務(如 Cron Job)結合 SQL 查詢與批次匯入的方式實現資料的定期同步。在選擇同步方案時,我們需要綜合考慮資料的即時性要求、系統架構的複雜度、運維成本以及資料的增量更新特性等因素。
基於 Spring Boot + MyBatis Plus + Vue & Element 實現的後臺管理系統 + 使用者小程式,支援 RBAC 動態許可權、多租戶、資料許可權、工作流、三方登入、支付、簡訊、商城等功能
專案地址:https://github.com/YunaiV/ruoyi-vue-pro 影片教程:https://doc.iocoder.cn/video/
同步方案
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即時同步是一種資料庫同步技術,主要用於即時捕獲並同步資料庫中的變更資料。
免翻官方ChatGPT 4.0 和 Claude Pro,穩定有售後

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的方式實現資料即時同步,在不影響源資料庫的情況下,同步延遲可降至毫秒級別。

同步流程
-
Canal 服務端向 MySQL 的 master 節點傳輸 dump 協議 -
MySQL 的 master 節點接收到 dump 請求後推送 binlog 日誌給 Canal 服務端,解析 binlog 物件(原始為byte流)轉成 Json 格式 -
Canal 客戶端透過 TCP 協議或 MQ 形式監聽 Canal 服務端,同步資料到ES
執行核心流程

-
canal模擬mysql slave的互動協議,偽裝自己為mysql slave,向mysql master傳送dump協議 -
mysql master收到dump請求,開始推送binary log給slave(也就是canal) -
canal解析binary log物件(原始為byte流)
6. 阿里雲 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例項:例項的資源規格隨負載需求動態調整,在波谷期和高峰期都能完全滿足業務需求,保證業務不受損。
歡迎加入我的知識星球,全面提升技術能力。

星球的內容包括:專案實戰、面試招聘、原始碼解析、學習路線。





文章有幫助的話,在看,轉發吧。
謝謝支援喲 (*^__^*)