ES 集群上，業務單點如何優化公升級？

一、es 基礎

spring boot 2.0 m7 整合 es 5 、kibana 和 x-pack

其中 es 三大要素：

索引（index）

索引，用於區分文件成組，即分到一組的文件集合。索引，用於儲存文件和使文件可被搜尋。比如專案索引命名為 project ，交易索引命名為 trade 等。

型別（type）

型別，用於區分索引中的文件，即在索引中對資料邏輯分割槽。比如設計專案分為 ui 、 ux 這些型別。可以放在該類目進行區分。但一般操作，很少用到這麼複雜的。

可見， _index 索引的重要性。避免某個索引儲存不相關的資料。

二、es 集群

es 集群搭建，文章很多。我這邊也不一一枚舉了。先看 es 集群分布式圖

集群（cluster）

跟伺服器集群類似，多個 elasticsearch 執行例項（節點 node）的組合體是 elasticsearch 集群。

elasticsearch 是天然分布式的，可以通過水平擴容為集群新增更多節點。

elasticsearch 集群是去中心化的，只有乙個主節點（master）。而且主節點是動態選舉，因此不會出現單點故障。

那節點是什麼？

節點（node）

上面說過，乙個 elasticsearch 執行例項就是節點。任何節點都可以被選舉成為主節點。主節點負責集群內所以變更，比如文件的增加、刪除等。所以集群不會因為主節點流量的增大成為瓶頸。因為任何節點都會成為主節點。

如圖，p1 p2 p0 是節點內的主分片，其他 r 是副分片。

那分片是什麼？

分片（shard）

分片，是 es 節點中最小的工作單元。分片僅儲存全部資料的一部分。分片包括主分片和副分片，主分片是副分片的拷貝。主分片和副分片基本沒有大的區別。

如果是全文搜尋，會查詢到每個分片，然後將每個分片的結果進行全域性地收集，並處理返回。

舉個例子：比如新建了乙個索引 project , 儲存專案相關的資料。那具體的某個 project a 的資料會被切分，儲存在不同的分片上。那麼根據 project a 的 _id 如何路由到具體的分片上呢？

分片的路由公式是這樣的：

shard = hash(routing) % number_of_primary_shards

三、es 集群上業務優化

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

這時候是不是想到了，一句常說的：空間換時間。

這時候是不是也想到了，mysql 分庫

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

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

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

index_id = project_id % 1000

總結一張圖：