這是泥瓦匠（bysocket.com）的第27篇精華分享

ES （ElasticSearch）是分散式搜尋引擎。引擎太晦澀，其實類似一個 MySQL ，一個儲存。方便提供下面功能：

• 近實時搜尋
• 全文檢索，結構化搜尋，統計分析

那麼儲存在 ES 資料哪裡來？

答案是資料同步。方式推薦如下：

1. 資料傳輸(Data Transmission)是阿里雲提供的一種支援RDBMS(關係型資料庫)、NoSQL、OLAP等多種資料來源之間資料互動的資料服務。【阿里的】
   https://help.aliyun.com/product/26590.html

2. 有贊億級訂單同步的探索與實踐【小弟我呆的小組搞的】
   https://mp.weixin.qq.com/s/33KACMxXkgzZyIL9m6q4YA

迴歸到 ES 演進

一、小流量階段

當時在創業公司，同步每次都是全量的，然後凌晨任務跑一下即可。或者直接同步往 ES CRUD 資料。

單機偽叢集，也可以跑。具體全文檢索思路：

• 基於「短語匹配」並設定最小匹配權重值
• 哪來的短語，利用 IK 分詞器分詞
• 基於 Fiter 實現篩選
• 基於 Pageable 實現分頁排序

具體看我係列 ES 部落格和 GitHub。

二、流量慢慢大了

這個量級預估是 百萬 / 千萬資料同步和查詢。

就不能單機偽叢集了，運維層面能解決這個量：

• 多個 ElasticSearch 執行例項（節點 Node）的組合體是 ElasticSearch 叢集
• 通過水平擴容為叢集新增更多節點

如何水平擴容

主分片在索引建立已經確定。讀操作可以同時被主分片和副分片處理。因此，更多的分片，會擁有更高的吞吐量。自然，需要增加更多的硬體資源支援吞吐量。說明，這裡無法提高效能，因為每個分片獲得的資源會變少。動態調整副本分片數，按需伸縮叢集，比如把副本數預設值為 1 增加到 2：

PUT /blogs/_settings
{
"number_of_replicas" : 2
}

基本一個叢集 Cluster 含著各個業務搜搜：訂單、商品等

三、突然訂單流量暴增了

突然發現一個問題：

• A 叢集裡面的大索引慢查會影響 A 叢集的其他小索引。

比如現在同一個 訂單 索引大了，慢查。影響了其他業務。那不應該呀，咋辦？

答案是：物理隔離為多叢集：

• 分為很多叢集：叢集訂單、叢集商品等隔離
• 多機房支援

往往這時候問題由來了：業務單點如何優化升級？

一個索引 project , 儲存專案相關的資料。專案的數量級越來越大，億量級，萬億量級。那一個大索引的查詢啥的都會出現瓶頸。這時候該怎麼優化呢？

解決方案：冷熱分離；拆分

大索引的拆分，也不是很難。類似分片的路由規則，根據具體業務指定即可。

這裡，我們可以定義 1000 個索引，分別名為 project_1、project_2、project_3…

然後在 ES 叢集上面架一層簡單的 proxy 。裡面核心的業務路由規則可以這樣：

project_id 專案自增 ID
index_id 得出來的索引對應的 ID

index_id = project_id % 1000

• ES proxy 層：做總索引和真正分索引的對映
• ES 索引配置管理：做索引與業務的對映
• ES 叢集

冷熱分離；也是類似的就是中間狀態的資料最熱獨立叢集獨立索引。定期從裡面刪除終態資料。那麼這個索引資料量少，支援搜搜查詢量賊大。何樂而不為。

• 完 -