ES系列基於ElasticSearch6.4.x版本。 1、簡介    ElasticSearch，每個索引被分成多個分片（預設每個索引5個主分片primary shard），每個分片又可以有多個副本。當一個文件被新增或刪除時（主分片中新增或刪除），其對應的複製分片之間必須保持同步。如果我們不這樣做，主要對於同一個文件的檢索請求，得到的結果將不一致。保持分片副本同步和服務讀取的過程就是我們所說的資料複製模型。    ElasticSearch的資料複製模型是基於主備份模型的。這個模型每一個複製組會有一個主分片，其他分片為複製分片。主分片伺服器是所有索引操作的主要入口點（索引、更新、刪除操作）。它負責驗證它們並確保它們是正確的。一旦一個索引操作被主伺服器接受，主伺服器也負責將操作複製到其他副本。    本節的目的是對Elasticsearch複製模型進行高水平的概述，並討論它對寫操作和讀操作之間的各種互動的影響。

2、基本寫模型    ElasticSearch每個索引操作都首先被解析為一個使用路由的複製組，預設基於文件ID（routing），其基本演算法為hash(routing) % (primary count)。一旦確定了複製組，則該操作將被轉發到組的主分片（primary shard）。主碎片負責驗證操作並將其轉發到其他副本。由於副本可以離線，所以不需要複製到所有副本。相反，彈性搜尋維護一個應該接收操作的碎片副本列表。這個列表被稱為in-sync副本，由主節點維護。正如其名稱所暗示的，這些是一組“好”碎片副本，它們保證已經處理了所有已被使用者認可的索引和刪除操作。主負責維護這個不變式，因此必須將所有操作複製到這個集合中的每個副本。    主分片處理流程：

1. 驗證請求是否符合Elasticsearch的介面規範，如果不符合，直接拒絕。
2. 在主分片上執行操作（例如索引、更新或刪除一個文件）。如果執行過程中出錯，直接返回錯誤。
3. 將操作轉發到當前同步副本集的每個副本。如果有多個副本，則並行執行。（in-sync當前可用、啟用的副本）。
4. 一旦所有的副本成功地執行了操作並對主伺服器進行了響應，主伺服器就會承認對客戶機的請求的成功完成。寫請求的流程如下圖所示（圖片來源於《Elasticsearch權威指南》）：    錯誤處理：    在索引過程中，許多事情可能會出錯——磁碟可能會被破壞，節點可以彼此斷開，或者一些配置錯誤可能導致一個副本的操作失敗，儘管它在主伺服器上是成功的。這些都是罕見的，但主要的是要對它們做出反應。    另外一種情況是如果主伺服器不可用，託管主節點的節點將向master傳送一條訊息。索引操作將等待（預設情況下最多1分鐘），以便master伺服器將其中一個副本提升為一個新的主節點。然後，該操作將被轉發到新的主伺服器進行處理。請注意，主伺服器(master)還監控各個節點的健康狀況，並可能決定主動降級主節點。這通常發生在持有主節點的節點通過網路問題與叢集隔離的情況下。為了更好的理解master伺服器與主分片所在伺服器的關係，下面給出一個ElasticSearch的叢集說明圖：
      其中NODE1為整個叢集的master伺服器，而第一個複製組(P0,R0,RO,其主分片所在伺服器NODE3)，第二個複製組(P1,R1,R1,其主分片所在伺服器NODE1)。    一旦在主伺服器上成功執行了操作，主伺服器就必須確保資料最終一致，即使由於在副本上執行失敗或由於網路問題導致操作無法到達副本（或阻止副本響應）造成的。為了避免資料在複製組內資料的不一致性（例如在主分片中執行成功，但在其中一兩個複製分片中執行失敗），主分片在如果未在指定時間內（預設一分鐘）未收到複製分片的成功響應或是收到錯誤響應，主分片會向Master伺服器傳送一個請求，請求從同步副本中刪除有問題的分片，當主分片確認刪除有問題的副本時，Master會指示刪除有問題的副本。同時，master還會指示另一個節點開始構建新的分片副本，以便將系統恢復到一個健康狀態。    主分片將一個操作轉發到副本時，首先會使用副本數來驗證它仍然是活動的主節點。如果由於網路分割槽（或長GC）而被隔離，那麼在意識到它已經被降級之前，它可能會繼續處理傳入的索引操作並轉發到從伺服器。來自陳舊的主伺服器的操作將會被副本拒絕。當主接受到來自副本的響應為拒絕它的請求時，此時的主分片會向Master伺服器傳送請求，最終將知道它已經被替換了，後續操作將會路由到新的主分片伺服器上。    如果沒有副本，那會發生什麼呢？    這是一個有效的場景，可能由於配置而發生，或者是因為所有的副本都失敗了。在這種情況下，主分片要在沒有任何外部驗證的情況下處理操作，這可能看起來有問題。另一方面，主分片伺服器不能自己失敗其他的分片（副本），而是請求master伺服器代表它這樣做。這意味著master伺服器知道主分片是該複製組唯一的可用拷貝。因此，我們保證master不會將任何其他（過時的）分片副本提升為一個新的主分片，並且任何索引到主分片伺服器的操作都不會丟失。當然這樣意味著我們只使用單一的資料副本，物理硬體問題可能導致資料丟失。請參閱Wait For Active Shards，以獲得一些緩解選項,(該引數項將在下一節中詳細描述)。    注：在一個ElasticSearch叢集中，存在兩個維度的選主。Master節點的選主、各個複製組主分片的選主。詳細的原理分析將在原始碼分析篇深入學習。

3、基本讀模型    在Elasticsearch中，可以通過ID進行非常輕量級的查詢，也可以使用複雜的聚合來獲取非平凡的CPU能力。主備份模型的優點之一是它使所有的分片副本保持相同（除了異常情況恢復中）。通常，一個同步副本就足以滿足讀取請求。    當一個節點接收到read請求時，該節點根據路由規則負責將其轉發給相應的資料節點，對響應進行整理，並對客戶端作出響應。我們稱該節點為該請求的協調節點。基本流程如下：

1. 將讀請求路由到到相關的分片節點。注意，由於大多數搜尋條件中不包含分片欄位，所以它們通常需要從多個分片組中讀取資料，每個分片代表一個不同的資料子集（預設5個數據子集，因為ElasticSearch預設的主分片個數為5個）。
2. 從每個分片複製組中選擇一個副本。讀請求可以是複製組中的主分片，也可以是其副本分片。在預設情況下，ElasticSearch分片組內的讀請求負載演算法為輪詢。
3. 根據第二步選擇的各個分片，向選中的分片傳送請求。
4. 匯聚各個分片節點返回的資料，然後返回個客戶端，注意，如果帶有分片欄位的查詢，將之後轉發給一個節點，該步驟可省略。

   異常處理：    當一個碎片不能響應一個read請求時，協調節點將從同一個複製組中選擇另一個副本，並將碎片級搜尋請求傳送給該副本。重複的失敗會導致沒有碎片副本可用。在某些情況下，比如搜尋，ElasticSearch會更傾向於快速響應，返回成功的分片資料給客戶端 ，並在響應包中指明哪些分片節點發生了錯誤。

4、Elasticsearch主備模型隱含含義

• 在正常操作下，每個讀取操作一次為每個相關的複製組執行一次。只有在失敗條件下，同一個複製組的多個副本執行相同的搜尋。
• 由於資料首先是在主分片上進行索引後，然後才轉發請求到副本，在轉發之前資料已經在主分片上發生了變化，所以在併發讀時，如果讀請求被轉發到主分片節點上，那該資料在它被確認之前（主分片再等待所有副本全部執行成功）就已經看到了變化。【有點類似於資料庫的讀未提交】。
• 主備模型的容錯能力為兩個分片（1主分片，1副本）。

5、ElasticSearch 讀寫模型異常時可造成的影響    在失敗的情況下，以下是可能的：

• 1個分片節點可能減慢整個叢集的索引效能 因為在每次操作期間（索引），主分片在本地成功執行索引動作後，會轉發請求到期複製分片節點上，此時主分片需要等待所有同步副本節點的響應，單個慢分片可以減慢整個複製組的速度。當然，一個緩慢的分片也會減慢那些被路由到它的搜尋。
• 髒讀 一個孤立的主伺服器可以公開不被承認的寫入。這是由於一個孤立的主節點只會意識到它在向副本傳送請求或向主人傳送請求時被隔離。在這一點上，操作已經被索引到主節點，並且可以通過併發讀取讀取。Elasticsearch可以通過在每秒鐘（預設情況下）對master進行ping來減少這種風險，並且如果沒有已知的主節點，則拒絕索引操作。

   本文詳細介紹了ElasticSearch文件的讀寫模型的設計思路，涉及到寫模型及其異常處理、讀模型及其異常處理、主備負載模型背後隱含的設計缺陷與ElasticSearch在異常情況帶來的影響。    下一節將開始學習Document API Index API。