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：

##資料訂閱回查

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

所以使用資料訂閱：

• 優點：

• #業務入侵較少
  ######即時性較好###

至於資料訂閱框架的選型，主流的大致上是這些：

#Zendesk社群#開發語言#Java##Python活躍度活躍活躍活躍 高可用#支持支援不支援客戶端Java/Go/PHP/Python/Rust無Python#訊息落地Kafka/RocketMQ 等Kafka/RabbitNQ/Redis 等自訂訊息格式自訂JSON自訂文件詳略詳細詳細

	Cancal	Maxwell	Python-Mysql-Rplication
#開源方	阿巴巴
##Java

#詳細說明

#########Boostrap#####不支援######################## ##支援######不支援###############MySQL同步到其他資料存儲，如HBase，基本上都是採用相似的幾種方法。 ###

以上是MySQL資料同步Elasticsearch的方案有哪些的詳細內容。更多資訊請關注PHP中文網其他相關文章！