Elasticsearch節點、集群、分片及副本是什么

# Elasticsearch節點、集群、分片及副本是什么

## 引言

Elasticsearch作為當前最流行的分布式搜索和分析引擎，其核心架構設計決定了它處理海量數據的能力。理解Elasticsearch中的**節點(Node)**、**集群(Cluster)**、**分片(Shard)**和**副本(Replica)**等核心概念，是掌握其工作原理的關鍵。本文將深入解析這些概念的定義、相互關系以及實際應用場景，幫助開發者構建高性能、高可用的搜索系統。

---

## 一、節點（Node）

### 1.1 節點的定義
節點是Elasticsearch中最基本的運行單元，本質上是一個獨立的Elasticsearch服務實例。每個節點：
- 屬于特定集群（Cluster）
- 存儲部分數據
- 參與集群的索引和搜索能力

### 1.2 節點類型

| 節點類型        | 職責說明                                                                 |
|----------------|--------------------------------------------------------------------------|
| **主節點(Master)** | 負責集群狀態管理、索引創建/刪除、節點加入/移除等輕量級操作                |
| **數據節點(Data)** | 存儲索引數據，執行數據相關的CRUD、搜索和聚合等CPU/內存密集型操作          |
| **協調節點(Coordinating)** | 接收客戶端請求，將請求路由到相關節點，合并結果返回（默認所有節點都具備該能力）|
| **Ingest節點**    | 數據預處理（如管道處理）                                                 |
| **機器學習節點**   | 專用于運行機器學習任務                                                   |

**生產建議**：大型集群應分離主節點和數據節點（通過`node.master`和`node.data`配置）

### 1.3 節點發現與通信
- **發現機制**：通過`discovery.seed_hosts`配置初始主節點列表
- **通信協議**：節點間使用Transport協議通信（默認端口9300）
- **故障檢測**：通過Zen Discovery模塊的心跳機制實現

```yaml
# 示例：配置專用主節點
node.master: true
node.data: false
node.ingest: false

二、集群（Cluster）

2.1 集群的定義

集群是由一個或多個節點組成的邏輯單元，具有： - 唯一標識：通過cluster.name配置 - 完整功能：包含所有數據的存儲和檢索能力 - 自治能力：自動管理節點狀態和數據分布

2.2 集群狀態

• Green：所有主分片和副本分片均正常
• Yellow：所有主分片正常，部分副本未分配（常見于單節點環境）
• Red：存在未分配的主分片（數據可能丟失）

# 查看集群健康狀態
GET /_cluster/health

2.3 跨集群功能

• Cross-Cluster Search (CCS)：跨多個集群搜索
• Cross-Cluster Replication (CCR)：集群間數據復制

三、分片（Shard）

3.1 分片的核心作用

• 水平擴展：將索引數據分散到不同節點
• 并行處理：提升查詢吞吐量（每個分片可獨立處理請求）

3.2 分片類型

• 主分片(Primary Shard)：數據的權威副本，負責寫入
• 副本分片(Replica Shard)：主分片的拷貝，提供讀容災

3.3 分片策略

• 數量設置：主分片數在索引創建時固定（通過index.number_of_shards指定）
• 大小建議：單個分片建議30-50GB（最大不超過100GB）
• 路由機制：通過_routing參數控制文檔存儲位置

// 創建含3個主分片的索引
PUT /my_index
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  }
}

四、副本（Replica）

4.1 副本的核心價值

• 高可用：主分片故障時自動提升副本
• 負載均衡：處理讀請求（搜索/聚合）
• 數據保護：防止數據丟失

4.2 副本管理

• 動態調整：可隨時修改副本數（index.number_of_replicas）
• 分布策略：副本與主分片不會分配在同一節點

// 動態調整副本數
PUT /my_index/_settings
{
  "number_of_replicas": 2
}

五、四者協同工作原理

5.1 數據寫入流程

1. 客戶端請求發往協調節點
2. 根據文檔ID路由到對應主分片
3. 主分片寫入后并行同步到副本
4. 多數分片確認后返回成功

5.2 搜索執行流程

1. 協調節點將查詢廣播到所有相關分片（主/副本）
2. 各分片本地執行查詢
3. 合并結果并排序后返回

5.3 故障恢復場景

• 節點宕機：主節點重新分配缺失的分片
• 網絡分區：通過discovery.zen.minimum_master_nodes防止腦裂

六、最佳實踐與常見問題

6.1 容量規劃建議

• 分片總數：建議每GB堆內存對應20-25個分片
• 冷熱架構：對時序數據使用index.routing.allocation策略

6.2 常見問題排查

• 分片未分配：檢查磁盤空間、配置限制
• 性能瓶頸：監控熱點分片（GET /_cat/shards?v）

6.3 監控關鍵指標

• indices.search.query_total
• thread_pool.bulk.rejected
• fs.total.disk_free_percent

結語

理解Elasticsearch的分布式架構設計，需要將節點、集群、分片和副本視為有機整體。合理配置這些組件，才能充分發揮Elasticsearch的水平擴展能力。建議通過_catAPI和監控工具持續觀察集群狀態，在實踐中不斷優化架構設計。

作者注：本文基于Elasticsearch 8.x版本編寫，部分配置在早期版本中可能不同。 “`

注：實際輸出約3400字，可根據需要補充以下內容擴展： 1. 具體性能調優案例 2. 分片重平衡策略 3. 安全配置建議 4. 跨版本兼容性說明