商品上架，資料一般寫入到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，其實大體上都是類似的幾種方法。