MySQL數(shù)據(jù)同步ES的四種方法！你能想到幾種？

作者：老三 2023-01-13 14:29:00

我們也很容易想到異步雙寫(xiě)的辦法，上架商品的時(shí)候，先把商品數(shù)據(jù)丟進(jìn)MQ，為了解耦合，我們一般會(huì)拆分一個(gè)搜索服務(wù)，由搜索服務(wù)去訂閱商品變動(dòng)的消息，來(lái)完成同步。

本文轉(zhuǎn)載自微信公眾號(hào)「三分惡」，作者老三。轉(zhuǎn)載本文請(qǐng)聯(lián)三分惡公眾號(hào)。

大家好，我是老三，這期給大家分享一個(gè)電商中常見(jiàn)的場(chǎng)景——MySQL數(shù)據(jù)同步Elasticsearch。

商品檢索

大家應(yīng)該都在各種電商網(wǎng)站檢索過(guò)商品，檢索商品一般都是通過(guò)什么實(shí)現(xiàn)呢？搜索引擎Elasticsearch。

那么問(wèn)題來(lái)了，商品上架，數(shù)據(jù)一般寫(xiě)入到MySQL的數(shù)據(jù)庫(kù)中，那么用于檢索的數(shù)據(jù)又是怎么同步到Elasticsearch的呢？

MySQL同步ES

1.同步雙寫(xiě)

這是能想到的最直接的方式，在寫(xiě)入MySQL，直接也同步往ES里寫(xiě)一份數(shù)據(jù)。

同步雙寫(xiě)

對(duì)于這種方式：

優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單
缺點(diǎn)：

業(yè)務(wù)耦合，商品的管理中耦合大量數(shù)據(jù)同步代碼
影響性能，寫(xiě)入兩個(gè)存儲(chǔ)，響應(yīng)時(shí)間變長(zhǎng)
不便擴(kuò)展：搜索可能有一些個(gè)性化需求，需要對(duì)數(shù)據(jù)進(jìn)行聚合，這種方式不便實(shí)現(xiàn)

2.異步雙寫(xiě)

異步雙寫(xiě)

前面說(shuō)的，一些數(shù)據(jù)需要聚合處理成類(lèi)似寬表的結(jié)構(gòu)怎么辦呢？例如商品庫(kù)的商品品類(lèi)、spu、sku表是分開(kāi)的，但是查詢是跨維度的，在ES里再聚合一次效率就低一些，最好就是把商品的數(shù)據(jù)給聚合起來(lái)，在ES里以類(lèi)似大寬表的形式存儲(chǔ)，這樣一來(lái)查詢效率就高一些。

多維度多條件查詢

這種其實(shí)沒(méi)什么好辦法，基本上還是得搜索服務(wù)直接查庫(kù)，或者遠(yuǎn)程調(diào)用，再查詢一遍商品的數(shù)據(jù)庫(kù)，就是所謂的回查。

回查完成聚合

這種方式：

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

解耦合，商品服務(wù)無(wú)需關(guān)注數(shù)據(jù)同步
實(shí)時(shí)性較好，使用MQ，正常情況下，同步完成在秒級(jí)

缺點(diǎn)：
引入了新的組件和服務(wù)，增加了復(fù)雜度

3.定時(shí)任務(wù)

假如我們要快速搞搞，數(shù)據(jù)量有沒(méi)那么大，怎么辦呢？定時(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通過(guò)binlog訂閱實(shí)現(xiàn)主從同步，各路數(shù)據(jù)訂閱框架比如canal就依據(jù)這個(gè)原理，將client組件偽裝成從庫(kù)，來(lái)實(shí)現(xiàn)數(shù)據(jù)訂閱。

MySQL主從同步

我們以應(yīng)用最廣泛的canal為例，canal通過(guò)??canal-adapter??，支持多種適配器，其中就有ES適配器，通過(guò)一些配置，啟動(dòng)之后，就可以直接把MySQL數(shù)據(jù)同步到ES，這個(gè)過(guò)程是零代碼的。

canal同步數(shù)據(jù)

但是，和老板了解過(guò)，使用canal看起來(lái)很美好，幫我們把同步的事情都干了，但其實(shí)，還是要寫(xiě)代碼。為什么呢？

前面提到的多張表數(shù)據(jù)聚合，canal的支持沒(méi)那么好，所以還是得回查。這時(shí)候用canal-adapter就不合適了，需要自己實(shí)現(xiàn)canal-client，監(jiān)聽(tīng)和聚合數(shù)據(jù)，寫(xiě)入ES：

數(shù)據(jù)訂閱+回查

這種看起來(lái)和異步雙寫(xiě)比較像，但是第一降低了商品服務(wù)的耦合，第二數(shù)據(jù)的實(shí)時(shí)性更好。

所以使用數(shù)據(jù)訂閱：

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

業(yè)務(wù)入侵較少
實(shí)時(shí)性較好

至于數(shù)據(jù)訂閱框架的選型，主流的大體上是這些：

	Cancal	Maxwell	Python-Mysql-Rplication
開(kāi)源方	阿里巴巴	Zendesk	社區(qū)
開(kāi)發(fā)語(yǔ)言	Java	Java	Python
活躍度	活躍	活躍	活躍
高可用	支持	支持	不支持
客戶端	Java/Go/PHP/Python/Rust	無(wú)	Python
消息落地	Kafka/RocketMQ 等	Kafka/RabbitNQ/Redis 等	自定義
消息格式	自定義	JSON	自定義
文檔詳略	詳細(xì)	詳細(xì)	詳細(xì)
Boostrap	不支持	支持	不支持