我來分享：MySQL數據同步ES方案選型解析

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

搜索引擎 Elasticsearch。

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

MySQL同步ES

一、同步雙寫

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

優點：

實現簡單缺點：

業務耦合，商品的管理中耦合大量數據同步代碼影響性能，寫入兩個存儲，響應時間變長不便擴展，搜索可能有一些個性化需求，需要對數據進行聚合，這種方式不便實現二、異步雙寫

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

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

多維度多條件查詢

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

回查完成聚合

優點：

解耦合，商品服務無需關注數據同步實時性較好，使用MQ，正常情況下，同步完成在秒級缺點：

引入了新的組件和服務，增加了復雜度三、定時任務

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

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

優點：

實現比較簡單缺點：

實時性難以保證對存儲壓力較大四、數據訂閱

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

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

MySQL主從同步

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

canal同步數據

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

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

數據訂閱+回查

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

優點：

業務入侵較少實時性較好至于數據訂閱框架的選型，主流的大體上是這些：

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

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈