本文轉載自微信公眾號「 三分惡」，作者老三 。轉載本文請聯三分惡公眾號。

大家好，我是老三，這期給大家分享一個電商中常見的場景——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，其實大體上都是類似的幾種方法。

參考：

• [1]. https://www.infoq.cn/article/1afyz3b6hnhprrg12833
• [2].https://www.iamle.com/archives/2900.html
• [3].https://blog.51cto.com/lianghecai/4755693
• [4].https://qinyuanpei.github.io/posts/1333693167/
• [5].https://github.com/alibaba/canal/wiki/ClientAdapter