建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號(hào)「 三分惡」，作者老三 。轉(zhuǎn)載本文請(qǐng)聯(lián)三分惡公眾號(hào)。
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對(duì)這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡(jiǎn)單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：空間域名、虛擬主機(jī)、營(yíng)銷軟件、網(wǎng)站建設(shè)、潛山網(wǎng)站維護(hù)、網(wǎng)站推廣。
大家好，我是老三，這期給大家分享一個(gè)電商中常見的場(chǎng)景——MySQL數(shù)據(jù)同步Elasticsearch。
商品檢索
大家應(yīng)該都在各種電商網(wǎng)站檢索過商品，檢索商品一般都是通過什么實(shí)現(xiàn)呢？搜索引擎Elasticsearch。
那么問題來了，商品上架，數(shù)據(jù)一般寫入到MySQL的數(shù)據(jù)庫中，那么用于檢索的數(shù)據(jù)又是怎么同步到Elasticsearch的呢？
MySQL同步ES
1.同步雙寫
這是能想到的最直接的方式，在寫入MySQL，直接也同步往ES里寫一份數(shù)據(jù)。
同步雙寫
對(duì)于這種方式：
- 優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單
- 缺點(diǎn)：
- 業(yè)務(wù)耦合，商品的管理中耦合大量數(shù)據(jù)同步代碼
- 影響性能，寫入兩個(gè)存儲(chǔ)，響應(yīng)時(shí)間變長(zhǎng)
- 不便擴(kuò)展：搜索可能有一些個(gè)性化需求，需要對(duì)數(shù)據(jù)進(jìn)行聚合，這種方式不便實(shí)現(xiàn)
2.異步雙寫
我們也很容易想到異步雙寫的辦法，上架商品的時(shí)候，先把商品數(shù)據(jù)丟進(jìn)MQ，為了解耦合，我們一般會(huì)拆分一個(gè)搜索服務(wù)，由搜索服務(wù)去訂閱商品變動(dòng)的消息，來完成同步。
異步雙寫
前面說的，一些數(shù)據(jù)需要聚合處理成類似寬表的結(jié)構(gòu)怎么辦呢？例如商品庫的商品品類、spu、sku表是分開的，但是查詢是跨維度的，在ES里再聚合一次效率就低一些，最好就是把商品的數(shù)據(jù)給聚合起來，在ES里以類似大寬表的形式存儲(chǔ)，這樣一來查詢效率就高一些。
多維度多條件查詢
這種其實(shí)沒什么好辦法，基本上還是得搜索服務(wù)直接查庫，或者遠(yuǎn)程調(diào)用，再查詢一遍商品的數(shù)據(jù)庫，就是所謂的回查。
回查完成聚合
這種方式：
- 優(yōu)點(diǎn)：
- 解耦合，商品服務(wù)無需關(guān)注數(shù)據(jù)同步
- 實(shí)時(shí)性較好，使用MQ，正常情況下，同步完成在秒級(jí)
- 缺點(diǎn)：
- 引入了新的組件和服務(wù)，增加了復(fù)雜度
3.定時(shí)任務(wù)
假如我們要快速搞搞，數(shù)據(jù)量有沒那么大，怎么辦呢？定時(shí)任務(wù)也可以。
定時(shí)任務(wù)
定時(shí)任務(wù)，最麻煩的一點(diǎn)是頻率不好選，頻率高的話，會(huì)非自然地形成業(yè)務(wù)的波峰，導(dǎo)致存儲(chǔ)的CPU、內(nèi)存占用波峰式上升，頻率低的話實(shí)時(shí)性比較差，而且也有波峰的情況。
這種方式：
- 優(yōu)點(diǎn)：實(shí)現(xiàn)比較簡(jiǎn)單
- 缺點(diǎn)：
- 實(shí)時(shí)性難以保證
- 對(duì)存儲(chǔ)壓力較大
4.數(shù)據(jù)訂閱
還有一種方式，就是最時(shí)興的數(shù)據(jù)訂閱。
MySQL通過binlog訂閱實(shí)現(xiàn)主從同步，各路數(shù)據(jù)訂閱框架比如canal就依據(jù)這個(gè)原理，將client組件偽裝成從庫，來實(shí)現(xiàn)數(shù)據(jù)訂閱。
MySQL主從同步
我們以應(yīng)用最廣泛的canal為例，canal通過??canal-adapter??，支持多種適配器，其中就有ES適配器，通過一些配置，啟動(dòng)之后，就可以直接把MySQL數(shù)據(jù)同步到ES，這個(gè)過程是零代碼的。
canal同步數(shù)據(jù)
但是，和老板了解過，使用canal看起來很美好，幫我們把同步的事情都干了，但其實(shí)，還是要寫代碼。為什么呢？
前面提到的多張表數(shù)據(jù)聚合，canal的支持沒那么好，所以還是得回查。這時(shí)候用canal-adapter就不合適了，需要自己實(shí)現(xiàn)canal-client，監(jiān)聽和聚合數(shù)據(jù)，寫入ES：
數(shù)據(jù)訂閱+回查
這種看起來和異步雙寫比較像，但是第一降低了商品服務(wù)的耦合，第二數(shù)據(jù)的實(shí)時(shí)性更好。
所以使用數(shù)據(jù)訂閱：
- 優(yōu)點(diǎn)：
- 業(yè)務(wù)入侵較少
- 實(shí)時(shí)性較好
至于數(shù)據(jù)訂閱框架的選型，主流的大體上是這些：
|
Cancal |
Maxwell |
Python-Mysql-Rplication | |
|
開源方 |
阿里巴巴 |
Zendesk |
社區(qū) |
|
開發(fā)語言 |
Java |
Java |
Python |
|
活躍度 |
活躍 |
活躍 |
活躍 |
|
高可用 |
支持 |
支持 |
不支持 |
|
客戶端 |
Java/Go/PHP/Python/Rust |
無 |
Python |
|
消息落地 |
Kafka/RocketMQ 等 |
Kafka/RabbitNQ/Redis 等 |
自定義 |
|
消息格式 |
自定義 |
JSON |
自定義 |
|
文檔詳略 |
詳細(xì) |
詳細(xì) |
詳細(xì) |
|
Boostrap |
不支持 |
支持 |
不支持 |
除了MySQL同步ES，MySQL同步到其它的數(shù)據(jù)存儲(chǔ)，例如HBase，其實(shí)大體上都是類似的幾種方法。
參考：
- [1]. https://www.infoq.cn/article/1afyz3b6hnhprrg12833
- [2].https://www.iamle.com/archives/2900.html
- [3].https://blog./lianghecai/4755693
- [4].https://qinyuanpei.github.io/posts/1333693167/
- [5].https://github.com/alibaba/canal/wiki/ClientAdapter
網(wǎng)站題目：MySQL數(shù)據(jù)同步ES的四種方法！你能想到幾種？
分享路徑：http://www.dlmjj.cn/article/djspdip.html
