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

商品檢索

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

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

MySQL同步ES

1.同步雙寫

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

同步雙寫

對于這種方式：

優點：實現簡單

缺點：

業務耦合，商品的管理中耦合大量數據同步代碼

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

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

2.異步雙寫

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

異步雙寫

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

多維度多條件查詢

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

回查完成聚合

這種方式：

優點：

解耦合，商品服務無需關注數據同步

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

缺點：

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

3.定時任務

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

定時任務

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

這種方式：

優點：實現比較簡單

缺點：

實時性難以保證

對存儲壓力較大

4.數據訂閱

還有一種方式，就是最時興的數據訂閱。

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

MySQL主從同步

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

canal同步數據

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

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

數據訂閱+回查

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

所以使用數據訂閱：

優點：

業務入侵較少

實時性較好

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

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

審核編輯：劉清