本節簡要介紹elasticsearch的資料複製模型。
elasticsearch中的每個索引都分為碎片，每個碎片可以有多個副本，這些副本稱為複製組，在新增或刪除文件時必須保持同步。如果我們不這樣做，從乙個副本中讀取將導致與從另乙個副本讀取的結果截然不同，保持碎片副本同步並從中提供讀取的過程就是我們所說的資料複製模型。
elasticsearch的資料複製模型基於主備模型，並在微軟研究院的pacifica *******中得到了很好的描述。該模型基於從複製組中持有乙個副本作為主碎片，其他副本稱為副本碎片。主碎片服務作為所有索引操作的主要入口點，它負責驗證它們並確保它們是正確的，一旦主碎片接受了索引操作，主碎片負責將操作複製到其他副本。
本節的目的是對elasticsearch複製模型作乙個高層次的概述，並討論它對讀和寫操作之間的各種互動的影響。
elasticsearch中的每個索引操作首先使用路由解析為乙個複製組，通常基於文件id，一旦確定了複製組，操作將在內部**到當前組的主碎片，主碎片負責驗證操作並將其**到其他副本。由於副本可以離線，主碎片不需要複製到所有副本，相反，elasticsearch維護乙個應該收到操作的碎片副本列表，這個列表稱為同步副本，由主節點維護。顧名思義，這些是一組「好的」碎片副本，它們保證已經處理了已向使用者確認的所有索引和刪除操作，主碎片負責維護這個不變數，因此必須將所有操作複製到這個集合中的每個副本。
主碎片遵循這個基本流程：
驗證傳入的操作並在結構上無效時拒絕它（例如：有乙個物件字段，其中乙個數字是預期的）。
將操作**到當前同步副本集合中的每個副本，如果有多個副本，則並行執行。
一旦所有副本都成功地執行了操作並響應了主碎片，主碎片就會對客戶端確認請求已經成功完成。
在索引過程中，許多事情都可能出錯 - 磁碟可能會損壞、節點之間可能斷開連線、或某些配置錯誤可能導致副本上的操作失敗，儘管它在主碎片上是成功的，這種情況並不常見，但主碎片必須對其作出響應。
在主碎片失敗的情況下，主碎片所在的節點將向主節點傳送關於主碎片失敗的訊息，索引操作將等待（預設情況下最多1分鐘），以便主節點將乙個副本提公升為乙個新的主碎片。然後，操作將被**到新的主碎片進行處理，注意，主節點還監控節點的健康狀況，並可能決定主動降級主碎片，這通常發生在持有主碎片的節點由於網路問題與集群隔離時。
在主碎片上成功執行操作之後，當在副本碎片上執行操作時，主碎片必須處理潛在的故障，這可能是由於副本上的實際故障，或者是由於網路問題阻止操作到達副本（或者阻止副本響應）。所有這些都有相同的最終結果：同步副本集合中的乙個副本錯過乙個將要被確認的操作，為了避免違反不變數，主碎片向主節點傳送一條訊息，請求從同步副本集合中刪除有問題的碎片。只有在主節點確認移除碎片後，主碎片才會確認操作，注意，主節點還將指示另乙個節點開始構建乙個新的碎片副本，以便將系統恢復到健康狀態。
這是乙個由於索引配置或僅僅因為所有副本都失敗而可能發生的有效場景，在這種情況下，主碎片是在沒有任何外部驗證的情況下處理操作，這可能看起來有問題，另一方面，主碎片本身不能使其他碎片失敗，但請求主節點代表它這樣做，這意味著主節點知道主碎片是唯一乙個好的副本。因此，我們保證主節點不會將任何其他（過期的）碎片副本提公升為新的主碎片，並且主碎片中索引的任何操作都不會丟失，當然，因為此時我們只執行資料的乙個副本，所以物理硬體問題可能導致資料丟失。
在elasticsearch中的讀可以是非常輕量的通過id的查詢，也可以是使用複雜聚合的繁重搜尋請求，而複雜的聚合會占用大量的cpu資源。主備模型的優點之一是保持所有碎片副本相同（除了飛行的操作之外），因此，乙個同步副本就足以服務於讀請求。
將讀請求解析到相關的碎片，注意，由於大多數搜尋將被傳送到乙個或多個索引，它們通常需要從多個碎片中讀，每個碎片代表資料的不同子集。
從碎片複製組中選擇每個相關碎片的活動副本，這可以是主碎片，也可以是副本，預設情況下，elasticsearch將會在碎片副本之間進行簡單的迴圈負載。
將碎片級別的讀請求傳送到選中的副本。
組合結果和響應，注意，在get by id查詢的情況下，只有乙個碎片是相關的，可以跳過這一步。
當碎片無法響應讀請求時，協調節點將從同一複製組中選擇另乙個副本，並將碎片級搜尋請求傳送到該副本，重複的失敗會導致碎片副本不可用。在某些情況下，比如_search，elasticsearch將更喜歡快速響應，儘管會得到部分結果，而不是等待問題得到解決（響應的_shards頭中顯示了部分結果）。
這些基礎流中的每乙個都決定了elasticsearch作為讀寫系統的行為，此外，由於讀寫請求可以併發執行，這兩個基本流相互互動，這有一些內在的含義：
高效的讀
未確認的讀
預設為兩個副本
在故障的情況下，以下是可能的情況：
單個碎片可以減慢索引速度
髒讀
孤立的主碎片可以公開不被承認的寫操作，這是由這樣乙個事實引起的：乙個孤立的主碎片只有在向其副本傳送請求或與主節點接觸時才會意識到它是孤立的，這時，操作已經被索引到主碎片中，並且可以被併發讀取，elasticsearch通過每秒ping一次主節點（預設情況下）並在如果不知道主節點的情況下拒絕索引操作來減輕這種風險。
本文件提供了elasticsearch如何處理資料的高層次概述，當然，在引擎下還有很多事情要做，像主碎片項、集群狀態發布和主節點擊舉等都在保持系統正常執行方面發揮了作用，本文件也沒有已知的和重要的bug（關閉和開啟），我們認識到github很難跟上，為了幫助人們保持在這些之上，我們在我們的**上維護乙個專用的彈性頁面，我們強烈建議你閱讀它。
Elasticsearch 參考指南（全文查詢）
高階全文查詢通常用於在全文本段 如電子郵件正文 上執行全文查詢，它們了解如何分析被查詢的字段，並將在執行之前將每個欄位的analyzer 或search analyzer 應用到查詢字串。本組中的查詢為 matchquery match phrasequery match phrase prefix...
Elasticsearch 參考指南（清除快取）
清除快取api允許清除與乙個或多個索引關聯的所有快取或特定快取。post twitter cache clear預設情況下，api將清除所有快取，可以通過設定query，fielddata或request來明確清除特定的快取。還可以通過使用相關欄位的逗號分隔列表指定字段引數來清除與特定字段相關的所有...
（0 1）elasticsearch參考學習路徑
elk系列 一 安裝elasticsearch logstash kibana filebeat v7.7.0 elk系列 二 在kibana中使用restful操作es庫 elk系列 三 安裝logstash外掛程式及打包離線安裝包 elk系列 四 logstash讀取nginx日誌寫入es中 e...