# 讀寫文檔 ## 介紹 Elasticsearch中的每個索引都[分為分片](../Getting_Started/Basic_Concepts.md#getting-started-shards-and-replicas)，每個分片可以有多個拷貝。這些拷貝稱為復制組，并且在添加或刪除文檔時必須保持同步。如果我們沒有這樣做，將導致從一個拷貝讀取與從另一個讀取相比出現非常不同的結果。保持分片拷貝同步并從中讀取的過程就是我們所說的數據復制模型。 Elasticsearch的數據復制模型基于*主備模型*，并在Microsoft Research的[PacificA 論文](https://www.microsoft.com/en-us/research/publication/pacifica-replication-in-log-based-distributed-storage-systems/)中得到很好的描述。該模型基于復制組有一個拷貝作為主分片。其他拷貝稱為副本分片。主分片作為所有索引操作的主要入口點，負責驗證與確保正確。一旦索引操作被主分片接受，主分片負責將操作復制到其他副本。 本節的目的是給出Elasticsearch復制模型的高級概述，并討論它對寫操作和讀操作之間的各種交互的影響。 ## 基礎寫模式 Elasticsearch中的每個索引操作首先通過使用[路由](Index_API.md#index-routing)來解析復制組，通常基于文檔ID。一旦確定了復制組，操作將在內部轉發到組的當前主分片。主分片負責驗證操作并將其轉發給其他副本。由于副本可以脫機，因此主分片不需要復制到所有副本。相反，Elasticsearch會維護一個應該接收操作的分片拷貝的列表。該列表稱為`in-sync copies`，由主節點維護。顧名思義，這些是一組“好”的分片拷貝，保證已經處理了所有已被確認給用戶的索引和刪除操作。主分片負責維持這個不變，因此必須將所有操作復制到此集合中的每個副本。 主分片遵循以下基本流程： 1. 驗證進入的請求并拒絕無效的結構（示例：預期數字字段但傳入的是對象字段） 2. 在本地執行操作，即索引或刪除相關文檔。這還將驗證字段的內容并根據需要拒絕（示例：關鍵詞值太長，無法在Lucene中進行索引）。 3. 轉發操作到當前`in-sync copies`集合中的每個副本。如果有多個副本，這是并行完成的。 4. 一旦所有的副本都成功地執行了操作并對主分片作出響應，主分片確認成功地完成了對客戶端的請求。 ### 失敗處理 索引過程中可能會出現許多問題——磁盤可能會損壞、節點可能會斷開連接、或者某些配置錯誤可能導致副本上的操作失敗，盡管它在主服務器上成功。這些都是不常見的，但是主分片必須對他們做出回應。 在主分片本身失敗的情況下，托管主分片的節點將向主節點發送關于它的消息。索引操作將等待（[默認](../Index_Modules.md#dynamic-index-settings)情況下最多1分鐘）主節點將其中一個副本升級為新的主分片。然后將該操作轉發到新的主分片處理器。請注意，主節點還監控節點的運行狀況，并可能決定主動降級主分片。這通常發生在持有主分片的節點因為網絡問題脫離集群。請參閱[這里](#demoted-primary)了解更多詳情。 一旦在主分片執行操作成功，那么在復制分片上執行它時，主分片處理潛在的失敗。這可能是由于副本上的實際故障或由于網絡問題導致操作無法到達副本（或防止副本響應）引起的。所有這些都具有相同的最終結果：作為`in-sync`復制集合的一部分的副本將忽略即將被確認的操作。為了避免違反不變量，主分片向主節點發送消息，請求從`in-sync`復制集合中刪除有問題的分片。只有一旦主節點確認刪除了分片，主分片才能確認操作。請注意，主節點還將指示另一個節點開始構建新的分片副本，以便將系統恢復到正常狀態。 在將操作轉發到副本時，主分片將使用副本來驗證它仍然是主片。如果由于網絡分區隔離（或長GC），主分片在意識到已降級之前可能會繼續處理傳入的索引操作。來自老的主分片的操作將被副本拒絕。因為它不再是主分片，當主分片接收到來自副本拒絕其請求的響應時，所以它將連接到主節點，并將得知它已被替換。然后將操作路由到新的主分片。 > ## 如果沒有副本，會發生什么？ > > 這是一個有效的場景，由于索引配置可能會發生，或者因為所有的副本都失敗了。在這種情況下，主分片的處理操作沒有任何外部驗證，這似乎是有問題的。另一方面，主分片是不能自己失敗其他分片，但是要求主節點代表這樣做。這意味著主節點知道主分片是唯一的單一的好的拷貝。因此，我們保證，主節點不會將任何其他（過時的）分片拷貝推舉為新的主分片，而且主分片的任何索引操作都不會丟失。當然，由于在這一點上，我們只運行單個數據拷貝，因此物理硬件問題可能會導致數據丟失。有關緩解選項，請參閱[“等待活動分片”一節](Index_API.md#index-wait-for-active-shards)。 ## 基礎讀模式 Elasticsearch中的讀取可以通過非常輕量級的ID查找或重量級的具有復雜的聚合的搜索請求，需要有有非凡的CPU功率。主備模式的一個優點是它保持所有分片拷貝相同（異常的操作除外）。因此，單個在線同步的分片就足以服務于讀取請求。 當節點接收到讀請求時，該節點負責將其轉發到保存相關分片的節點，整理響應以及響應客戶端。我們稱該節點為該請求的*協調*節點。基本流程如下： 1. 將讀請求解析到相關分片。請注意，由于大多數搜索將發送到一個或多個索引，它們通常需要從多個分片中讀取，每個分片表示數據的不同子集。 2. 從分片復制組中選擇每個相關分片的活動拷貝。這可以是主分片或副本。默認情況下，Elasticsearch只會簡單的輪訓分片拷貝。 3. 將分片級讀取請求發送到所選拷貝。 4. 結合結果和回應。請注意，在通過ID查找的情況下，只有一個分片是相關的，并且可以跳過該步驟。 ### 失敗處理 當分片未能響應讀請求時，協調節點將從同一復制組中選擇另一個拷貝，并將該分片級搜索請求發送給該拷貝。重復故障可能導致沒有分片拷貝可用。在某些情況下，如`_search`，Elasticsearch將更愿意快速響應，盡管部分結果，而不是等待該問題得到解決（部分結果在響應的`_shards`頭中指出）。 ## 一些簡單的含義 每一個這些基本流程的確定了Elasticsearch系統如何表現為讀取和寫入數據。此外，由于可以同時執行讀寫請求，所以這兩個基本流彼此相互作用。這有一些固有的含義： **高效讀取** 在正常操作下，每個相關復制組執行一次讀取操作一次。只有在故障條件下，同一個搜索才會在多個拷貝的同一個分片上執行相同的搜索。 **讀取未確認** 由于主分片首先在本地進行索引，然后在向副本發送請求，所以并發讀取可以在確認之前已經看到更改。 **默認兩個拷貝** 該模型可以容錯，同時只保留兩個數據拷貝。這與基于法定人數的系統相反，其中容錯的最小份數為`3`。 ## 失敗 在失敗的情況下，有以下可能： **單個分片可以減慢索引** 因為主分片等待每個操作中設置的在線副本中的所有副本，所以單個緩慢的分片可能會減慢整個復制組的速度。這是我們為上述讀取效率付出的代價。當然，單個緩慢的分片也會減慢已經發送給它的不幸的搜索。 **臟讀** 孤立的主分片可以暴露不被確認的寫入。這是由于隔離的主分片只有在向其副本發送請求或者向主節點發送請求時才會被隔離。在這一點上，操作已經被索引到主分片并且可以通過并發讀取。Elasticsearch通過每秒鐘（默認情況下）ping主節點來減輕這種風險，如果沒有主節點，則拒絕索引操作。 ## 冰山提示 本文檔提供了Elasticsearch如何處理數據的高級概述。當然，底下還有更多更多的事情。諸如主要術語，集群狀態發布和主節點選舉等都起到了保持系統運行正常的作用。本文檔不包括已知和重要的bug（已關閉和打開）。我們認識到[GitHub](https://github.com/elastic/elasticsearch/issues?q=label%3Aresiliency)很難跟上。為了幫助大家掌握，我們在我們的網站上維護一個專用的[彈性頁面](https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html)。我們強烈建議您閱讀。 > my note > > 基礎寫模型 > 基礎讀模型 > [剖析Elasticsearch集群系列](http://blog.csdn.net/zlh3955649)(共三篇)