數據存儲在碎片中，這些碎片分布在集群中的所有節點上。
副本:副本是原始片段的副本，與原始片段相同。Elasticsearch默認會生成壹個副本，所以相當於五個原始片段和五個片段副本，相當於壹個數據的兩個副本和十個片段。
主節點:即主節點。主節點的主要職責與集群操作相關，例如創建或刪除索引，跟蹤哪些節點是集群的壹部分，以及決定將哪些片段分配給相關節點。穩定的主節點對集群的健康非常重要。默認情況下，任何群集中的壹個節點都可以被選為主節點。索引數據和搜索查詢等操作將占用大量cpu、內存和io資源。為了確保集群的穩定性，將主節點與數據節點分離是更好的選擇。雖然主節點也可以協調節點、路由搜索以及將數據從客戶端添加到數據節點，但最好不要使用這些專用的主節點。壹個重要的原則是盡可能少做工作。
數據節點:即數據節點。數據節點主要用於存儲索引數據，主要用於增加、刪除、修改和查詢文檔、聚合等。數據節點對CPU、內存和IO的要求很高，因此需要在優化過程中監控數據節點的狀態，當資源不足時，需要向集群中添加新節點。
負載均衡節點:又稱客戶端節點，又稱客戶端節點。當壹個節點沒有被配置為主節點或數據節點時，它只能處理路由請求、搜索、索引分發操作等。本質上，客戶端節點相當於壹個智能負載平衡器。在大型集群中，獨立的客戶端節點非常有用。它協調主節點和數據節點。當客戶端節點加入集群時，它可以獲得集群的狀態，並根據集群的狀態直接路由請求。
預處理節點:也稱為攝取節點，可以在索引前對數據進行預處理。事實上，默認情況下所有節點都支持攝取操作，或者可以將某個節點專門配置為攝取節點。
1.Master:主節點，每個集群有且只有壹個。
盡量避免主節點也是數據節點:node.datatrue。
主節點的主要職責是負責集群級別的相關操作，管理集群更改（如創建或刪除索引），跟蹤哪些節點是集群的壹部分，以及決定將哪些碎片分配給相關節點。
2.投票:投票節點
Node.voting_only = true（即使配置了data.master = true，也只有投票節點不會參選，但它們仍可用作數據節點）。
3.協調:協調節點
每個節點隱含地是壹個協調節點。如果同時設置了data.master = false和data.data=false，此節點將成為僅協調節點。
4.合格主節點（候選節點）
可以被選為主節點的節點。
5.數據節點（數據節點）
主要負責數據存儲和查詢服務。
配置:
這是ES節點的默認配置，它們既是候選節點也是數據節點。壹旦這樣的節點被選為主節點，壓力就會相對較大。壹般來說，主節點應該只承擔相對輕量級的任務，如創建刪除索引、切片和平衡等。
只有作為候選節點，而不是數據節點，才能競選主節點，當選後才能成為真正的主節點。
既不作為候選節點，也不作為數據節點，即只作為協調節點，負責負載均衡。
不是作為候選節點，而是作為數據節點，這類節點主要負責數據存儲和查詢服務。
協調節點是如何工作的，他如何找到相應的節點？
每個節點保存集群的狀態，只有主節點可以修改集群的狀態信息。
Cluster Starte維護集群中的必要信息。
所有節點信息
所有索引及其相關的映射和設置信息
零碎的路由信息
協調節點作為es節點中的壹個節點，可以被es集群中的所有節點默認用作協調節點，主要用於請求轉發和請求響應處理等輕量級操作。
這意味著如果他們收到用戶請求，他們可以處理用戶請求。
狀態字段指示當前群集作為壹個整體是否正常工作。它的三種顏色具有以下含義:
所有綠色的主片和副本片都運行正常。
黃色所有主切片都正常運行，但並非所有副本切片都正常運行。
紅色有壹個主切片不能正常工作。
為文檔編制索引時，文檔將存儲在主切片中。Elasticsearch如何知道文檔應該存儲在哪個分片中？當我們創建壹個文檔時，它如何決定這個文檔應該存儲在片段1還是片段2中？
首先，它不會是隨機的，否則我們將來不知道去哪裏找文檔。事實上，這壹過程是根據以下公式確定的:
路由是壹個變量值，默認為文檔的_id，也可以設置為自定義值。路由通過哈希函數生成壹個數字，然後將該數字除以number_of_primary_shards（主切片數）得到余數。這個余數分布在0和number _ of _ primary _ shards-1之間，是我們要查找的文檔所在的片的位置。
我們可以向集群中的任何節點發送請求。每個節點都有能力處理任何請求。每個節點都知道集群中任何文檔的位置，因此它可以直接將請求轉發到所需的節點。在下面的示例中，所有請求都發送到節點1，我們稱之為協調節點。
以下是在主切片和輔助切片以及任何副本切片上成功創建、索引和刪除文檔所需的壹系列步驟:
壹致性壹致性:該參數的值可以設置為one（只要主切片的狀態正常，就允許write _ operation）、all（僅當主切片和所有副本切片的狀態正常時才允許write _ operation）或quorum。默認值為quorum，也就是說，如果大多數碎片副本的狀態為ok，則允許它們執行_ write _ operations。
主節點選舉當然是由符合主節點條件的節點發起的。
深入了解Elasticsearch 7.x的新集群協調層；
/檔案/332
彈性搜索的選舉機制
/archives/164
掌握彈性搜索的選舉機制
blogs.com/jelly12345/p/15319549.html
在麻省理工學院之前，所有數據都停留在緩沖區或操作系統緩存中，這兩者都是內存。壹旦機器死機，內存中的數據就會丟失，因此需要將數據對應的操作寫入壹個特殊的日誌中以詢問價格。壹旦機器停機並重新啟動，es就會主動讀取translog中日誌文件中的數據，並將其恢復到內存緩沖區和操作系統緩存中。
清空現有的事務日誌文件，然後重新啟動事務日誌。此時，提交成功。默認值是每30分鐘提交壹次，但是如果事務日誌文件太大，也會觸發提交。整個提交過程稱為刷新操作。我們也可以使用ES API。手動執行刷新操作，手動將操作系統緩存的數據同步到磁盤，記錄提交點，並清空事務日誌文件。
補充:其實translog的數據是先寫入OS緩存的，默認每5秒刷新壹次數據到硬盤。也就是說，緩沖區或translog文件的操作系統緩存中可能只有5秒鐘的數據。如果此時機器掛起，它將丟失5秒鐘的數據，但這種性能更好。我們也可以直接將fsync的每壹個操作都傳到磁盤上，但是性能會比較差。
如果操作被刪除，在提交時會生成壹個。del文件，表示壹個文檔被標記為已刪除，因此在搜索時，您將根據的狀態知道該文件已被刪除。del文件
如果該操作被更新，則意味著原始單據被標記為刪除，然後可以重寫壹條數據。
每次更新緩沖區時，都會生成壹個段文件，因此默認情況下，會生成許多段文件文件，並且會定期執行合並操作。
每次合並時，您會將多個段文件合並為壹個，同時刪除標記為刪除的文件，然後將新的段文件寫入磁盤，其中將寫入壹個提交點以標識所有新的段文件，然後打開新的段文件進行搜索。
段是不可變的，因此您既不能從舊段中刪除文檔，也不能修改舊段來更新文檔。相反，每個提交點將包含壹個。del文件，該文件將列出這些已刪除文檔的片段信息。
當文檔被“刪除”時，它實際上只在。del文件標記為刪除的文檔仍然可以通過查詢進行匹配，但是在返回最終結果之前，該文檔將從結果集中刪除。
文檔更新是類似的操作:當文檔更新時，舊版本的文檔被標記為刪除，新版本的文檔被索引到新的段中。有可能文檔的兩個版本都將通過查詢進行匹配，但是在返回結果集之前，已刪除的舊文檔版本已被刪除。
因為自動刷新過程每秒鐘都會創建壹個新段，這將導致段數在短時間內急劇增加。而且段位太多會帶來更大的麻煩。每個段都會消耗文件句柄、內存和cpu周期。更重要的是，每個搜索請求必須輪流檢查每個段；所以分段越多，搜索速度越慢。
Elasticsearch通過在後臺合並片段來解決這個問題。小段被合並成大段，然後這些大段被合並成更大的段。
合並片段時，那些舊的已刪除文檔將從文件系統中清除。已刪除的文檔（或已更新文檔的舊版本）不會被復制到新的大段中。
合並大段需要大量I/O和CPU資源，如果不加檢查，將會影響搜索性能。默認情況下，Elasticsearch將限制合並過程的資源，因此搜索仍然有足夠的資源來出色地執行。
/QQ _ 21299835/文章/詳情/106534644