這是泥瓦匠（bysocket.com）的第27篇精華分享
ES （ElasticSearch）是分布式搜索引擎。引擎太晦澀，其實類似一個 MySQL ，一個存儲。方便提供下面功能：
- 近實時搜索
- 全文檢索，結構化搜索，統計分析
那么存儲在 ES 數據哪里來？
答案是數據同步。方式推薦如下：
-
數據傳輸(Data Transmission)是阿里雲提供的一種支持RDBMS(關系型數據庫)、NoSQL、OLAP等多種數據源之間數據交互的數據服務。【阿里的】
https://help.aliyun.com/product/26590.html -
有贊億級訂單同步的探索與實踐【小弟我呆的小組搞的】
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 集群
冷熱分離；也是類似的就是中間狀態的數據最熱獨立集群獨立索引。定期從里面刪除終態數據。那么這個索引數據量少，支持搜搜查詢量賊大。何樂而不為。
- 完 -
