1. 程式人生 > >Elasticsearch——讀寫文件

Elasticsearch——讀寫文件

目錄

1.介紹

故障處理

故障處理

5.故障

1.介紹

Elasticsearch中的每一個索引都會被切片然後每一個切片都會有多份複製。

這些複製被稱作複製組,並且當文件被新增或移除時,複製組中的複製必須保證同步。

如果做不到這一點,從一個複製中讀取的結果將與從其他複製中讀取的結果有很大的不同。

保證切片複製之間的同步並且基於此提供讀服務的過程稱之為資料備份模型。

Elasticsearch的資料備份模型基於主-備份模型。

此模型基於讓備份組中的一份單獨複製作為主切片實現。其他的複製稱為備份切片。

主切片作為所有索引操作的主進入點。它負責驗證這些操作,以確保它們正確。

當一個索引操作被主切片接收後,主切片負責將這些操作複製給其他的備份切片。

2.基礎寫模型

Elasticsearch中的每一個索引操作通常基於文件ID解析給使用路由備份組。

一旦備份組被確認,此操作便會在內部轉發給備份組的當前主切片。主切片負責驗證操作並將其轉發給其他的備份切片。

由於副本可以離線,主切片不需要將操作複製給所有的備份切片。

相反,Elasticsearch維護一份應該接收操作的備份切片的列表。這個列表稱為in-sync cpoies,由master結點維護。

這個列表中的切片保證完成使用者承認的索引與刪除操作。

由於主切片負責保證不變性,所以主切片會將操作複製給此列表中的每一個備份切片。

主切片遵從以下基本流:

  1. 驗證進入的操作,如果結構上無效(例如:物件欄位中設定了數字),拒絕操作。
  2. 本地執行操作,此時仍會驗證欄位內容陪,如果有必要(例如:關鍵字值對於Lucene索引過長),拒絕執行。
  3. 轉發操作給當前in-sync副本集合中的每一個副本。如果存在多個副本,並行執行此操作。
  4. 一旦所有的副本全部執行成功並且響應主切片,主切片向客戶端確認請求完成。

故障處理

在索引構建期間,許多事情都可能出現故障——硬碟可能損壞,結點可能失去與其他結點的連線或者一些錯誤的配置可能導致一個操作儘管在主切片上執行成功發但是在備份結點上執行失敗。

這些錯誤較為罕見,但是主切片需要應對它們。

當主切片自身出錯時,持有主切片的結點會向主伺服器傳送一條資訊。

索引操作會等待一分鐘左右,等待主伺服器將一個備份切片提為主切片。

然後索引操作會被髮給新的主切片進行執行。

注意主伺服器還會監控結點健康狀態,可能會主動給主切片降級。這通常發生在主切片因為網路問題從叢集中獨立時。

一旦操作在主切片上成功執行,主切片就不得不應對當將操作執行在備份切片上時潛在的執行失敗問題。

這可能由於備份切片上實際執行失敗,也可能由於網路問題,阻止了操作到達備份切片或阻止了備份切片的迴應。

所有這些都導致了一個相同的結果:in-sync備份集合中的一個備份切片錯過了一個即將被承認的操作。

為了防止損害不變性,主切片向主伺服器傳送了一條資訊請求從in-sync備份集合中移除有問題的切片。

只有主伺服器承認切片的移除,主伺服器才會承認此操作。

注意,主伺服器還會指示其他結點開始構建新的切片副本用以恢復系統的健康狀態。

當主切片轉發操作給備份切片時,主切片將會使用備份切片檢驗自身是否仍是活動主切片。

如果主切片由於網路分割槽或長GC從叢集中脫離,在它意識到自身已經被降級之前,它可能會繼續執行進入的索引操作。

來自過期主切片的操作將會被備份切片拒絕。

當主切片接收到由於自身不再是主切片而被備份切片拒絕請求的迴應時,它將會向主伺服器發出詢問然後得知自身已經被取代。

操作已經按路徑傳送到新的主切片。

如果不存在備份切片會發生什麼?

由於索引配置或只是因為所有的備份全部掛了,所以這是一個可能發生的有效場景。

在這種情況下,主切片在沒有外部檢驗的情況下執行操作,這似乎存在問題。

另一方面,主切片不會在自身上的其他切片上執行操作失敗,但是會請求主切片代替自身這樣做。

這意味著,主伺服器知道主切片時唯一的可用備份。

因此主伺服器不會將其他(過期)切片備份提升為新的主切片,並且任何主切片執行的操作都不會丟失。

當然,因為在這時只有一份資料備份切片在工作,所以物理硬體問題將會造成資料丟失。

3.基礎讀模型

Elasticsearch中的讀操作可以是通過ID實現的輕量級查詢,也可以是呼叫CPU大量效能的伴隨著複雜聚合的重量級搜尋請求。

主-備份模型的一個優勢就是它保持所有的切片副本相同。因此,單個in-sync備份足以服務度讀請求。

當一個結點接收到一個讀請求,此結點將會將其傳送給持有相關切片的其他結點,整理迴應,然後響應客戶端。此節點稱為協調結點。

基本流如下:

  1. 解析讀請求到相關切片。注意由於搜尋將會被髮送給一個或多個索引,它們通常需要從多個切片中進行讀操作,每個切片代表資料的不同子集。
  2. 從備份切片組中選出每份相關切片的活躍備份。這可以是主切片也可以是備份切片。預設情況下,Elasticseach將會在切片備份中迴圈。
  3. 傳送切片級讀請求到選出的備份。
  4. 結合請求與響應。注意在通過ID進行查詢的情況下,只有一個切片相關並且這個步驟被跳過。

故障處理

當一個切片沒能響應讀請求時,協調結點將會從相同備份組中選出其他備份,並且將切片級請求傳送給備份。

反覆的失敗可能導致沒有切片備份可用。

在某些情況下,例如_search,Elastisearch傾向於快速響應,儘管只有部分結果,代替等待問題被解決(部分結果將會在響應的_shards首部表示)。

4.一些簡單的影響

這些基礎流決定了Elasticsearch應對讀與寫的行為。而且,由於讀與寫請求可以併發執行,這兩個基本流互相影響彼此。

高效讀

在正常操作下,每個讀操作會在每個相關備份組上執行一次。只有在失敗條件下,會在多分相同片的備份上執行相同搜尋。

不被承認的讀

由於主切片先本地執行索引操作,然後再複製請求,所以在寫操作被承認之前,一個併發讀操作可能看見這個變化。

預設兩個備份

此模型同時維護兩份備份便可以容錯。這與基於合法數量的系統需要最少三分備份才能完成容錯不同。

5.故障

單備份切片會降低索引速度

因為主切片在執行每一個操作期間都會等待in-sync備份集合中所有的切片完成操作,所以單個切片會減慢整個備份組的執行速度。當然,單切片的執行緩慢也會減緩路由到此切片的搜尋操作。

髒讀

離線主切片可以暴露不被承認的寫操作。這是因為只有當離線主切片傳送請求到備份副本或接觸主伺服器之後,離線主機才會意識到自己已經離線。此時,一個索引操作已經在此主切片上執行,並且可以被併發讀讀取。Elasticsearch通過每秒(預設)ping一次主機並且如果ping不到主伺服器時拒絕索引操作來降低髒讀的風險。