# Reading and Writing documents（讀寫文檔） 原文鏈接 : [https://www.elastic.co/guide/en/elasticsearch/reference/5.4/docs-replication.html](https://www.elastic.co/guide/en/elasticsearch/reference/5.4/docs-replication.html) 譯文鏈接 : [http://www.apache.wiki/pages/viewpage.action?pageId=10028500](http://www.apache.wiki/pages/viewpage.action?pageId=10028500) 貢獻者 : [那伊抹微笑](/display/~wangyangting)，[ApacheCN](/display/~apachecn)，[Apache中文網](/display/~apachechina) ### Introduction（介紹） 在 **Elasticsearch **中的每個索引都會被?[拆分成分片](https://www.elastic.co/guide/en/elasticsearch/reference/5.4/_basic_concepts.html#getting-started-shards-and-replicas)，并且每個分片都有多個副本。這些副本稱為?**_replication group_**（副本組）并且在刪除或者添加文檔的時候必須同步到各個副本。如果我們做不到這點，從不同副本中讀取的數據會不一致。我們把保持分片和副本之間的同步以及從中讀取的過程就是我們所說的?**data replication model**（數據復制模型）。 **Elasticsearch** 的?**data replication model**（數據復制模型）是基于**_primary-backup model_**?（主備模型）的，并且 **在Microsoft Research** 的 **PacificA paper?**中描述得非常好。該模型以來自 **replication group**（副本組，實際是主分片）的單個副本為基礎。其它副本叫做 **_replica shards_**（副本分片）。主分片是所有索引操作的入口。它負責驗證索引操作是否有效。一旦主分片接受一個索引操作，主分片的副本分片也會接受該操作。 本節的目的是給出 **Elasticsearch** **replication model**?的高級概述，并討論它對寫操作和讀操作之間的各種交互的影響。 ### Basic write model（基礎的寫模型） 每個索引操作首先會使用 **routing?**參數解析到 **replication group**（分片組，包含主分片和副本分片） ，通常基于文檔 **ID**。一旦確定 **replication group**，就會內部地轉發該操作到分片組的主分片中。主分片負責驗證操作和轉發它到其他副本分片。**Elasticsearch** 維護一個可以接收該操作的分片的副本列表。這個列表叫做 _**in-sync copies**_（同步中的副本）并由 **master** 節點維護。正如名字那樣，保證這些分片都會處理所有的索引和刪除操作，這些操作都會經過用戶確認。主分片負責維護不變性（各個副本保持一致），因此必須復制這些操作到列表中的每個副本。 主分片遵循以下基本流程 :? 1. 驗證操作，如果它的結構有錯就拒絕該操作（例如，對 **object?**字段指定一個數字值） 2. 在本地執行操作。即索引或刪除相關文檔。這也會驗證字段的內容，如果不通過就拒絕操作（例如，字段串的長度超出 **Lucene?**的定義的長度） 3. 轉發該操作到當前 **in-sync** 副本組的所有副本分片。如果有多個副本分片，會并行轉發。 4. 一旦所有的副本分片成功執行該操作就會返回給主分片，主分片把請求的成功執行的信息返回給用戶。 #### Failure handling（故障處理） 索引期間會發生很多錯誤 - 硬盤壞了，節點丟失和其他節點的連接，或者某些配置錯誤會導致不能在副本分片上執行某個操作，盡管該操作成功在主分片上執行。雖然這是罕見的，但是主分片必須匯報這些錯誤信息。 對于主分片自身錯誤的情況，它所在的節點會發送一個消息到?**master?**節點。這個索引操作會等待（[默認](https://www.elastic.co/guide/en/elasticsearch/reference/5.4/index-modules.html#dynamic-index-settings)?最多一分鐘）**master?**節點提升一個副本分片為主分片。這個操作會被轉發給新的主分片處理。注意?**master?**同樣會監控節點的健康，并且可能會主動降級主分片。這通常發生在主分片所在的節點和集群失去聯系的時候。點擊[這里](https://www.elastic.co/guide/en/elasticsearch/reference/5.4/docs-replication.html#demoted-primary)?查看更多細節。 一旦在主分片執行的操作成功，該主分片必須處理在副本分片上潛在發生的錯誤。錯誤發生的原因可能是，在副本分片上執行操作時發生的錯誤，也可能是因為網絡阻塞，導致主分片無法轉發操作到副本分片，或者副本分片無法返回結果給主分片。這些錯誤都會導致相同的結果 :?**in-sync replica set?**中的一個分片丟失一個即將要確認的操作。為了避免出現不一致，主分片會發送一條消息到?**master?**節點，要求它把有問題的分片從?**in-sync replica set?**中移除。 一旦?**master?**確認移除了該分片，主分片就會確認這次操作。注意?**master?**也會指導另一個節點建立一個新的分片副本，以便把系統恢復成健康狀態。 在轉發請求到副本分片時，主分片會使用副本分片來驗證它是否仍是一個活躍的主分片。如果主分片因為網絡原因（或很長的?**GC**）被隔離了，在它被降級之前它會繼續處理傳入的索引操作。來自陳舊的主分片的操作將會被副本分片拒絕。當主分片接收到來自拒絕其請求的響應時，因為它不再是主節點，所以它將會訪問到主節點，并且將會知道它已被替換。 然后將操作路由到新的主分片。 Note（注意）: **如果沒有副本會發生什么？** 這是一個有效的場景，由于索引配置或因為所有副本故障時會發生。這時候在沒有任何外部驗證的情況下處理該操作，可能會導致問題。另一方面，主分片不能使它的分片失效，但它會請求 **master** 使它們失效 。這意味著，**master** 知道只有主分片才是一個可用的副本。因此我們確保 **master** 不會提升任何其他分片副本（過時）為主分片，并且索引到主分片上的任何操作都不會丟失。當然，由于在這一點上，我們只運行單個的數據副本，因此物理硬件問題可能會導致數據丟失。 有關緩解這些問題的選項，請參閱 “[等待活動分片](https://www.elastic.co/guide/en/elasticsearch/reference/5.4/docs-index_.html#index-wait-for-active-shards)” 一節。 ### Basic read model（基礎的讀取模型） 通過 **id** 查找是非常輕量級的，一個巨大的復雜的聚合查詢請求需要消耗大量 **cpu** 資源。 **primary-backup model** 一個好處是保證所有的分片副本都是一致（正在執行的操作例外）。因此，單個 **in-sync** 副本也可以服務請求。 當一個讀請求被節點接收，這個節點負責轉發它到其他涉及相關分片的節點，并整理響應結果，發送給客戶端。我們叫這個節點為這個請求的 **_coordinating node_**（協調節點）。基本流程如下 :? 1. 把讀請求發送到相關分片。注意，因為大多數搜索都會發送到一個或多個索引，通常需要從多個分片讀取，每個分片都保存這些數據的一部分。 2. 從 **shard replication group?**選擇一個相關分片的活躍副本。它可以是一個主分片或者副本分片。默認情況下，**Elasticsearch** 會簡單地循環遍歷這些分片。 3. 發送一個分片級別的讀請求到被選中的副本中。 4. 合并結果和響應。注意針對通過 **id** 查找的 **get?**請求?，會跳過這個步驟，因為只有一個相關的分片。 #### Failure handling（故障處理） 當分片不能響應一個讀請求，協調節點會從?**replication group**?中選擇另一個副本，并發送請求到該副本代替不可用的副本。沒有可用的分片副本會導致重復的錯誤。某些情況下，**Elasticsearch**?更喜歡盡早響應，即使只有部分的結果，而不是等待問題解決（你可以在響應結果的?**_shards?**字段，檢查本次結果是完整的還是部分的） ### A few simple implications（一些簡單的含義） 每一個這樣的基礎流決定了 **Elasticsearch** 作為一個系統在讀和寫之間是如何表現的。此外，由于可以同時執行讀寫請求，所以這兩個基本流彼此相互作用。這有一些固有的含義 :? Efficient reads（高效讀取） ?在正常操作下，每個相關復制組執行一次讀取操作一次。只有在故障條件下，同一個分片的多個副本才能執行相同的搜索。 Read unacknowledged ?由于主分片首先在本地進行索引，然后復制請求，所以并發讀取可以在確認之前已經看到更改。 Two copies by default 該模型可以容錯，同時只保留兩個數據副本。這與?**quorum-based**?的系統相反，其中容錯的最小副本為 **3**。 ### Failures（故障） 在故障的情況下，可以進行以下操作 :? ?A single shard can slow down indexing（單個分片可以降低索引速度） 因為在每次操作時該主分片會等待所有在 **in-sycn**（同步中的）副本集合中的副本。所以單個 **slow** **shard**（緩慢的副本）可以減慢整個副本組的速度。這是我們為上述讀取效率付出的代價。當然，單個緩慢的分片也會減慢已經路由給它的 **unlucky searches**（不利的搜索）。 ?Dirty reads（臟讀） 隔離的主分片可以暴露不被確認的寫入。這是由于隔離的主要設備只有在向其副本發送請求或者向?**master?**發送請求時才會被隔離。在這一點上，操作已經被索引到主分片并且可以通過并發讀取獲得。**Elasticsearch**?通過每秒鐘（默認情況下）**ping master?**來降低這種風險，如果沒有 **master**，則拒絕索引操作。 ### The Tip of the Iceberg（部分建議） 本文檔提供了 **Elasticsearch**如何處理數據的高級概述。當然，真實情況還要更復雜。考慮下主要的術語，集群狀態發布和 **master**?選舉等都起到了保持系統正常運行的作用。本文檔不包括已知和重要的錯誤（已關閉和打開）。我們認識到?[GitHub 很難跟上](https://github.com/elastic/elasticsearch/issues?q=label%3Aresiliency)。為了幫助這些人，我們在我們的網站上維護一個專用的?[resiliency page](https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html)?。我們強烈建議您閱讀。