公號：碼農充電站pro
主頁：https://codeshellme.github.io
1，常見的集羣部署方式
ES 有以下不同類型的節點：
- Master(eligible)節點：只有 Master eligible 節點可以成爲 Master 節點。
- Master 節點用於維護索引信息和集羣狀態。
- Data 節點：負責數據存儲。
- Ingest 節點：數據預處理。
- Coordinating 節點：處理用戶請求。
- ML 節點：機器學習相關功能。
在開發環境中，一個節點可以承擔多種角色。
但是在生產環境，建議一個節點只負責單一角色，以達到高可用性及高性能。同時根據業務需求和硬件資源來合理分配節點。
1.1，節點配置參數
在默認情況下，一個節點會同時扮演 Master eligible Node，Data Node 和 Ingest Node。
各類型的節點配置參數如下：
| 節點類型 | 配置參數 | 默認值 |
|---|---|---|
| Master eligible | node.master | true |
| Data Node | node.data | true |
| Ingest Node | node.ingest | true |
| Coordinating | 無 | - |
| ML | node.ml | true（需要 enable x-pack） |
默認情況下，每個節點都是一個 Coordinating 節點，可以將 node.master，node.data 和 node.ingest 同時設置爲 false，讓一個節點只負責 Coordinating 節點的角色。
1.2，配置單一角色
默認情況下，一個節點會承擔多個角色，可以通過配置讓一個節點只負責單一角色。
單一職責節點配置：
- Master 節點：從高可用和避免腦裂的角度考慮，生產環境可配置 3 個 Master節點。
- node.master：
true - node.ingest：
false - node.data：
false
- node.master：
- Data 節點
- node.master：
false - node.ingest：
false - node.data：
true
- node.master：
- Ingest 節點
- node.master：
false - node.ingest：
true - node.data：
false
- node.master：
- Coordinating 節點
- node.master：
false - node.ingest：
false - node.data：
false
- node.master：
1.3，水平擴展架構
集羣的水平擴展：
- 當需要更多的磁盤容量和讀寫能力時，可以增加 Data Node；
- 當系統有大量的複雜查詢和聚合分析時，可以增加 Coordinating Node。
1.4，讀寫分離架構
使用 Ingest 節點對數據預處理。
2，分片設計與管理
ES 中的文檔存儲在索引中，索引的最小存儲單位是分片，不同的索引存儲在不同的分片中。
當討論分片時，一般是基於某個索引的，不同索引之間的分片互不干擾。
分片分爲主分片和副本分片兩種；副本分片是主分片的拷貝，主要用於備份數據。
關於主副分片數的設置：
- 主分片數：主分片數在索引創建時確定，之後不能修改。
- 在 ES 7.0 以後，一個索引默認有一個主分片。
- 一個索引的主分片數不能超過 1024。
- 副本分片數：副本分片數在索引創建之後可以動態修改。
- 副本分片數默認爲 1。
關於每個節點上的分片數的設置，可參考這裏。
2.1，主分片的設計
如果某個索引只有一個主分片：
- 優點：查詢算分和聚合不精準的問題都可避免。
- 缺點：集羣無法實現水平擴展。
- 因爲索引（不管該索引的數據量達到了多大）只能存儲在一個主分片上（一個分片不能跨節點存儲/處理）；
- 對於單個主分片的索引來說，即使有再多的數據節點，它也無法利用。
如果某個索引有多個主分片：
- 優點：集羣可以實現水平擴展。
- 對於擁有多個主分片的索引，該索引的數據可以分佈在多個主分片上，不同的主分片可以分佈在不同的數據節點中；這樣，該索引就可以利用多個節點的讀寫能力，從而處理更多的數據。
- 如果當前的數據節點數小於主分片數，當有新的數據節點加入集羣后，這些主分片就會自動被分配到新的數據節點上，從而實現水平擴容。
- 缺點：但是主分片數也不能過多，因爲對於分片的管理也需要額外的資源開銷。主要會帶來以下問題：
- 每次搜索/聚合數據時需要從多個分片上獲取數據，並彙總；除了會帶來精準度問題，還會有性能問題。
- 分片的 Meta 信息由 Master 節點維護管理，過多的分片，會增加 Master 節點的負擔。
對於分片的設計建議：
- 從分片的存儲量考慮：
- 對於日誌類應用，單個分片不要大於 50G；
- 對於搜索類應用，單個分片不要大於 20G；
- 從分片數量考慮：
- 一個 ES 集羣的分片（包括主分片和副本分片）總數不超過 10 W。
2.2，副本分片的設計
副本分片是主分片的備份：
- 優點：
- 可防止數據丟失，提高系統的可用性；
- 可以分擔主分片的查詢壓力，提高系統的查詢性能。
- 缺點：
- 與主分片一樣，需要佔用系統資源，有多少個副本，就會增加多少倍的存儲消耗。
- 會降低系統的寫入速度。
3，集羣容量規劃
容量規劃指的是，在一個實際項目中：
- 一個集羣需要多少節點，以及節點類型分配。
- 一個索引需要幾個主分片，幾個副本分片。
3.1，要考慮的因素
做容量規劃時要考慮的因素：
- 機器的軟硬件配置
- 數據量：
- 單條文檔的尺寸
- 文檔的總數量
- 索引的總數量
- 業務需求：
- 文檔的複雜度、數據格式
- 寫入需求
- 查詢需求
- 聚合需求
- 等
3.2，硬件配置
對系統整體性能要求高的，建議使用 SSD，內存與硬盤的比例可爲 1：10。
對系統整體性能要求一般的，可使用機械硬盤，內存與硬盤的比例可爲 1：50。
JVM 配置爲機器內存的一半，建議 JVM 內存配置不超過 32 G。
單個節點的數據建議控制在 2TB 以內，最大不超過 5 TB。
3.3，常見應用場景
有如下常見應用場景：
- 搜索類應用：
- 總體數據集大小基本固定，數據量增長較慢。
- 日誌類應用：
- 每日新增數據量比較穩定，數據量持續增長，可預期。
1，處理時間序列數據
ES 中提供了 Date Math 索引名用於寫入時間序列的數據。
示例：
請求 URI 要經過 URL 編碼：
# PUT /<my-index-{now/d}>
# 經過 URL 編碼後
PUT /%3Cmy-index-%7Bnow%2Fd%7D%3E
查詢示例：
# POST /<logs-{now/d}/_search
POST /%3Clogs-%7Bnow%2Fd%7D%3E/_search
# POST /<logs-{now/w}/_search
POST /%3Clogs-%7Bnow%2Fw%7D%3E/_search
4，ES 開發模式與生產模式
從 ES 5 開始，ES 支持開發模式與生產模式，ES 可通過配置自動選擇不同的模式去運行：
- 開發模式配置：
- http.host：localhost
- transport.bind_host：localhost
- 生產模式配置：
- http.host：真實 IP 地址
- transport.bind_host：真實 IP 地址
4.1，Booststrap 檢測
在生產模式啓動 ES 集羣時，會進行 Booststrap 檢測（只有檢測通過才能啓動成功），它包括：
- JVM 檢測
- Linux 檢測：只在 Linux 環境進行
4.2，JVM 配置
JVM 通過 config 目錄下的 jvm.options 文件進行配置，需要注意以下幾點：
- 將 Xms 和 Xmx 設置成一樣；
- Xmx 不要超過物理內存的 50%，最大內存建議不超過 32G；
- JVM 有 Server 和 Client 兩種模式，在 ES 的生產模式必須使用 Server 模式；
- 需要關閉 JVM Swapping
4.3，更多的 ES 配置
更多的關於 ES 的配置可參考其官方文檔，包括：
5，監控集羣狀態
集羣狀態爲 Green 只能代表分片正常分配，不能代表沒有其它問題。
ES 提供了很多監控相關的 API：
- _cluster/health：集羣健康狀態。
- _cluster/state：集羣狀態。
- _cluster/stats：集羣指標統計。
- _cluster/pending_tasks：集羣中正在執行的任務。
- _tasks：集羣任務。
- _cluster/allocation/explain：查看集羣分片的分配情況，用於查找原因。
- _nodes/stats：節點指標統計。
- _nodes/info：節點信息。
- _index/stats：索引指標統計。
- 一些 cat API。
5.1，Slow log
ES 的 Slow log 可以設置一些閾值，當寫入時間或者查詢時間超過這些閾值後，會將相關操作記錄日誌。
5.2，集羣診斷
需要監控的指標：
一個集羣診斷工具 Support Diagnostics。
（本節完。）
推薦閱讀：
歡迎關注作者公衆號，獲取更多技術乾貨。
