正文前的小菜——Elasticsearch的基礎概念(對基礎概念了解的朋友可以直接往下看題)

Elasticsearch（簡稱ES）是一個基于Apache Lucene構建的開源、分布式、RESTful接口的全文搜索引擎。

以下是Elasticsearch的基礎概念：

1.Elasticsearch的基本概念

(1) 索引（Index）：

• 索引是Elasticsearch中存儲數據的地方，可以把它理解為一個優化過的、快速查詢的大型文檔集合。
• 索引類似于關系型數據庫中的“數據庫”或“表”的概念，但它是面向文檔的，且每個字段都可以被索引和搜索。
• 索引由名稱（必須為全小寫字符）標識，并通過此名稱進行文檔的創建、搜索、更新及刪除操作。

(2) 文檔（Document）：

• 文檔是Elasticsearch中的最小單位，是索引中的一條數據。
• 文檔以JSON格式存儲，包含多個字段，每個字段的類型由映射（Mapping）定義。
• 文檔的字段類型可以是文本、數值、日期等，也可以是復雜類型，如嵌套文檔或數組。

(3) 映射（Mapping）：

• 映射定義了索引中文檔的結構，包括字段的名稱、類型和其他相關設置。
• 類似于關系型數據庫中的模式（Schema），但Elasticsearch支持動態映射，即可以在插入新字段時自動創建映射。

(4) 分片（Shard）：

• 分片是Elasticsearch分布式架構的基礎，每個索引都可以被分成多個主分片（Primary Shard）和副本分片（Replica Shard）。
• 主分片負責數據的存儲和索引，而副本分片則提供數據的冗余存儲和負載均衡。
• 分片使得Elasticsearch能夠橫向擴展至數以百計的服務器，處理PB級的數據。

(5) 節點（Node）：

• 節點是Elasticsearch集群中的一個實例，它可以是主節點（Master Node）、數據節點（Data Node）或客戶端節點（Client Node）。
• 主節點負責集群的元數據存儲和協調，數據節點負責數據的存儲和檢索，而客戶端節點則提供RESTful API接口供外部訪問。

2.Elasticsearch的工作原理簡述

(1) 索引過程：

• 當向Elasticsearch中存入文檔時，它會自動對文檔的內容進行索引。
• 索引過程包括分詞和倒排索引，幫助系統快速找到與查詢匹配的文檔。

(2) 查詢過程：

• 查詢請求會首先被發送到客戶端節點或數據節點。
• 節點會根據查詢條件將請求路由到包含相關數據的分片上。
• 分片會執行查詢并返回結果給節點，節點再將結果匯總后返回給客戶端。

3.Elasticsearch的應用場景

(1) 全文搜索：適用于需要全文檢索的應用場景，如搜索引擎、文檔管理系統等。

(2) 日志分析：適用于需要實時分析日志數據的應用場景，如運維監控、故障排查等。

(3) 實時數據分析：提供了聚合分析功能，可以實現對保存的大量數據的近實時統計分析。適用于需要實時數據分析的應用場景，如商業智能、數據分析等。

面試官：ES的整體架構是怎樣的？

Elasticsearch（簡稱ES）的整體架構是分布式和模塊化的，旨在支持大規模數據的搜索、分析和實時查詢。

以下是ES整體架構的詳細解釋：

1.集群與節點

(1) 集群：Elasticsearch集群由多個節點組成，這些節點共同協作以提供搜索和分析功能。每個集群都有一個唯一的名稱，節點通過這個名稱進行通信。

(2) 節點：每個節點都是一個運行Elasticsearch實例的服務器。節點可以是主節點、數據節點、協調節點或備份節點（也稱副本節點）。

• 主節點（Master Node）：負責管理集群的狀態和配置，如索引的創建和刪除、節點的加入和離開等。
• 數據節點（Data Node）：用于存儲數據并執行與數據相關的操作，如搜索、聚合和索引。數據節點是集群中最重要的節點，因為它們會處理大多數請求。
• 協調節點（Coordinating Node）：負責將請求路由到適當的節點，并將結果聚合返回給客戶。協調節點本身不存儲任何數據。
• 備份節點（Replica Node）：不用于主數據存儲，而是為主節點分片提供備份。若主節點出現故障，副本將自動替代其功能，保證高可用性。

2.索引與分片

(1) 索引：索引是存儲文檔的地方，可以視為一個數據庫。每個索引都有一個唯一的名稱，用于在搜索時引用。索引中的數據通常以JSON格式存儲，并可以通過REST API進行操作。

(2) 分片：索引被分割成多個分片，每個分片是一個獨立的Lucene索引。分片使得數據可以水平擴展，允許在多個節點上分布存儲。每個索引可以有多個主分片（primary shard）和副本分片（replica shard）。主分片存儲數據，副本分片用于提供數據冗余和負載均衡。

3.文檔與字段

(1) 文檔：文檔是Elasticsearch中存儲的基本信息單元，通常與數據庫中的一行相對應。每個文檔都有一個唯一的ID，且以JSON格式存儲。文檔包含多個字段，這些字段提供了文檔的元數據或內容。

(2) 字段：文檔中的每個屬性都稱為一個字段。字段可以包含文本、數字、日期、布爾值或地理位置等數據類型。

4.存儲與檢索機制

(1) 存儲機制：當文檔被寫入Elasticsearch時，它們首先被存儲在內存緩沖區（Memory Buffer）中。然后，這些文檔會定期被刷新到磁盤上的段文件（Segment）中。段文件是Lucene索引的基本單位，它們包含了文檔的倒排索引和其他相關信息。

(2) 檢索機制：當用戶執行搜索查詢時，Elasticsearch會首先在Term Dictionary中查找查詢字符串中的每個單詞。然后，它會使用這些單詞對應的倒排列表來找到包含這些單詞的文檔。最后，系統會根據文檔的相關性得分對結果進行排序并返回給用戶。倒排索引允許Elasticsearch快速定位到包含特定單詞的文檔集合。

5.容錯與副本管理

(1) 容錯機制：Elasticsearch通過副本機制來提高數據的可靠性和可用性。當主分片出現故障時，副本分片會自動提升為主分片，以繼續提供服務。

(2) 副本管理：Elasticsearch會根據配置為主分片創建副本分片。這些副本分片可以分布在不同的節點上，以確保在主分片出現故障時，數據仍然可以從副本分片中恢復。

6.分布式架構與擴展性

(1) 分布式架構：Elasticsearch的分布式架構允許它橫向擴展，以支持大規模數據集的存儲與處理。通過添加更多節點到集群中，Elasticsearch可以自動重新分配數據以平衡負載并提高性能。

(2) 擴展性：Elasticsearch提供了靈活的擴展選項，包括垂直擴容（使用更強大的服務器）和水平擴容（添加更多服務器）。然而，水平擴容通常是更受歡迎的選擇，因為它可以更有效地利用資源并避免單點故障。

面試官：Elasticsearch中的分片和副本是如何工作的？分片和副本的大小和數量如何影響ES的性能？

1.分片（Shard）

(1) 定義：分片是Elasticsearch分發數據的單元。每個分片本身就是一個完整的搜索引擎（Lucene實例），它保存了全部數據中的一部分。

(2) 創建與分配：

當創建一個新索引時，Elasticsearch會根據用戶指定的分片數量（通過number_of_shards參數）創建主分片，并將這些分片分配到集群中的不同節點上。

分片的分配由Elasticsearch自動管理，確保它們分布在集群的不同節點上，以最大限度地提高系統的容錯能力和性能。

(3) 數據寫入：

對于寫操作（如創建、更新或刪除），Elasticsearch會將請求發送到包含相關分片的節點上執行。

寫請求首先發送到主分片，主分片處理寫請求并將數據寫入到分片中，然后主分片將寫操作同步到所有的副本分片，確保數據的一致性。

(4) 數據讀?。?/p>

對于讀取操作，Elasticsearch可以從任何具有對應分片（無論是主分片還是副本分片）的節點上獲取數據。

這允許查詢負載均衡，并且可以利用副本分片來增加搜索吞吐量。

2.副本（Replica）

(1) 定義：

副本是對主分片的冗余復制，用于提高數據的可用性和容錯性。

每個主分片都可以有一個或多個副本分片。

(2) 創建與分配：

Elasticsearch根據索引的副本設置（通過number_of_replicas參數），為每個主分片創建副本分片。

副本分片被分配到與主分片不同的節點上，以確保數據冗余和故障恢復能力。

(3) 故障恢復：

如果某個節點宕機了，導致某些分片不可用，Elasticsearch會自動檢測到這個問題并嘗試使用副本分片來恢復服務。

Elasticsearch會將副本分片提升為主分片，并在集群中的其他節點上創建新的副本分片，以恢復數據冗余。

(4) 性能提升：

副本分片可以分擔讀請求，減少單個分片的讀負載，從而提高搜索性能和吞吐量。

如下所示是啟動2個ES節點，創建5個分片，1個副本的示例。

下面是啟動3個ES節點，創建5個分片，1個副本的示例。

下面再說說看分片和副本的大小和數量對ES性能的影響。

3.分片大小和數量對性能的影響

(1) 分片大?。?/p>

• 寫入性能：較小的分片可以減少每個分片上的數據量，從而可能加快寫入速度，因為每次寫入操作涉及的數據量更少。然而，過小的分片可能導致過多的分片數量，增加管理開銷和I/O操作。相反，較大的分片可以處理更多的寫入請求，提高系統的寫入吞吐量，但過大的分片可能使故障恢復速度變慢。
• 讀取性能：分片大小對讀取性能的影響相對復雜。較小的分片可能減少查詢時的數據掃描范圍，但也可能增加查詢時的分片間通信開銷。較大的分片可能提高查詢效率，但也可能導致查詢延遲增加，因為需要處理的數據量更大。

(2) 分片數量：

• 寫入性能：更多的主分片可以提高寫入吞吐量，因為操作可以并行化到多個分片上。然而，每個分片都會消耗資源（CPU、內存、磁盤），過多的分片會導致資源競爭，反而降低性能。
• 讀取性能：讀取性能可以通過增加副本分片來提高，因為更多的副本可以處理更多的并發讀請求。然而，分片數量過多也可能導致查詢時的分片間通信開銷增加，影響讀取性能。

4.副本大小和數量對性能的影響

(1) 副本大?。?/p>

副本是數據的冗余拷貝，存儲在副本分片中。副本分片的大小與主分片相同，因為它們是對主分片的完整復制。因此，副本大小本身對性能沒有直接影響，但副本的數量和分布會影響性能。

(2) 副本數量：

提示：這里說的副本的數量是指ES對分片復制了幾份副本，而不是一份副本有多少個分片。

• 讀取性能：增加副本分片數量可以提高系統的讀取性能，因為更多的副本可以處理更多的并發讀請求。副本分片還可以減少單個分片的讀負載，因為請求可以在多個副本之間均勻分配。
• 寫入性能：每次寫入操作不僅要在主分片上執行，還要在所有副本分片上重復。因此，增加副本分片數量會增加寫操作的負擔，每次寫操作需要同步到更多的副本上。這可能導致寫入性能下降，特別是在資源有限的情況下。
• 容錯能力：副本分片還可以提高系統的容錯能力。如果一個節點或分片失敗，Elasticsearch可以從副本中恢復數據，幾乎不影響用戶查詢。更多的副本可以更快地恢復數據，因為Elasticsearch有更多選項來重新分配和平衡網絡中的數據。

5.優化建議

(1) 合理設置分片數量：

• 根據數據量、硬件資源和使用場景來設置主分片的數量。通常建議將每個主分片的大小保持在幾十GB到幾百GB之間。
• 對于需要頻繁更新或刪除的數據，較小的分片（如10GB-20GB）可能更合適，以減少段合并的開銷。對于靜態數據或只增加不修改的數據，更大的分片（接近50GB）通常更有效。

(2) 根據讀取負載調整副本數量：

• 如果系統是讀取密集型的（如搜索或分析應用），增加副本分片可以提供更好的讀取性能。
• 在決定副本數量時，也要考慮集群的節點數量。至少應該有足夠的節點來分配這些副本，以避免所有副本都在同一個節點上導致資源競爭。

(3) 監控和調整：

• 使用Elasticsearch的監控工具（如Kibana Monitoring）定期檢查分片的健康和性能。
• 如果檢測到性能瓶頸，可以根據具體情況調整分片和副本的數量。例如，使用Shrink API減少分片數量，或使用Split API增加分片數量。

面試官：說說看ES的倒排索引是如何實現的？

Elasticsearch使用倒排索引（Inverted Index）來存儲和檢索數據。倒排索引是一種數據結構，用于存儲每個詞（term）及其對應的文檔ID列表（Posting List）。這種結構使得Elasticsearch能夠快速地根據一個或多個詞找到包含這些詞的文檔。

ES的倒排索引包括以下結構：

1.Term Dictionary

Elasticsearch將所有的詞進行排序，并使用二分法查找詞，以提高查找效率。這種排序后的詞列表被稱為Term Dictionary。

如下圖所示是正排索引，正排索引是以文檔的ID作為關鍵字，并且記錄文檔中每個字段的值信息，通過查詢id來把整條文檔拿出來。但是在查詢某一個keyword存在于哪些文檔的時候， 需要對所有文檔進行掃描匹配。

這樣檢索效率比較低下：

再看倒排索引的Term Dictionary，倒排索引以字或詞作為關鍵字索引， 倒排索引建立的是分詞（Term）和文檔（Document）之間的映射關系。

2.倒排列表（Posting List）

倒排列表記載了出現過某個單詞的所有文檔的文檔列表。

列表中包含單詞在該文檔中出現的位置信息及頻率（作關聯性算分），每條記錄稱為一個倒排項（Posting）。

3.Term Index

由于Term Dictionary可能非常大，無法全部放入內存，因此Elasticsearch引入了Term Index。Term Index類似于字典的索引頁，它包含了詞的一些前綴和對應的Term Dictionary的block位置。通過Term Index，Elasticsearch可以快速定位到Term Dictionary的某個位置，然后從這個位置順序查找所需的詞。

4.FST（Finite State Transducers）

為了進一步優化Term Index，Elasticsearch使用了FST壓縮技術。FST是一種有限狀態機，它將詞（字節序列）映射到任意輸出。通過FST，Elasticsearch可以將Term Index占用的空間進一步縮小并緩存到內存中，從而提高查找效率。FST的實現相對比較復雜，面試的時候答到Term Dictionary、倒排列表 和 Term Index即可，如果還想把FST答出來就要理解FST算法的原理。下面簡單描述下FST的構造過程。我們對“cat”、 “deep”、 “do”、 “dog” 、“dogs”這5個單詞進行插入構建FST（注：必須已排序）。1）插入“cat”插入cat，每個字母形成一條邊，其中t邊指向終點。

2）插入“deep”與前一個單詞“cat”進行最大前綴匹配，發現沒有匹配則直接插入，P邊指向終點。

3）插入“do”與前一個單詞“deep”進行最大前綴匹配，發現是d，則在d邊后增加新邊o，o邊指向終點。

4）插入“dog”與前一個單詞“do”進行最大前綴匹配，發現是do，則在o邊后增加新邊g，g邊指向終點。

5）插入“dogs”與前一個單詞“dog”進行最大前綴匹配，發現是dog，則在g后增加新邊s，s邊指向終點。

最終我們得到了如上一個有向無環圖。利用該結構可以很方便的進行查詢，如給定一個term “dog”，我們可以通過上述結構很方便的查詢存不存在，甚至我們在構建過程中可以將單詞與某一數字、單詞進行關聯，從而實現key-value的映射。那么只要在每個節點或者指針上存儲該節點上單詞的倒排列表的地址就可以知道該單詞對應的文檔ID有哪些了。

面試官：能說說看Elasticsearch寫入文檔的過程是怎么樣的嗎？

在介紹ES的寫入過程之前，先要介紹有關ES索引和段的基礎概念。

在ES中，索引（Index）是一個邏輯命名空間，包含一組文檔。每個索引由多個分片（Shard）組成，而每個分片又由多個segment組成。

segment是索引數據的實際存儲單元，而分片則是數據分布和并行處理的基本單位。當查詢一個Elasticsearch索引時，查詢會在所有分片上執行，進而查詢到segment，然后合并所有結果。每一個段都是一個獨立的、不可變的文件集合，包含了完整索引中的一部分數據（包括倒排索引和正排索引）。

我們可以理解為，ES寫入文檔最終是要將文檔寫入到段中，這個文檔才算進入了倒排索引，能夠被搜索。

索引在 Lucene 中除表示所有段的集合外，還增加了提交點的概念。

為了提升寫的性能，Lucene并沒有每新增一條數據就增加一個段，而是采用延遲寫的策略，每當有新增的數據時，就將其先寫入內存中，然后批量寫入磁盤中。若有一個段被寫到硬盤，就會生成一個提交點，提交點就是一個列出了所有已知段和記錄所有提交后的段信息的文件。

再回過頭來說ES寫入文檔的過程，詳細描述如下：

1.寫入請求的接收與路由

(1) 接收請求：

客戶端向Elasticsearch集群中的任意節點發送寫入（Index）請求。

(2) 確定目標分片：

接收請求的節點（作為協調節點）根據文檔的ID和索引的設置（如分片數量），使用哈希函數和模運算來確定文檔應該寫入到哪個主分片。

分片計算公式：shard_num = hash(_routing) % num_primary_shards。其中，_routing默認情況下是文檔的ID，num_primary_shards是主分片的數量。

(3) 路由請求到目標節點：

協調節點根據目標分片的ID，通過集群狀態中的路由表找到該分片的主分片所在的節點，并將請求轉發給該節點。

2.在主分片上執行寫入操作

(1) 內存緩沖區：

主分片接收到寫入請求后，首先將文檔存儲在內存中的一個緩沖區（In-memory buffer）中。

(2) 記錄事務日志：

同時，為了確保數據的持久性和可靠性，Elasticsearch將每個寫入操作記錄到事務日志（Translog）中。

Translog是一個追加寫入的日志文件，它記錄了所有對索引的更改，以便在系統崩潰后恢復數據。

(3) 創建倒排索引：

在內存緩沖區中，Elasticsearch將文檔轉換成倒排索引的形式，這個索引會在內存中形成一個分段對象（Segment），詳情見下方的刷新操作（Refresh）。

倒排索引是Elasticsearch高效搜索的關鍵，它記錄了每個單詞在哪些文檔中出現，以及出現的位置。

3.將數據同步到副本分片

(1) 異步復制：

一旦文檔被寫入到主分片，主分片會開始將數據異步地同步到其對應的副本分片上。

副本分片是主分片的完整拷貝，它們可以處理搜索請求并提供數據恢復的能力。

(2) 等待確認：

主分片等待所有副本分片都成功寫入文檔后，才向協調節點發送確認信息。

Elasticsearch的寫入一致性策略（如quorum）確保了在寫入數據時，必須有足夠數量的活躍分片（包括主分片和副本分片）處于可用狀態。

4.刷新與持久化

(1) 刷新操作（Refresh）：

刷新操作會將內存緩沖區中的數據創建成一個新的Lucene段（Segment），并將其添加到索引中。

刷新操作是周期性的，可以通過配置來控制刷新的頻率，它使得新寫入的數據可以被搜索到，但它不會將數據持久化到磁盤上。

(2) 持久化操作（Flush）：

持久化操作會將內存中的數據以及Translog中的更改寫入到磁盤上。

這意味著數據被真正寫入到了物理存儲中，而不僅僅是保存在操作系統的文件系統緩存中。

持久化操作會調用操作系統的fsync函數來確保數據被寫入磁盤，并且會清空相關的緩存和文件（如Translog）。

5.合并段（Segment Merging）

(1) 優化存儲和搜索性能：

ElasticSearch 每次 refresh 一次都會生成一個新的 segment 文件，這樣下來 segment 文件會越來越多。因為每一個 segment 都會占用文件句柄、內存、cpu資源，每個搜索請求都必須訪問每一個segment，這就意味著存在的 segment 越多，搜索請求就會變得更慢。

為了優化存儲和搜索性能，Lucene會定期進行段合并操作。

小的段會被合并到大的段中，然后這些大的段再被合并到更大的段。

(2) 合并過程：

合并過程在后臺進行，不會中斷索引和搜索操作。ElasticSearch 有一個后臺進程專門負責 segment 的合并，定期執行 merge 操作，將多個小 segment 文件合并成一個 segment，在合并時被標識為 deleted 的文檔不會被寫入到新的 segment 中。

合并完成后，老的段會被刪除，然后將新的 segment 文件 flush 寫入磁盤。

然后創建一個新的 commit point 文件，標識所有新的 segment 文件，并排除掉舊的 segement 和已經被合并的小 segment。

面試官：Elasticsearch是如何實現master選舉的？

1.選舉機制概述

Elasticsearch的master選舉機制主要通過Zen Discovery插件（默認插件）來實現。當Elasticsearch集群啟動時，所有節點都處于一種“候選”狀態，然后通過Zen Discovery機制相互發現，并參與到主節點的選舉過程中。

2.選舉過程

(1) 節點發現：

Elasticsearch集群中的節點通過Zen Discovery機制相互發現，確保集群狀態的一致性。

(2) 候選者聲明：

每個節點在啟動時都會檢查自己的配置（如node.master設置為true），以確定自己是否有資格成為主節點候選者。

具備候選資格的節點會將自己添加到候選者列表中。

(3) 投票機制：

候選者節點會向集群中的其他所有節點發送投票請求。

每個節點在收到投票請求后，會根據一定的規則（如節點的健康狀況、存儲的數據量、負載情況等）來決定是否投票給該候選者。

投票過程遵循多數原則，即一個候選者必須獲得超過半數節點的選票才能成為主節點。

(4) 選舉結果：

如果某個候選者得到了超過半數的投票，那么它就會成為新的master節點。

如果兩個或更多的候選者得到了相同的票數，那么集群將會再次進行選舉，直到選出一個明確的master節點。

三、選舉過程中的關鍵要素

(1) 節點ID和版本號：

在選舉過程中，節點的ID和版本號也是重要的考慮因素。通常，版本號更高的節點會被優先考慮作為主節點。

如果版本號相同，則會根據節點ID的大小來決定選舉結果（ID越小，優先級越高）。

(2) 穩定性檢查：

Elasticsearch會周期性地檢查當前的主節點是否仍然有效。

如果主節點失去聯系或不可用，集群會再次啟動一個新的選舉過程來選出新的主節點。

(3) 持久化和同步：

主節點的選舉結果會被集群中的所有節點同步和持久化。

這確保了每個節點對當前的主節點有一致的認知，從而維護了集群的一致性。

面試官：ES集群的腦裂問題是如何產生的？如何避免ES集群發生腦裂？

1.基本概念

Elasticsearch集群中的腦裂問題（split-brain problem）是指在網絡分裂或節點故障的情況下，集群中的節點可能無法就主節點的選擇達成一致，導致多個節點各自認為自己是主節點，從而引發數據不一致和潛在的數據丟失問題。

2.產生原因

(1) 網絡問題：

集群間的網絡延遲或中斷，導致一些節點無法訪問到主節點（Master Node），從而認為主節點已經失效。

在這種情況下，這些節點可能會選舉出新的主節點，并對原有的主節點上的分片和副本進行標記（如標紅），然后分配新的主分片。

(2) 節點負載：

當主節點的角色既為Master又為Data時，如果訪問量較大，可能會導致主節點停止響應或處于假死狀態。

此時，其他節點得不到主節點的響應，會認為主節點已經掛掉，從而重新選舉主節點。

(3) JVM內存回收：

Data節點上的Elasticsearch進程占用的內存較大時，可能會引發JVM的大規模內存回收，導致Elasticsearch進程失去響應。

這種情況也可能導致節點認為其他節點已經失效，從而嘗試選舉新的主節點。

(4) 配置不當：

如果Elasticsearch集群的配置不當，如最小主節點數（Minimum Master Nodes）設置不正確，也可能導致腦裂問題的發生。

最小主節點數應該設置為(N/2) + 1（其中N是具有主節點資格的節點數），以確保在集群分裂時只有一個主節點被選舉出來。

3.影響與后果

• 數據不一致：在腦裂問題發生時，不同的節點組可能會執行不同的寫操作，導致數據不一致。
• 數據丟失：如果在腦裂問題發生期間，集群中的某些節點發生故障或宕機，可能會導致數據丟失。

為了防止Elasticsearch集群中的腦裂問題，可以采取以下措施：

(1) 主節點選舉機制

• Zen Discovery模塊：Elasticsearch使用Zen Discovery模塊進行主節點選舉，確保集群中只有一個主節點管理集群元數據。
• 仲裁節點數配置：合理配置discovery.zen.minimum_master_nodes，這個參數用于定義在選舉主節點時，集群中必須有多少個節點被認為是活躍的，才能允許進行主節點的選舉。

推薦的配置值是(N/2) + 1（向下取整），其中N是具有主節點資格的節點數。這個配置可以有效防止在網絡分區時形成多個主節點。

(2) 網絡配置與故障處理

①網絡超時與重試機制：

• 配置網絡超時（如discovery.zen.ping_timeout）和重試機制，以減少網絡故障對集群的影響。
• 適當增加超時時間可以減少因網絡抖動導致的誤判，從而避免不必要的主節點重選。

②網絡分區檢測：定期進行集群健康檢查，如果發現網絡分區，集群會自動嘗試恢復并重新連接。

③網絡隔離：盡量避免將Elasticsearch集群部署在可能存在網絡隔離風險的環境中，如跨數據中心部署時，要確保網絡連接的穩定性和可靠性。

(3) 節點配置與負載管理

① 主節點與數據節點分離：

• 將主節點（master node）與數據節點（data node）分離，以減輕主節點的負載，提高其穩定性和響應速度。
• 可以通過配置node.master和node.data屬性來實現節點的角色分離。

關于node.master和node.data屬性的解釋如下：一個Elasticsearch集群是由許多Node構成的，Node可以有不同的類型，通過以下配置，可以產生四種不同類型的Node：

conf/elasticsearch.yml:
    node.master: true/false
    node.data: true/false

四種不同類型的Node是一個node.master和node.data的true/false的兩兩組合。

當node.master為true時，其表示這個node是一個master的候選節點，可以參與選舉。ES正常運行時只能有一個master，多于1個時會發生腦裂。

當node.data為true時，這個節點作為一個數據節點，會存儲分配在該node上的shard的數據并負責這些shard的寫入、查詢等。

② 負載均衡：

• 在數據節點之間實現負載均衡，避免單個節點過載導致集群不穩定。
• 可以使用Elasticsearch的內置負載均衡機制或外部負載均衡器來實現。

面試官：ES在高并發下如何保證讀寫一致性？

Elasticsearch在高并發環境下保證讀寫一致性，主要通過以下幾種機制來實現：

1.最終一致性模型

Elasticsearch采用最終一致性模型，這意味著在理想情況下，系統會最終達到一致性，但可能在某些情況下會有短暫的不一致，尤其是在分布式系統中發生網絡分區或節點故障時。這種模型提供了高可用性和容錯能力，同時降低了嚴格一致性帶來的性能開銷。

2.事務日志（Translog）

作用：記錄所有對索引的更改操作，包括文檔的插入、更新和刪除。

寫前日志（Write-Ahead Logging, WAL）：當寫入請求到達時，Elasticsearch首先將數據寫入事務日志，然后再將其異步刷新到磁盤上的分片中。這種機制確保了在系統崩潰等異常情況下，已經提交的數據不會丟失。

持久化：事務日志的使用對于處理高并發寫入請求至關重要，因為寫入操作只需要寫入事務日志，而不需要直接更新磁盤上的分片，因此寫入性能得到了極大的提升。同時，定期將事務日志的內容寫入到一個新的日志文件中，并刪除舊的日志文件，以確保數據的持久化。

3.分片和副本

分片：Elasticsearch通過將數據分布在多個分片上來實現水平擴展。每個索引由一個或多個分片組成，每個分片可以獨立存儲和處理數據。這種分片機制有助于將寫入和讀取請求分散到集群的不同節點上，從而提高并發處理能力。

副本：每個分片可以有零個或多個副本。副本是分片的完整拷貝，用于提高數據的可用性和容錯能力。當原始分片不可用時（例如，由于節點故障），副本可以接管處理請求。通過合理配置分片和副本的數量，可以在集群中平衡負載，進一步提高并發處理能力。

4.樂觀并發控制

版本號：Elasticsearch在每個文檔上維護版本號。每當文檔被更新時，該版本號就會增加。

寫入操作：當寫入操作請求使用一個特定版本時，Elasticsearch會檢查當前存儲的版本與請求的版本是否匹配。如果匹配，則執行更新操作；如果不匹配，則返回版本沖突錯誤。

沖突處理：如果兩個并發請求試圖更新同一個文檔，只有第一個請求會成功，第二個請求會收到一個版本沖突錯誤。應用程序可以根據業務邏輯對這些沖突進行處理，比如重試或者合并數據。

5.寫入一致性和讀取一致性控制

寫入一致性：通過設置write consistency，可以要求在寫操作時，必須等待多少個分片副本確認成功才能返回。這可以提高數據的可靠性，但可能會增加延遲。例如：

• quorum：等待多數副本確認。
• all：等待所有副本確認。

讀取一致性：通過設置search consistency，可以保證讀取到的數據是某個時間點的一致視圖。例如：

• 使用refresh機制，確保查詢時能夠看到剛剛寫入的數據。
• 在分頁查詢時，可以使用search_after進行基于游標的查詢，以避免由于分頁查詢中的數據變化導致的不一致問題。