MySQL 實戰 4 種將數據同步到ES方案

文章目錄

1. 前言
2. 數據同步方案
- 2.1 同步雙寫
- 2.2 異步雙寫
- 2.3 定時更新
- 2.4 基于 Binlog 實時同步
3. 數據遷移工具選型
- 3.1 Canal
- 3.2 阿里云 DTS
- 3.3 Databus
- 3.4 Databus和Canal對比
- 3.4 其它
4. 后記

上周聽到公司新同事分享 MySQL 同步數據到 ES 的方案，發現很有意思，感覺有必要將這塊知識點再總結提煉一下，就有了這篇文章。

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 定時更新

上面兩種方案中都存在硬編碼問題，代碼的侵入性太強，如果對實時性要求不高的情況下，可以考慮用定時器來處理：

數據庫的相關表中增加一個字段為 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。

3.1 Canal

基于數據庫增量日志解析，提供增量數據訂閱&消費，目前主要支持 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