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