今天給大家分享一個電商中常見的場景——MySQL數(shù)據(jù)如何同步Elasticsearch。

商品檢索

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

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

MySQL同步ES

1.同步雙寫

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

同步雙寫

對于這種方式：

優(yōu)點：實現(xiàn)簡單

缺點：

業(yè)務耦合，商品的管理中耦合大量數(shù)據(jù)同步代碼

影響性能，寫入兩個存儲，響應時間變長

不便擴展：搜索可能有一些個性化需求，需要對數(shù)據(jù)進行聚合，這種方式不便實現(xiàn)

2.異步雙寫

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

異步雙寫

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

多維度多條件查詢

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

回查完成聚合

這種方式：

優(yōu)點：

解耦合，商品服務無需關(guān)注數(shù)據(jù)同步

實時性較好，使用MQ，正常情況下，同步完成在秒級

缺點：

引入了新的組件和服務，增加了復雜度

3.定時任務

假如我們要快速搞搞，數(shù)據(jù)量有沒那么大，怎么辦呢？定時任務也可以。

定時任務

定時任務，最麻煩的一點是頻率不好選，頻率高的話，會非自然地形成業(yè)務的波峰，導致存儲的CPU、內(nèi)存占用波峰式上升，頻率低的話實時性比較差，而且也有波峰的情況。

這種方式：

優(yōu)點：實現(xiàn)比較簡單

缺點：

實時性難以保證

對存儲壓力較大

4.數(shù)據(jù)訂閱

還有一種方式，就是最時興的數(shù)據(jù)訂閱。

MySQL通過binlog訂閱實現(xiàn)主從同步，各路數(shù)據(jù)訂閱框架比如canal就依據(jù)這個原理，將client組件偽裝成從庫，來實現(xiàn)數(shù)據(jù)訂閱。

MySQL主從同步

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

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

但是，和老板了解過，使用canal看起來很美好，幫我們把同步的事情都干了，但其實，還是要寫代碼。為什么呢？

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

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

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

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

優(yōu)點：

業(yè)務入侵較少

實時性較好

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

除了MySQL同步ES，MySQL同步到其它的數(shù)據(jù)存儲，例如HBase，其實大體上都是類似的幾種方法。

審核編輯：劉清