ES 叢集上，業務單點如何優化升級？
摘要: 原創出處 https://www.bysocket.com 「公眾號：泥瓦匠BYSocket 」歡迎關注和轉載，保留摘要，謝謝！
- ES 基礎
- ES 叢集
- ES 叢集上業務優化
一、ES 基礎
ES 的安裝下載，網上一大片，我這邊不在重複。可以看看我以前做的小筆記：
其中 ES 三大要素：
- 文件（Document）
文件，在面向物件觀念就是一個物件。在 ES 裡面，是一個大 JSON 物件，是指定了唯一 ID 的最底層或者根物件。文件的位置由 _index、_type 和 _id 唯一標識。文件元資料：- _index ：文件在哪存放
- _type ： 文件表示的物件類別
- _id ：文件唯一標識
- 索引（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
- hash 函式生成數字，經過取餘演算法得到餘數。餘數就是分片的位置。
- routing 是可變值，支援自定義。預設文件 _id
- number_of_primary_shards 主分片的數量
三、ES 叢集上業務優化
倘若如果剛剛那個例子，一個索引 project , 儲存專案相關的資料。專案的數量級越來越大，億量級，萬億量級。那一個大索引的查詢啥的都會出現瓶頸。這時候該怎麼優化呢？
這時候是不是想到了，一句常說的：空間換時間。
這時候是不是也想到了，MySQL 分庫
所以大索引的拆分，也不是很難。類似分片的路由規則，根據具體業務指定即可。
這裡，我們可以定義 1000 個索引，分別名為 project_1、project_2、project_3…
然後在 ES 叢集上面架一層簡單的 proxy 。裡面核心的業務路由規則可以這樣：
index_id = project_id % 1000
- project_id 專案自增 ID
- index_id 得出來的索引對應的 ID
總結一張圖：
- ES proxy 層：做總索引和真正分索引的對映
- ES 索引配置管理：做索引與業務的對映
- ES 叢集：就是上面講的
參考資料
- https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-index-field.html
以下專題教程也許您會有興趣
- 《Spring Boot 2.x 系列教程》 https://www.bysocket.com/springboot
- 《Java 核心系列教程》 https://www.bysocket.com/archives/2100
（關注微信公眾號，領取 Java 精選乾貨學習資料）
（新增我微信：bysocket01。加入純技術交流群，成