上周聽到公司同事分享 MySQL 同步資料到 ES 的方案，發現很有意思，感覺有必要將這塊知識點再總結提煉一下，就有了這篇文章，
本文會先講述資料同步的 4 種方案，并給出常用資料遷移工具，干貨滿滿！
不 BB，上文章目錄：
1. 前言
在實際專案開發中，我們經常將 MySQL 作為業務資料庫，ES 作為查詢資料庫，用來實作讀寫分離，緩解 MySQL 資料庫的查詢壓力，應對海量資料的復雜查詢，
這其中有一個很重要的問題，就是如何實作 MySQL 資料庫和 ES 的資料同步，今天和大家聊聊 MySQL 和 ES 資料同步的各種方案，
我們先看看下面 4 種常用的資料同步方案，
2. 資料同步方案
2.1 同步雙寫
這是一種最為簡單的方式，在將資料寫到 MySQL 時，同時將資料寫到 ES，
優點：
-
業務邏輯簡單； -
實時性高，
缺點：
-
硬編碼，有需要寫入 MySQL 的地方都需要添加寫入 ES 的代碼； -
業務強耦合； -
存在雙寫失敗丟資料風險； -
性能較差，本來 MySQL 的性能不是很高，再加一個 ES，系統的性能必然會下降，
2.2 異步雙寫
針對多資料源寫入的場景，可以借助 MQ 實作異步的多源寫入，
優點：
-
性能高； -
不易出現資料丟失問題，主要基于 MQ 訊息的消費保障機制，比如 ES 宕機或者寫入失敗，還能重新消費 MQ 訊息； -
多源寫入之間相互隔離，便于擴展更多的資料源寫入，
缺點：
-
硬編碼問題，接入新的資料源需要實作新的消費者代碼； -
系統復雜度增加，引入了訊息中間件； -
MQ是異步消費模型，用戶寫入的資料不一定可以馬上看到，造成延時，
2.3 基于 SQL 抽取
上面兩種方案中都存在硬編碼問題，代碼的侵入性太強，如果對實時性要求不高的情況下，可以考慮用定時器來處理：
-
資料庫的相關表中增加一個欄位為 timestamp 的欄位，任何 CURD 操作都會導致該欄位的時間發生變化； -
原來程式中的 CURD 操作不做任何變化； -
增加一個定時器程式，讓該程式按一定的時間周期掃描指定的表，把該時間段內發生變化的資料提取出來； -
逐條寫入到 ES 中，
優點：
-
不改變原來代碼，沒有侵入性、沒有硬編碼； -
沒有業務強耦合，不改變原來程式的性能； -
Worker 代碼撰寫簡單不需要考慮增刪改查，
缺點：
-
時效性較差，由于是采用定時器根據固定頻率查詢表來同步資料，盡管將同步周期設定到秒級，也還是會存在一定時間的延遲； -
對資料庫有一定的輪詢壓力，一種改進方法是將輪詢放到壓力不大的從庫上，
經典方案：借助 Logstash 實作資料同步，其底層實作原理就是根據配置定期使用 SQL 查詢新增的資料寫入 ES 中，實作資料的增量同步，
2.4 基于 Binlog 實時同步
上面三種方案要么有代碼侵入，要么有硬編碼，要么有延遲，那么有沒有一種方案既能保證資料同步的實時性又沒有代入侵入呢？
當然有，可以利用 MySQL 的 Binlog 來進行同步，
具體步驟如下：
-
讀取 MySQL 的 Binlog 日志，獲取指定表的日志資訊； -
將讀取的資訊轉為 MQ； -
撰寫一個 MQ 消費程式； -
不斷消費 MQ，每消費完一條訊息，將訊息寫入到 ES 中，
優點：
-
沒有代碼侵入、沒有硬編碼； -
原有系統不需要任何變化，沒有感知； -
性能高； -
業務解耦，不需要關注原來系統的業務邏輯，
缺點：
-
構建 Binlog 系統復雜； -
如果采用 MQ 消費決議的 Binlog 資訊，也會像方案二一樣存在 MQ 延時的風險，
3. 資料遷移工具選型
對于上面 4 種資料同步方案，“基于 Binlog 實時同步”方案是目前最常用的，也誕生了很多優秀的資料遷移工具，這里主要對這些遷移工具進行介紹，
這些資料遷移工具，很多都是基于 Binlog 訂閱的方式實作，模擬一個 MySQL Slave 訂閱 Binlog 日志，從而實作 CDC（Change Data Capture），將已提交的更改發送到下游，包括 INSERT、DELETE、UPDATE，
至于如何偽裝？大家需要先了解 MySQL 的主從復制原理，需要學習這塊知識的同學，可以看我之前寫的高并發教程，里面有詳細講解，
3.1 Cannel
基于資料庫增量日志決議，提供增量資料訂閱&消費，目前主要支持 MySQL，
Canal 原理就是偽裝成 MySQL 的從節點，從而訂閱 master 節點的 Binlog 日志，主要流程為：
-
Canal 服務端向 MySQL 的 master 節點傳輸 dump 協議； -
MySQL 的 master 節點接收到 dump 請求后推送 Binlog 日志給 Canal 服務端，決議 Binlog 物件（原始為 byte 流）轉成 Json 格式； -
Canal 客戶端通過 TCP 協議或 MQ 形式監聽 Canal 服務端，同步資料到 ES，
下面是 Cannel 執行的核心流程，其中 Binlog Parser 主要負責 Binlog 的提取、決議和推送，EventSink 負責資料的過濾 、路由和加工，僅作了解即可，
3.2 阿里云 DTS
資料傳輸服務 DTS（Data Transmission Service）支持 RDBMS、NoSQL、OLAP 等多種資料源之間的資料傳輸，
它提供了資料遷移、實時資料訂閱及資料實時同步等多種資料傳輸方式，相對于第三方資料流工具，DTS 提供豐富多樣、高性能、高安全可靠的傳輸鏈路，同時它提供了諸多便利功能，極大方便了傳輸鏈路的創建及管理，
特點：
-
多資料源：支持 RDBMS、NoSQL、OLAP 等多種資料源間的資料傳輸； -
多傳輸方式：支持多種傳輸方式，包括資料遷移、實時資料訂閱及資料實時同步； -
高性能：底層采用了多種性能優化措施，全量資料遷移高峰期時性能可以達到70MB/s，20萬的TPS，使用高規格服務器來保證每條遷移或同步鏈路都能擁有良好的傳輸性能； -
高可用：底層為服務集群，如果集群內任何一個節點宕機或發生故障，控制中心都能夠將這個節點上的所有任務快速切換到其他節點上，鏈路穩定性高； -
簡單易用：提供可視化管理界面，提供向導式的鏈路創建流程，用戶可以在其控制臺簡單輕松地創建傳輸鏈路； -
需要付費，
再看看 DTS 的系統架構，
-
高可用：資料傳輸服務內部每個模塊都有主備架構，保證系統高可用，容災系統實時檢測每個節點的健康狀況，一旦發現某個節點例外，會將鏈路快速切換到其他節點， -
資料源地址動態適配：對于資料訂閱及同步鏈路，容災系統還會監測資料源的連接地址切換等變更操作，一旦發現資料源發生連接地址變更，它會動態適配資料源新的連接方式，在資料源變更的情況下，保證鏈路的穩定性，
更多內容，請查看阿里官方檔案：https://help.aliyun.com/product/26590.html
3.3 Databus
Databus 是一個低延遲、可靠的、支持事務的、保持一致性的資料變更抓取系統，由 LinkedIn 于 2013 年開源，
Databus 通過挖掘資料庫日志的方式，將資料庫變更實時、可靠的從資料庫拉取出來，業務可以通過定制化 client 實時獲取變更并進行其他業務邏輯，
特點：
-
多資料源：Databus 支持多種資料來源的變更抓取，包括 Oracle 和 MySQL， -
可擴展、高度可用：Databus 能擴展到支持數千消費者和事務資料來源，同時保持高度可用性， -
事務按序提交：Databus 能保持來源資料庫中的事務完整性，并按照事務分組和來源的提交順尋交付變更事件， -
低延遲、支持多種訂閱機制：資料源變更完成后，Databus 能在毫秒級內將事務提交給消費者，同時，消費者使用D atabus 中的服務器端過濾功能，可以只獲取自己需要的特定資料， -
無限回溯：對消費者支持無限回溯能力，例如當消費者需要產生資料的完整拷貝時，它不會對資料庫產生任何額外負擔，當消費者的資料大大落后于來源資料庫時，也可以使用該功能，
再看看 Databus 的系統架構，
Databus 由 Relays、bootstrap 服務和 Client lib 等組成，Bootstrap 服務中包括 Bootstrap Producer 和 Bootstrap Server，
-
快速變化的消費者直接從 Relay 中取事件； -
如果一個消費者的資料更新大幅落后，它要的資料就不在 Relay 的日志中，而是需要請求 Bootstrap 服務，回傳的將會是自消費者上次處理變更之后的所有資料變更快照，
開源地址：https://github.com/linkedin/databus
3.4 其它
Flink
-
有界資料流和無界資料流上進行有狀態計算分布式處理引擎和框架， -
官網地址：https://flink.apache.org
CloudCanal
-
資料同步遷移系統，商業產品， -
官網地址：https://www.clougence.com/?utm_source=wwek
Maxwell
-
使用簡單，直接將資料變更輸出為json字串，不需要再撰寫客戶端， -
官網地址：http://maxwells-daemon.io
DRD
-
阿里巴巴集團自主研發的分布式資料庫中間件產品，專注于解決單機關系型資料庫擴展性問題，具備輕量(無狀態)、靈活、穩定、高效等特性， -
官方地址：https://www.aliyun.com/product/drds
yugong
-
幫助用戶完成從 Oracle 資料遷移到 MySQL， -
訪問地址：https://github.com/alibaba/yugong
4. 后記
通過這篇文章，讓你知道 MySQL 和其它多維資料的同步方案，以及常用的資料遷移工具，幫助你更好選型，
作者|樓仔
本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Four-data-synchronization-schemes-to-Elasticsearch.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/554244.html
標籤：MySQL
上一篇：大白話講解資料庫的三級模式及二級映像（所謂的內外模式在生活中到底是什么東西?）
下一篇：返回列表