快捷導(dǎo)航

4種MySQL數(shù)據(jù)同步ES方案詳解

更新時(shí)間：2023年10月11日 15:17:55 作者：鶴沖天Pro

這篇文章主要給大家分享介紹了關(guān)于4種MySQL數(shù)據(jù)同步ES方案的相關(guān)資料,MySQL是一種常用的關(guān)系型數(shù)據(jù)庫(kù),而Elasticsearch是一種為搜索和分析而設(shè)計(jì)的分布式全文搜索引擎,需要的朋友可以參考下

1. 前言

在實(shí)際項(xiàng)目開發(fā)中，我們經(jīng)常將 MySQL 作為業(yè)務(wù)數(shù)據(jù)庫(kù)，ES 作為查詢數(shù)據(jù)庫(kù)，用來(lái)實(shí)現(xiàn)讀寫分離，緩解 MySQL 數(shù)據(jù)庫(kù)的查詢壓力，應(yīng)對(duì)海量數(shù)據(jù)的復(fù)雜查詢。

這其中有一個(gè)很重要的問(wèn)題，就是如何實(shí)現(xiàn) MySQL 數(shù)據(jù)庫(kù)和 ES 的數(shù)據(jù)同步，今天和大家聊聊 MySQL 和 ES 數(shù)據(jù)同步的各種方案。

我們先看看下面 4 種常用的數(shù)據(jù)同步方案。

2. 數(shù)據(jù)同步方案

2.1 同步雙寫

這是一種最為簡(jiǎn)單的方式，在將數(shù)據(jù)寫到 MySQL 時(shí)，同時(shí)將數(shù)據(jù)寫到 ES。

優(yōu)點(diǎn)：

業(yè)務(wù)邏輯簡(jiǎn)單；

實(shí)時(shí)性高。

缺點(diǎn)：

硬編碼，有需要寫入 MySQL 的地方都需要添加寫入 ES 的代碼；

業(yè)務(wù)強(qiáng)耦合；

存在雙寫失敗丟數(shù)據(jù)風(fēng)險(xiǎn)；

性能較差，本來(lái) MySQL 的性能不是很高，再加一個(gè) ES，系統(tǒng)的性能必然會(huì)下降。

2.2 異步雙寫

針對(duì)多數(shù)據(jù)源寫入的場(chǎng)景，可以借助 MQ 實(shí)現(xiàn)異步的多源寫入。

優(yōu)點(diǎn)：

性能高；

不易出現(xiàn)數(shù)據(jù)丟失問(wèn)題，主要基于 MQ 消息的消費(fèi)保障機(jī)制，比如 ES 宕機(jī)或者寫入失敗，還能重新消費(fèi) MQ 消息；

多源寫入之間相互隔離，便于擴(kuò)展更多的數(shù)據(jù)源寫入。

缺點(diǎn)：

硬編碼問(wèn)題，接入新的數(shù)據(jù)源需要實(shí)現(xiàn)新的消費(fèi)者代碼；

系統(tǒng)復(fù)雜度增加，引入了消息中間件；

MQ是異步消費(fèi)模型，用戶寫入的數(shù)據(jù)不一定可以馬上看到，造成延時(shí)。

2.3 基于 SQL 抽取

上面兩種方案中都存在硬編碼問(wèn)題，代碼的侵入性太強(qiáng)，如果對(duì)實(shí)時(shí)性要求不高的情況下，可以考慮用定時(shí)器來(lái)處理：

數(shù)據(jù)庫(kù)的相關(guān)表中增加一個(gè)字段為 timestamp 的字段，任何 CURD 操作都會(huì)導(dǎo)致該字段的時(shí)間發(fā)生變化；

原來(lái)程序中的 CURD 操作不做任何變化；

增加一個(gè)定時(shí)器程序，讓該程序按一定的時(shí)間周期掃描指定的表，把該時(shí)間段內(nèi)發(fā)生變化的數(shù)據(jù)提取出來(lái)；

逐條寫入到 ES 中。

優(yōu)點(diǎn)：

不改變?cè)瓉?lái)代碼，沒(méi)有侵入性、沒(méi)有硬編碼；

沒(méi)有業(yè)務(wù)強(qiáng)耦合，不改變?cè)瓉?lái)程序的性能；

Worker 代碼編寫簡(jiǎn)單不需要考慮增刪改查。

缺點(diǎn)：

時(shí)效性較差，由于是采用定時(shí)器根據(jù)固定頻率查詢表來(lái)同步數(shù)據(jù)，盡管將同步周期設(shè)置到秒級(jí)，也還是會(huì)存在一定時(shí)間的延遲；

對(duì)數(shù)據(jù)庫(kù)有一定的輪詢壓力，一種改進(jìn)方法是將輪詢放到壓力不大的從庫(kù)上。

經(jīng)典方案：借助 Logstash 實(shí)現(xiàn)數(shù)據(jù)同步，其底層實(shí)現(xiàn)原理就是根據(jù)配置定期使用 SQL 查詢新增的數(shù)據(jù)寫入 ES 中，實(shí)現(xiàn)數(shù)據(jù)的增量同步。

2.4 基于 Binlog 實(shí)時(shí)同步

上面三種方案要么有代碼侵入，要么有硬編碼，要么有延遲，那么有沒(méi)有一種方案既能保證數(shù)據(jù)同步的實(shí)時(shí)性又沒(méi)有代入侵入呢？

當(dāng)然有，可以利用 MySQL 的 Binlog 來(lái)進(jìn)行同步。

具體步驟如下：

讀取 MySQL 的 Binlog 日志，獲取指定表的日志信息；

將讀取的信息轉(zhuǎn)為 MQ；

編寫一個(gè) MQ 消費(fèi)程序；

不斷消費(fèi) MQ，每消費(fèi)完一條消息，將消息寫入到 ES 中。

優(yōu)點(diǎn)：

沒(méi)有代碼侵入、沒(méi)有硬編碼；

原有系統(tǒng)不需要任何變化，沒(méi)有感知；

性能高；

業(yè)務(wù)解耦，不需要關(guān)注原來(lái)系統(tǒng)的業(yè)務(wù)邏輯。

缺點(diǎn)：

構(gòu)建 Binlog 系統(tǒng)復(fù)雜；

如果采用 MQ 消費(fèi)解析的 Binlog 信息，也會(huì)像方案二一樣存在 MQ 延時(shí)的風(fēng)險(xiǎn)。

3. 數(shù)據(jù)遷移工具選型

對(duì)于上面 4 種數(shù)據(jù)同步方案，“基于 Binlog 實(shí)時(shí)同步”方案是目前最常用的，也誕生了很多優(yōu)秀的數(shù)據(jù)遷移工具，這里主要對(duì)這些遷移工具進(jìn)行介紹。

這些數(shù)據(jù)遷移工具，很多都是基于 Binlog 訂閱的方式實(shí)現(xiàn)，模擬一個(gè) MySQL Slave 訂閱 Binlog 日志，從而實(shí)現(xiàn) CDC（Change Data Capture），將已提交的更改發(fā)送到下游，包括 INSERT、DELETE、UPDATE。

至于如何偽裝？大家需要先了解 MySQL 的主從復(fù)制原理，需要學(xué)習(xí)這塊知識(shí)的同學(xué)，可以看我之前寫的高并發(fā)教程，里面有詳細(xì)講解。

3.1 Cannel

基于數(shù)據(jù)庫(kù)增量日志解析，提供增量數(shù)據(jù)訂閱&消費(fèi)，目前主要支持 MySQL。

Canal 原理就是偽裝成 MySQL 的從節(jié)點(diǎn)，從而訂閱 master 節(jié)點(diǎn)的 Binlog 日志，主要流程為：

Canal 服務(wù)端向 MySQL 的 master 節(jié)點(diǎn)傳輸 dump 協(xié)議；

MySQL 的 master 節(jié)點(diǎn)接收到 dump 請(qǐng)求后推送 Binlog 日志給 Canal 服務(wù)端，解析 Binlog 對(duì)象（原始為 byte 流）轉(zhuǎn)成 Json 格式；Canal 客戶端通過(guò) TCP 協(xié)議或 MQ 形式監(jiān)聽 Canal 服務(wù)端，同步數(shù)據(jù)到 ES。

下面是 Cannel 執(zhí)行的核心流程，其中 Binlog Parser 主要負(fù)責(zé) Binlog 的提取、解析和推送，EventSink 負(fù)責(zé)數(shù)據(jù)的過(guò)濾、路由和加工，僅作了解即可。

3.2 阿里云 DTS

數(shù)據(jù)傳輸服務(wù) DTS（Data Transmission Service）支持 RDBMS、NoSQL、OLAP 等多種數(shù)據(jù)源之間的數(shù)據(jù)傳輸。

它提供了數(shù)據(jù)遷移、實(shí)時(shí)數(shù)據(jù)訂閱及數(shù)據(jù)實(shí)時(shí)同步等多種數(shù)據(jù)傳輸方式。相對(duì)于第三方數(shù)據(jù)流工具，DTS 提供豐富多樣、高性能、高安全可靠的傳輸鏈路，同時(shí)它提供了諸多便利功能，極大方便了傳輸鏈路的創(chuàng)建及管理。

特點(diǎn)：

多數(shù)據(jù)源：支持 RDBMS、NoSQL、OLAP 等多種數(shù)據(jù)源間的數(shù)據(jù)傳輸；

多傳輸方式：支持多種傳輸方式，包括數(shù)據(jù)遷移、實(shí)時(shí)數(shù)據(jù)訂閱及數(shù)據(jù)實(shí)時(shí)同步；

高性能：底層采用了多種性能優(yōu)化措施，全量數(shù)據(jù)遷移高峰期時(shí)性能可以達(dá)到70MB/s，20萬(wàn)的TPS，使用高規(guī)格服務(wù)器來(lái)保證每條遷移或同步鏈路都能擁有良好的傳輸性能；

高可用：底層為服務(wù)集群，如果集群內(nèi)任何一個(gè)節(jié)點(diǎn)宕機(jī)或發(fā)生故障，控制中心都能夠?qū)⑦@個(gè)節(jié)點(diǎn)上的所有任務(wù)快速切換到其他節(jié)點(diǎn)上，鏈路穩(wěn)定性高；

簡(jiǎn)單易用：提供可視化管理界面，提供向?qū)降逆溌穭?chuàng)建流程，用戶可以在其控制臺(tái)簡(jiǎn)單輕松地創(chuàng)建傳輸鏈路；
需要付費(fèi)。

再看看 DTS 的系統(tǒng)架構(gòu)。

高可用：數(shù)據(jù)傳輸服務(wù)內(nèi)部每個(gè)模塊都有主備架構(gòu)，保證系統(tǒng)高可用。容災(zāi)系統(tǒng)實(shí)時(shí)檢測(cè)每個(gè)節(jié)點(diǎn)的健康狀況，一旦發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)異常，會(huì)將鏈路快速切換到其他節(jié)點(diǎn)。

數(shù)據(jù)源地址動(dòng)態(tài)適配：對(duì)于數(shù)據(jù)訂閱及同步鏈路，容災(zāi)系統(tǒng)還會(huì)監(jiān)測(cè)數(shù)據(jù)源的連接地址切換等變更操作，一旦發(fā)現(xiàn)數(shù)據(jù)源發(fā)生連接地址變更，它會(huì)動(dòng)態(tài)適配數(shù)據(jù)源新的連接方式，在數(shù)據(jù)源變更的情況下，保證鏈路的穩(wěn)定性。

更多內(nèi)容，請(qǐng)查看阿里官方文檔：https://help.aliyun.com/product/26590.html

3.3 Databus

Databus 是一個(gè)低延遲、可靠的、支持事務(wù)的、保持一致性的數(shù)據(jù)變更抓取系統(tǒng)。由 LinkedIn 于 2013 年開源。

Databus 通過(guò)挖掘數(shù)據(jù)庫(kù)日志的方式，將數(shù)據(jù)庫(kù)變更實(shí)時(shí)、可靠的從數(shù)據(jù)庫(kù)拉取出來(lái)，業(yè)務(wù)可以通過(guò)定制化 client 實(shí)時(shí)獲取變更并進(jìn)行其他業(yè)務(wù)邏輯。

特點(diǎn)：

多數(shù)據(jù)源：Databus 支持多種數(shù)據(jù)來(lái)源的變更抓取，包括 Oracle 和 MySQL。

可擴(kuò)展、高度可用：Databus 能擴(kuò)展到支持?jǐn)?shù)千消費(fèi)者和事務(wù)數(shù)據(jù)來(lái)源，同時(shí)保持高度可用性。

事務(wù)按序提交：Databus 能保持來(lái)源數(shù)據(jù)庫(kù)中的事務(wù)完整性，并按照事務(wù)分組和來(lái)源的提交順尋交付變更事件。

低延遲、支持多種訂閱機(jī)制：數(shù)據(jù)源變更完成后，Databus 能在毫秒級(jí)內(nèi)將事務(wù)提交給消費(fèi)者。同時(shí)，消費(fèi)者使用D atabus 中的服務(wù)器端過(guò)濾功能，可以只獲取自己需要的特定數(shù)據(jù)。

無(wú)限回溯：對(duì)消費(fèi)者支持無(wú)限回溯能力，例如當(dāng)消費(fèi)者需要產(chǎn)生數(shù)據(jù)的完整拷貝時(shí)，它不會(huì)對(duì)數(shù)據(jù)庫(kù)產(chǎn)生任何額外負(fù)擔(dān)。當(dāng)消費(fèi)者的數(shù)據(jù)大大落后于來(lái)源數(shù)據(jù)庫(kù)時(shí)，也可以使用該功能。

再看看 Databus 的系統(tǒng)架構(gòu)。

Databus 由 Relays、bootstrap 服務(wù)和 Client lib 等組成，Bootstrap 服務(wù)中包括 Bootstrap Producer 和 Bootstrap Server。