背景

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

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

一、Mysql和ES各自的特點(diǎn)

為什么選用Mysql

MySQL 在關(guān)系型數(shù)據(jù)庫歷史上并沒有特別優(yōu)勢的位置，Oracle/DB2/PostgreSQL(Ingres) 三老比 MySQL 開發(fā)早了 20 來年, 但是乘著 2000 年的互聯(lián)網(wǎng)東風(fēng), LAMP 架構(gòu)得到迅速的使用，特別在中國，大部分新興企業(yè)的 IT 系統(tǒng)主數(shù)據(jù)沉淀于 MySQL 中。

核心特點(diǎn)：開源免費(fèi)、高并發(fā)、穩(wěn)定、支持事務(wù)、支持SQL查詢

• 高并發(fā)能力：MySQL 內(nèi)核特征特別適合高并發(fā)簡單 SQL 操作 ，鏈接輕量化(線程模式)，優(yōu)化器、執(zhí)行器、事務(wù)引擎相對簡單粗暴，存儲(chǔ)引擎做得比較細(xì)致

• 穩(wěn)定性好：主數(shù)據(jù)庫最大的要求就是穩(wěn)定、不丟數(shù)據(jù)，MySQL 內(nèi)核特征反倒讓其特點(diǎn)鮮明，從而達(dá)到很好的穩(wěn)定性，主備系統(tǒng)也很早就 ready ,應(yīng)對崩潰情況下的快速切換，innodb 存儲(chǔ)引擎也保障了 MySQL 下盤穩(wěn)定

• 操作便捷：良好、便捷的用戶體驗(yàn)(相比 PostgreSQL) , 讓應(yīng)用開發(fā)者非常容易上手 ,學(xué)習(xí)成本較低

• 開源生態(tài)：MySQL 是一款開源產(chǎn)品，讓上下游廠商圍繞其構(gòu)建工具相對簡單，HA proxy、分庫分表中間件讓其實(shí)用性大大加強(qiáng)，同時(shí)開源的特質(zhì)讓其有大量的用戶

為什么選用 ES

ES 幾個(gè)顯著的特點(diǎn)，能夠有效補(bǔ)足 MySQL 在企業(yè)級數(shù)據(jù)操作場景的缺陷，而這也是我們將其選擇作為下游數(shù)據(jù)源重要原因

核心特點(diǎn)：支持分詞檢索，多維篩選性能好，支持海量數(shù)據(jù)查詢

• 文本搜索能力：ES 是基于倒排索引實(shí)現(xiàn)的搜索系統(tǒng)，配合多樣的分詞器，在文本模糊匹配搜索上表現(xiàn)得比較好，業(yè)務(wù)場景廣泛

• 多維篩選性能好：億級規(guī)模數(shù)據(jù)使用寬表預(yù)構(gòu)建(消除 join)，配合全字段索引，使 ES 在多維篩選能力上具備壓倒性優(yōu)勢，而這個(gè)能力是諸如 CRM, BOSS, MIS 等企業(yè)運(yùn)營系統(tǒng)核心訴求，加上文本搜索能力，獨(dú)此一家

• 開源和商業(yè)并行：ES 開源生態(tài)非?；钴S，具備大量的用戶群體，同時(shí)其背后也有獨(dú)立的商業(yè)公司支撐，而這讓用戶根據(jù)自身特點(diǎn)有了更加多樣、漸進(jìn)的選擇

二、數(shù)據(jù)同步方案

1、同步雙寫

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

• 偽代碼：

/**
 * 新增商品
 */
@Transactional(rollbackFor = Exception.class)
public void addGoods(GoodsDto goodsDto) {
     //1、保存Mysql
     Goods goods = new Goods();
     BeanUtils.copyProperties(goodsDto,goods);
     GoodsMapper.insert();
 
     //2、保存ES
     IndexRequest indexRequest = new IndexRequest("goods_index","_doc");
     indexRequest.source(JSON.toJSONString(goods), XContentType.JSON);
     indexRequest.setRefreshPolicy(WriteRequest.RefreshPolicy.IMMEDIATE);
     highLevelClient.index(indexRequest);
}

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

  • 業(yè)務(wù)邏輯簡單
  • 實(shí)時(shí)性高

• 缺點(diǎn)：

  • 硬編碼，有需要寫入mysql的地方都需要添加寫入ES的代碼；
  • 業(yè)務(wù)強(qiáng)耦合；
  • 存在雙寫失敗丟數(shù)據(jù)風(fēng)險(xiǎn)；
  • 性能較差：本來mysql的性能不是很高，再加一個(gè)ES，系統(tǒng)的性能必然會(huì)下降。

• 附：
  上面說的雙寫失敗風(fēng)險(xiǎn)，包括以下幾種：

  • ES系統(tǒng)不可用；
  • 程序和ES之間的網(wǎng)絡(luò)故障；
  • 程序重啟，導(dǎo)致系統(tǒng)來不及寫入ES等。

針對這種情況，有數(shù)據(jù)強(qiáng)一致性要求的，就必須雙寫放到事務(wù)中來處理，而一旦用上事物，則性能下降更加明顯。

2、異步雙寫（MQ方式）

針對多數(shù)據(jù)源寫入的場景，可以借助MQ實(shí)現(xiàn)異步的多源寫入，這種情況下各個(gè)源的寫入邏輯互不干擾，不會(huì)由于單個(gè)數(shù)據(jù)源寫入異?；蚓徛绊懫渌麛?shù)據(jù)源的寫入，雖然整體寫入的吞吐量增大了，但是由于MQ消費(fèi)是異步消費(fèi)，所以不適合實(shí)時(shí)業(yè)務(wù)場景。

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

  • 性能高
  • 不易出現(xiàn)數(shù)據(jù)丟失問題，主要基于MQ消息的消費(fèi)保障機(jī)制，比如ES宕機(jī)或者寫入失敗，還能重新消費(fèi)MQ消息。
  • 多源寫入之間相互隔離，便于擴(kuò)展更多的數(shù)據(jù)源寫入

• 缺點(diǎn)：

  • 硬編碼問題，接入新的數(shù)據(jù)源需要實(shí)現(xiàn)新的消費(fèi)者代碼
  • 系統(tǒng)復(fù)雜度增加：引入了消息中間件
  • 可能出現(xiàn)延時(shí)問題：MQ是異步消費(fèi)模型，用戶寫入的數(shù)據(jù)不一定可以馬上看到，造成延時(shí)。

3、基于Mysql表定時(shí)掃描同步

上面兩種方案中都存在硬編碼問題，也就是有任何對mysq進(jìn)行增刪改查的地方要么植入ES代碼，要么替換為MQ代碼，代碼的侵入性太強(qiáng)。

如果對實(shí)時(shí)性要求不高的情況下，可以考慮用定時(shí)器來處理，具體步驟如下：

• 數(shù)據(jù)庫的。m字段，任何crud操作都會(huì)導(dǎo)致該字段的時(shí)間發(fā)生變化；
• 原來程序中的CURD操作不做任何變化；
• 增加一個(gè)定時(shí)器程序，讓該程序按一定的時(shí)間周期掃描指定的表，把該時(shí)間段內(nèi)發(fā)生變化的數(shù)據(jù)提取出來；
• 逐條寫入到ES中。

如下圖所示：

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

具體實(shí)現(xiàn)可以參考：通過Logstash實(shí)現(xiàn)mysql數(shù)據(jù)定時(shí)增量同步到ES

• 優(yōu)點(diǎn)：
• 不改變原來代碼，沒有侵入性、沒有硬編碼；
• 沒有業(yè)務(wù)強(qiáng)耦合，不改變原來程序的性能；
• Worker代碼編寫簡單不需要考慮增刪改查；
• 缺點(diǎn)：
• 時(shí)效性較差，由于是采用定時(shí)器根據(jù)固定頻率查詢表來同步數(shù)據(jù)，盡管將同步周期設(shè)置到秒級，也還是會(huì)存在一定時(shí)間的延遲。
• 對數(shù)據(jù)庫有一定的輪詢壓力，一種改進(jìn)方法是將輪詢放到壓力不大的從庫上。

4、基于Binlog實(shí)時(shí)同步

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

當(dāng)然有，可以利用mysql的binlog來進(jìn)行同步。其實(shí)現(xiàn)原理如下：

• 具體步驟如下：

  • 讀取mysql的binlog日志，獲取指定表的日志信息；
  • 將讀取的信息轉(zhuǎn)為MQ；
  • 編寫一個(gè)MQ消費(fèi)程序；
  • 不斷消費(fèi)MQ，每消費(fèi)完一條消息，將消息寫入到ES中。

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

  • 沒有代碼侵入、沒有硬編碼；
  • 原有系統(tǒng)不需要任何變化，沒有感知；
  • 性能高；
  • 業(yè)務(wù)解耦，不需要關(guān)注原來系統(tǒng)的業(yè)務(wù)邏輯。

• 缺點(diǎn)：

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

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

5、業(yè)界目前較為流行的方案：使用canal監(jiān)聽binlog同步數(shù)據(jù)到es

• canal ，譯意為水道/管道/溝渠，主要用途是基于 MySQL 數(shù)據(jù)庫增量日志解析，提供增量數(shù)據(jù)訂閱和消費(fèi)。

  說白了就是，根據(jù)Mysql的binlog日志進(jìn)行增量同步數(shù)據(jù)。要理解canal的原理，就要先了解mysql的主從復(fù)制原理：

  • 所有的create update delete操作都會(huì)進(jìn)入MySQLmaster節(jié)點(diǎn)
  • master節(jié)點(diǎn)會(huì)生成binlog文件，每次操作mysql數(shù)據(jù)庫就會(huì)記錄到binlog文件中
  • slave節(jié)點(diǎn)會(huì)訂閱master節(jié)點(diǎn)的binlog文件，以增量備份的形式同步數(shù)據(jù)到slave數(shù)據(jù)

• 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請求后推送binlog日志給canal服務(wù)端，解析binlog對象（原始為byte流）轉(zhuǎn)成Json格式
  • canal客戶端通過TCP協(xié)議或MQ形式監(jiān)聽canal服務(wù)端，同步數(shù)據(jù)到ES

三、數(shù)據(jù)遷移同步工具選型

數(shù)據(jù)遷移同步工具的選擇比較多樣，下表僅從 MySQL 同步 ES 這個(gè)場景下，對一些筆者深度使用研究過的數(shù)據(jù)同步工具進(jìn)行對比，用戶可以根據(jù)自己的實(shí)際需要選取適合自己的產(chǎn)品。

總結(jié)

本文主要對Mysql和ES進(jìn)行數(shù)據(jù)同步的常見方案進(jìn)行了匯總說明。

• 同步雙寫是最簡單的同步方式，能最大程度保證數(shù)據(jù)同步寫入的實(shí)時(shí)性，最大的問題是代碼侵入性太強(qiáng)。
• 異步雙寫引入了消息中間件，由于MQ都是異步消費(fèi)模型，所以可能出現(xiàn)數(shù)據(jù)同步延遲的問題。好處是在大規(guī)模消息同步時(shí)吞吐量更、高性能更好，便于接入更多的數(shù)據(jù)源，且各個(gè)數(shù)據(jù)源數(shù)據(jù)消費(fèi)寫入相互隔離互不影響。
• 基于Mysql表定時(shí)掃描同步 ，原理是通過定時(shí)器定時(shí)掃描表中的增量數(shù)據(jù)進(jìn)行數(shù)據(jù)同步，不會(huì)產(chǎn)生代碼侵入，但由于是定時(shí)掃描同步，所以也會(huì)存在數(shù)據(jù)同步延遲問題，典型實(shí)現(xiàn)是采用 Logstash 實(shí)現(xiàn)增量同步。
• 基于Binlog實(shí)時(shí)同步 ，原理是通過監(jiān)聽Mysql的binlog日志進(jìn)行增量同步數(shù)據(jù)。不會(huì)產(chǎn)生代碼侵入，數(shù)據(jù)同步的實(shí)時(shí)也能得到保障，弊端是Binlog系統(tǒng)都較為復(fù)雜。典型實(shí)現(xiàn)是采用 canal 實(shí)現(xiàn)數(shù)據(jù)同步。

參考資料

MySQL 數(shù)據(jù)實(shí)時(shí)同步到 Elasticsearch 的技術(shù)方案選型和思考文章來源地址http://www.zghlxwxcb.cn/news/detail-720996.html

到了這里，關(guān)于【技術(shù)選型】Mysql和ES數(shù)據(jù)同步方案匯總的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！