Elasticsearch 7.x 之節點、叢集、分片及副本

Elasticsearch是一個基於Lucene的搜尋伺服器。它提供了一個分散式多使用者能力的全文搜尋引擎，基於RESTful web介面。Elasticsearch是用Java語言開發的，並作為Apache許可條款下的開放原始碼釋出，是一種流行的企業級搜尋引擎。

Elasticsearch 分散式特性包括如下幾個點：

什麼是高可用？CAP 定理是分散式系統的基礎，也是分散式系統的 3 個指標：

Consistency（一致性）

Availability（可用性）

Partition tolerance（分割槽容錯性）

那高可用（High Availability）是什麼？高可用，簡稱 HA，是系統一種特徵或者指標，通常是指，提供一定效能上的服務執行時間，高於平均正常時間段。反之，消除系統服務不可用的時間。

衡量系統是否滿足高可用，就是當一臺或者多臺伺服器當機的時候，系統整體和服務依然正常可用。舉個例子，一些知名的網站保證 4 個 9 以上的可用性，也就是可用性超過 99.99%。那 0.01% 就是所謂故障時間的百分比。

Elasticsearch 在高可用性上，體現如下兩點：

服務可用性：允許部分節點停止服務，整體服務沒有影響

資料可用性：允許部分節點丟失，最終不會丟失資料

隨著公司業務發展，Elasticsearch 也面臨兩個挑戰：

搜尋資料量從百萬到億量級

搜尋請求 QPS 也猛增

那麼需要將原來節點和增量資料重新從 10 個節點分佈到 100 個節點。Elasticsearch 可以橫向擴充套件至數百（甚至數千）的伺服器節點，同時可以處理PB級資料。Elasticsearch 為了可擴充套件性而生，由小規模叢集增長為大規模叢集的過程幾乎完全自動化，這是水平擴充套件的體現。

上面透過可擴充套件性，可以看出 Elasticsearch 分散式的好處明顯：

儲存可以水平擴容，水平空間換時間

部分節點停止服務，整個叢集服務不受影響，照樣正常提供服務

Elasticsearch 在後臺自動完成了分散式相關工作，如下：

自動分配文件到不同分片或者多節點上

均衡分配分片到叢集節點上，index 和 search 操作時進行負載均衡

複製每個分片，支援資料冗餘，防止硬體故障資料丟失

叢集擴容時，無縫整合新節點，並且重新分配分片

Elasticsearch 叢集知識點如下：

不同叢集透過名字區分，預設叢集名稱為 “elasticsearch”

叢集名 cluster name ，可以透過配置檔案修改或者 行 -E cluster.name=user-es-cluster 進行設定一個叢集由多個節點組成

Elasticsearch 叢集有多個節點組成，形成分散式叢集。那麼，什麼是節點呢？

節點（Node），就是一個 Elasticsearch 應用例項。大家都知道 Elasticsearch 原始碼是 Java 寫的，那麼節點就是一個 Java 程式。

所以類似 Spring 應用一樣，一臺伺服器或者本機可以執行多個節點，只要對應的埠不同即可。但生產伺服器中，一般一臺伺服器執行一個 Elasticsearch 節點。還有需要注意：

Elasticsearch 都會有 name ，透過 -E node.name=node01 指定或者配置檔案中配置

每個節點啟動成功，都會分配對應得一個 UID ，儲存在 data 目錄

可以透過  _cluster/health 檢視叢集的健康狀態，如下：

Green 主分片與副本分片都正常

Yellow 主分片正常，副本分片不正常

Red 有主分片不正常，可能某個分片容量超過了磁碟大小等

如圖，有主（Master）節點和其他節點。那麼節點有多少型別呢？

Elasticsearch 被啟動後，預設就是 Master-eligible Node。然後透過參與選主過程，可以成為 Master Node。具體選主原理，後續單獨寫一篇文章。Master Node 有什麼作用呢？

Master Node 負責同步叢集狀態資訊：

所有節點資訊

所有索引即其 Mapping 和 Setting 資訊

所有分片路由資訊

只能 Master 節點可以修改資訊，是因為這樣就能保證資料得一致性

Data Node，又稱資料節點。用於儲存資料，其在資料擴充套件上起至關重要的作用。

Coordinating Node，是負責接收任何 Client 的請求，包括 REST Client 等。該節點將請求分發到合適的節點，最終把結果彙集到一起。一般來說，每個節點預設起到了 Coordinating Node 的職責。

還有其他節點型別，雖然不常見，但需要知道：

Hot & Warm Node：不同硬體配置的 Data Node，用來實現冷熱資料節點架構，降低運維部署的成本

Machine Learning Node：負責機器學習的節點

Tribe Node：負責連線不同的叢集。支援跨叢集搜尋 Cross Cluster Search

一般在開發環境中，設定單一的角色節點：

master node：透過 node.master 配置，預設 true

data node：透過 node.data 配置，預設 true

ingest node：透過 node.ingest 配置，預設 true

coordinating node：預設每個節點都是 coordinating 節點，設定其他型別全部為 false。

machine learning：透過 node.ml 配置，預設 true，需要透過 x-pack 開啟。

同樣看這個圖，3 個節點分別為 Node1、Node2、Node3。並且 Node3 上面有一個主分片 P0 和一個副本 R2。那什麼是主分片呢？

主分片，用來解決資料水平擴充套件的問題。比如上圖這個解決可以將資料分佈到所有節點上：

節點上可以有主分片，也可以沒有主分片

主分片在索引建立的時候確定，後續不允許修改。除非 Reindex 操作進行修改

副本，用來備份資料，提高資料的高可用性。副本分片是主分片的複製

副本分片數，可以動態調整

增加副本數，可以一定程度上提高服務讀取的吞吐和可用性

如何檢視 Elasticsearch 叢集的分片配置呢？可以從 settings 從看出：

number_of_shards 主分片數
number_of_replicas 副本分片數
{
  "my_index": {
    "settings": {
      "index": {
        "number_of_shards": "8",
        "number_of_replicas": "1"
      }
    }
  }
}

實戰建議：對生產環境中，分片設定很重要，需要最好容量評估與規劃

根據資料容量評估分配數，設定過小，後續無法水平擴充套件；單分片資料量太大，也容易導致資料分片耗時嚴重

分片數設定如果太大，會導致資源浪費，效能降低；同時也會影響搜尋結果打分和搜尋準確性

索引評估，每個索引下面的單分片數不用太大。如何評估呢？比如這個索引 100 G 資料量，那設定 10 個分片，平均每個分片資料量就是 10G 。每個分片 10 G 資料量這麼大，耗時肯定嚴重。所以根據評估的資料量合理安排分片數即可。如果需要調整主分片數，那麼需要進行 reindex 等遷索引操作。

比如知道了搜尋效能場景，例如多少資料量，多大的寫入，是寫為主還是查詢為主等等，才可以確定：

磁碟，推薦 SSD，JVM最大 Xmx 不要超過30G。副本分片至少設定為1。主分片，單個儲存不要超過 30 GB，按照這個你推算出分片數，進行設定。

叢集中磁碟快滿的時候，你再增加機器，確實可能導致新建的索引全部分配到新節點上去的可能性。最終導致資料分配不均。所以要記得監控叢集，到70%就需要考慮刪除資料或是增加節點可以設定最大分片數緩解這個問題。

分片的尺寸如果過大，確實也沒有快速恢復的辦法，所以儘量保證分片的size在40G以下。

原文地址：