【前提】

       目前公司訂單資料庫雖然使用了索引、快取、讀寫分離等，由於業務本身複雜以及資料量的不斷上漲，導致查詢出現了瓶頸，海量資料查詢對於APP有時候甚至出現超時現象，不得不對這種情況做出處理。其中可行解決方案比如：分庫分表、使用ElasticSearch檢索、優化索引等，最終組內評定，選擇了通過ElasticSearch來解決這個問題。

【設計思想】

        如圖所示，類似資料庫的讀寫分離，增刪改操作直接操作資料庫，查詢操作，利用ES快速檢索的能力，直接從ElasticSearch中通過DSL語句進行查詢。

        針對於這種情況，我們不需要重構系統，只需要將ES查詢這部分設計成元件，插入到原有的系統當中。其中我們的設計是這樣的：

        1.單獨為ES查詢新建了專案，通過RPC的形式，來請求查詢；

        2.在系統Service層統一通過配置中心設計一組“開關”，防止elasticsearch崩潰時，緊急將底層查詢切換回Mysql資料庫。

【資料同步】

        由上可知，基本的思想是讀寫分離到ES，解決慢查詢問題，那麼mysql的資料是如何同步到elasticsearch中呢？

        binlog + cancel + blukAPI(ElasticSearch)

        從Mysql實時同步到ES，我採取了上述技術棧組合的方案。當然，對於es官方給出的同步策略以及開源出來的同步策略主要包含：
       1.elasticsearch-jdbc | https://github.com/jprante/elasticsearch-jdbc 
       2.elasticsearch-river-MySQL | 

       如上所述的這4種方案，都可以實時地將Mysql資料同步到ES中，在“銘毅天下”大神的部落格中，看到了這4種外掛優劣性的對比：

     上圖來自：https://blog.csdn.net/laoyang360/article/details/51771621

     如上，普遍問題在於不能實現同步刪除功能，恰巧公司資料平臺組同事做了一套支援通過binlog做資料同步的系統，嘗試了一下從mysql到es的實時同步可用，而且增量、全量都可以做，於是乎就採用了這種方式。其中主要用了阿里開源的canal 以及ES中的Bluk API。

      一、Canal

      canal專案目前已經開源：https://github.com/alibaba/canal

      canal原理：

      Mysql理解為圖中Master，Elastic理解為途中slave。主要過程分三步：

     1.master將改變記錄到二進位制日誌(binary log)中（這些記錄叫做二進位制日誌事件，binary log events，可以通過show binlog events進行檢視）；

      2.slave將master的binary log events拷貝到它的中繼日誌(relay log)；

      3.slave重做中繼日誌中的事件，將改變反映它自己的資料。

    二、Bulk API

    The bulk API makes it possible to perform many index/delete operations in a single API call. This can greatly increase the indexing speed.

       關於Bulk API的使用，參考官方：https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html 

【注意點】      

       1.資料同步之前，提前建好Elasticsearch的index、type結構，並設定好分片數量，因為後期分片不可變。

       2.就index中欄位的設計，遵循一個index下對應一個type，因為最新版本的elasticserach會漸漸去掉type的概念。

       3.從Mysql同步到elastic的原理還是基於mysql的binlog，對於訂單查詢條件維度太多，雖然多張表可以合併到一個index中，但

如果是1對多或者多對多關係，不要關聯到一個index裡。

       4.對於列表查詢，目前es 查詢不支援連線，所以關聯查詢要麼用正規化二做冗餘設計表，要麼自應用裡自己做關聯。

      週末愉快
      That's all.