Elasticsearch6.x文檔API之讀寫文檔

1.簡介

Elasticsearch中的每個索引都分為碎片 ，每個碎片可以有多個副本。這些副本稱為復制組，在添加或刪除文檔時必須保持同步。

如果我們不這樣做，將導致從一個副本中讀取與從另一個副本中讀取的數據截然不同的結果。

保持碎片副本同步並從中提供讀取的過程就是我們所說的數據復制模型。

Elasticsearch的數據復制模型基於主備份模型，並在Pacific Research的論文中得到了很好的描述 。

該模型使用一個數據集作為主分片。其他數據集稱為副本分片。主分片作為所有索引操作的主要入口點。它負責驗證它們並確保它們是正確的。一旦主分片接受了索引操作，其負責將操作復制到其他副本。

本節的目的是對Elasticsearch復制模型進行高級概述，並討論它對寫入和讀取操作之間的各種交互的影響。

2.基本的寫模型

Elasticsearch中的每個索引操作首先使用路由解析到特定的復制組（分片），通常基於文檔ID。

確定復制組后，操作將在內部轉發到組的當前主分片。主分片負責驗證操作並將其轉發到其他副本。由於副本可以脫機，因此不需要將主分片復制到所有副本分片。

相反，Elasticsearch維護應該接收操作的副本分片列表。此列表稱為同步副本並由主節點維護。顧名思義，這些是“好”分片副本的集合，保證已經處理了向用戶確認的所有索引和刪除操作。

主分片負責維護此不變量，因此必須將所有操作復制到此集合中的每個副本。

主分片遵循以下基本流程：

1. 驗證傳入操作並在結構無效時拒絕它（例如：定義為數字字段，但是傳過來的是一個對象類型）
2. 在本地執行操作，即索引或刪除相關文檔。這也將驗證字段的內容並在需要時拒絕（例如：關鍵字值太長，無法在Lucene中進行索引）。
3. 將操作轉發到當前同步副本集中的每個副本。如果有多個副本，則這是並行完成的。
4. 一旦所有副本成功執行了操作並響應主服務器，主服務器就會確認成功完成對客戶端的請求。

3.故障處理

在索引過程中可能會出現許多問題 - 磁盤可能會損壞，節點可能會相互斷開連接，或者某些配置錯誤可能導致復制副本上的操作失敗，盡管它在主服務器上成功。這些雖然很少見，但主分片必須處理它們。

在主分片本身發生故障的情況下，托管主分片的節點將向主節點(master)發送有關它的消息。

索引操作將等待（默認情況下最多1分鍾），以便master將其中一個副本分片提升為新的主分片。然后，該操作將被轉發到新的主分片處理。

請注意，主服務器還會監控節點的運行狀況，並可能決定主動降級主服務器。通過網絡問題發生時，通常會發生這種情況。

一旦在主分片上成功執行了操作，主服務器就必須處理在副本分片上執行它時潛在的故障。

這可能是由副本上的實際故障或由於網絡問題導致操作無法到達副本​​（或阻止副本響應）引起的。

所有這些都具有相同的最終結果：作為同步副本集的一部分的副本錯過了即將被確認的操作。為了避免違反不變量，主分片向master節點發送消息，請求從同步副本集中刪除有問題的分片。

只有在master上確認要刪除分片后，主分片才會應答此操作的結果。請注意，master還將指示另一個節點開始構建新的shard副本，以便將系統恢復到正常狀態。

在將操作轉發到副本時，主分片將使用副本來驗證它仍然是有效主分片。如果主要由於網絡分區（或長GC）而被隔離，則它可能會在意識到它已被降級之前繼續處理傳入的索引操作。來自過時主分片的操作將被副本分片拒絕。

當主分片收到來自副本的拒絕其請求響應時，因為它不再是主分片，那么它將聯系master節點並將知道它已被替換。然后將操作路由到新主分片。

如果沒有副本分片會怎么樣？

這是一個有效的方案，可能由於索引配置或僅因為所有副本都已失敗而發生。在這種情況下，主要是處理操作而沒有任何外部驗證，這可能看起來有問題。

另一方面，master知道主分片是唯一的單個良好副本。因此，我們保證master不會將任何其他（過時的）分片副本提升為新主分片，並且任何索引到主分區的操作都不會丟失。當然，由於此時我們只使用單個數據副本運行，因此物理硬件問題可能會導致數據丟失。

4.基本讀模型

Elasticsearch中的讀取可以是ID非常輕量級的查找，也可以是具有復雜聚合的大量搜索請求，這些聚合會占用很多的CPU能力。

主備份模型的一個優點是它使所有分片副本保持相同（除了正在進行的操作）。因此，單個同步副本足以提供讀取請求。

當節點收到讀取請求時，該節點負責將其轉發到保存相關分片（根據路由）的節點，收集整理響應並響應客戶端。我們將該節點稱為該請求的協調節點。基本流程如下：

1. 將讀取請求解析為相關分片。請注意，由於大多數搜索將被發送到一個或多個索引，因此它們通常需要從多個分片中讀取，每個分片代表數據的不同子集。
2. 從分片復制組中選擇每個相關分片的活動副本。這可以是主分片或副本分片。默認情況下，Elasticsearch將簡單地在分片副本之間循環。
3. 將分片級讀取請求發送到所選副本。
4. 收集整理結果並做出回應。請注意，在通過ID查找的情況下，只有一個分片是相關的，可以跳過此步驟。

5.故障處理

當分片無法響應讀取請求時，協調節點將從同一復制組中選擇另一個副本分片，並將分片級別搜索請求發送到該副本。

重復失敗可能導致沒有可用的分片副本。在某些情況下，例如_search，Elasticsearch更願意快速響應，盡管有部分結果，而不是等待問題得到解決（部分結果顯示在_shards響應的標題中）。

6.一些簡單的含義

由於讀取和寫入請求可以同時執行，因此這兩個基本流程彼此交互。這有一些固有的含義：

高效的讀

在正常操作下，對每個相關復制組執行一次讀取操作。只有在失敗條件下，同一個分片的多個副本才會執行相同的搜索。

讀未確認的

由於主分片先在本地索引然后復制請求，因此並發讀取可能在確認之前（副本尚未完成）已經看到了更改。

默認情況下為兩份

此模型可以容錯，同時僅保留兩個數據副本。這與基於法定數量的系統形成對比，其中容錯的最小副本數為3。

7.失敗

在失敗的情況下，以下是可能的情況：

單個分片故障會減慢索引搜索速度

由於主分片在每個操作期間等待同步副本集中的所有副本，因此單個慢速分片可能會降低整個復制組的速度。這是我們為提高讀效率付出的代價。當然，單個慢速分片也會減慢路由到它的搜索請求。

臟讀

隔離的主分片可以暴露無法收到應答的寫入入口。這是因為隔離的主分片只有在向其副本發送請求或向master node發送請求時才會意識到它是隔離的。

此時，操作已經索引到主分片中，並且可以通過並發讀取來讀取。Elasticsearch通過每秒ping一次master node（默認情況下）並在沒有master應答的情況下拒絕索引操作來減輕這種風險。

8.冰山一角

本文檔提供了Elasticsearch如何處理數據的高級概述。當然，還有很多事情要發生。term，集群狀態和主選舉等都可以在保持系統正常運行方面發揮作用。

為了幫助人們掌控這些，我們 在我們的網站上維護了一個專用的頁面。我們強烈建議閱讀它。