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