Document APIs

本節首先簡要介紹Elasticsearch的數據複製模型，而後詳細描述如下CRUD API：

Single document APIs

Index API
Get API
Delete API
Update API

Multi-document APIs

Multi Get API
Bulk API
Delete By Query API
Update By Query API
Reindex API
注意：全部CRUD API都是單索引API。 index參數接受單個索引名稱或指向單個索引的別名。

讀取和寫入文檔

介紹

Elasticsearch中的每一個索引會分紅多個分片，每一個分片能夠有多個副本。 這些副本被稱爲複製組（replication group），在添加或刪除文檔時必須保持同步。 不然會致使從不一樣的副本查詢出來的結果不一致。 保持分片副本同步並提供讀取操做的過程就是咱們所說的數據複製模型（data replication model）。

Elasticsearch的數據複製模型基於primary-backup模型，在微軟研究院的PacificA論文中有很好的描述。
該模型基於複製組的一個副本，該副本充當主分片（primary shard）。其餘副本稱爲副本分片（replica shards）。主分片是全部索引操做的主要入口點，負責校驗並確保操做是正確的。一旦索引操做被主分片接受，主分片也負責將操做複製到其餘副本。

本節的目的是高度概述Elasticsearch複製模型，並討論它對寫入和讀取操做之間各類交互的影響。

基本寫入模型

Elasticsearch中的每一個索引操做首先使用路由（一般基於文檔ID）解析到對應的複製組。 一旦肯定了複製組，該操做就會在內部轉發到組的當前主分片。 主分片負責校驗操做並將其轉發給其餘副本。 因爲副本可能脫機，所以主分片不須要把該操做複製到全部副本。相反，Elasticsearch維護應該接收操做的分片副本列表。 該列表稱爲同步副本（in-sync copies），由主節點（master node）維護。 顧名思義，這是一組「好」的分片副本，保證已經處理了全部索引和刪除操做。 主分片負責維護此不變量（前面說同步副本由master維護。這裏又說由primary維護，困惑），所以必須將全部操做複製到此集合中的每一個副本。

主分片遵循如下基本流程：
驗證傳入操做，拒絕結構無效的操做(例如：傳入一個對象字段，但指望的是一個數字)
在本地執行操做，即索引或刪除相關文檔， 這也將驗證字段的內容並在須要時拒絕（例如：關鍵字值在Lucene中索引太長）。
將操做轉發到當前同步副本集中的每一個副本。 若有多個副本，會並行完成。
一旦全部副本都成功執行操做並響應給了主分片，主分片就會確認已成功地完成了客戶端的請求。

失敗處理
索引期間不少事情均可能出錯 --磁盤可能損壞，節點可能互相斷開鏈接，或者某些配置錯誤可能致使某個副本上的操做失敗，儘管它在主分片上成功了。 這些並不常見，但主分片仍是要對它們作出迴應。

主分片自己發生故障的時，主分片所在的節點將向master（主節點）發送一條消息。 該索引操做將等待（默認狀況下最多1分鐘），以便maser將其中一個副本提高爲新的主分片。 該操做將被轉發到新的主分片進行處理。 請注意，master還監視節點的運行情況，並可能決定主動降級主分片。好比網絡問題，持有主分片的節點與集羣隔離時，一般會發生這種狀況。更多詳情請看這裏。

一旦在主分片（primary）上成功執行了操做，在副本分片（replica shards）上執行時，主分片（primary）還需處理潛在的失敗，失敗可能來源於：

• 在副本上執行失敗了
• 因爲網絡問題副本未接收到操做(或副本的響應沒法接收)。

全部執行失敗的這些分片具備相同的結果：一個副本是同步複製集（in-sync replica set）的一部分，若是錯過了即將被確認的操做。爲了不違反不變量，主分片會向主節點（master）發送一條消息，請求將有問題的碎片從同步複製集中刪除。只有主節點（master）確認移除分片後，主分片（primary）纔會確認操做。請注意，主節點（master）還會指示另外一個節點開始構建新的分片副本，以便將系統恢復到健康狀態。

在將操做轉發給副本時，主分片將使用該副原本驗證它是否仍然處於活動狀態。若是主分片因爲網絡問題（或長時間的GC）而被隔離，它可能會繼續處理傳入的索引操做，而後才意識到本身已被降級。已降級的主分片接收的操做不會被副本認可。當它收到來自副本拒絕的響應後，那麼它將與主節點（master）聯繫並知道它已被替換。而後該操做被路由到新的主分片。

假如沒有副本會發生什麼呢？
這是一個有效的場景，多是因爲索引配置，或者僅僅是由於全部的副本都失敗了。在這種狀況下，主分片處理操做，而不須要任何外部驗證，這可能看起來有問題。
另外一方面，主分片不能捨棄其餘分片，但會請求主節點（master）表明它執行此操做。這意味着主節點（master）知道主分片是惟一的好的副本。咱們會所以保證主節點（master）不會將任何其餘(過期的)分片副本提高爲一個新的主分片，而且任何索引到主分片的操做都不會丟失。固然，物理硬件問題可能致使數據丟失。請參閱 Wait For Active Shards 。

基本讀模型

Elasticsearch中的讀取操做能夠經過ID進行很是輕量級的查找，也能夠經過複雜的聚合進行重量級的搜索請求，這些請求會佔用大量的CPU資源。主從複製（primary-backup）的一個優勢是它能夠保持全部分片副本一致(with the exception of in-flight operations)。所以，單個同步副本足以知足讀取請求。

當某個節點收到讀取請求時，該節點負責將其轉發到相關分片的節點，整理響應並響應客戶端。咱們稱該節點爲該請求的協調節點（coordinating node）。基本流程以下：

解析讀請求到相關的分片。注意，因爲大多數搜索將被髮送到一個或多個索引，它們一般須要從多個分片讀取，每一個分片表示不一樣的數據子集。
從分片複製組中選擇每一個相關分片的活動副本。這能夠是主分片或副本。默認狀況下，Elasticsearch只會在分片的副本間循環。
將分片級別的讀請求發送到所選副本。
結合結果並作出迴應。請注意，在經過ID查找的狀況下，只有一個分片是相關的，該步驟能夠被跳過。

失敗處理
當分片沒法響應讀取請求時，協調節點將從同一複製組中選擇另外一個副本，並將分片級別搜索請求發送到該副本。 重複性故障可能致使沒有可用的分片副本。 在某些狀況下，好比_search，Elasticsearch會更傾向於快速響應，可能會只有部分結果，而不是等待問題獲得解決（部分結果在響應的_shards頭中）。

一些簡單的含義

這些基本流程中的每個都決定了Elasticsearch做爲讀寫系統的行爲。 此外，因爲讀取和寫入請求能夠同時執行，所以這兩個基本流程相互做用。 這有幾個內在的含義：

有效的讀取
在正常操做下，每一個相關複製組執行一次讀取操做。 只有在失敗狀況下，同一個分片的多個副本纔會執行相同的搜索。
讀未確認
因爲主分片首先在本地創建索引，而後複製請求，所以併發讀取可能在未確認的狀況下就被讀取。
默認兩個副本
該模型能夠容錯，同時只保留兩個數據副本。 這與quorum-based 系統相反，該系統容錯的最小副本數爲3。

Failures

在失敗的狀況下，如下是可能的：

單個分片會減慢索引
因爲主分片在每次操做期間都會等待設置同步副本中的全部副本，所以單個慢分片會減慢整個複製組的速度。 這是咱們爲上述讀取效率付出的代價。 固然，一個緩慢的分片也會減慢已經發送給它的搜索。
髒讀
一個孤立的主分片能夠暴露不被確認的寫入。 這是因爲一個孤立的主分片只有在向其副本發送請求或向主節點（master）發送請求時纔會將其隔離。 此時該操做已經被索引到主分片，並能夠被併發讀取。 Elasticsearch經過每秒（默認狀況下）對主節點（master）執行ping操做，在沒有發現主節點（master）存在的狀況下拒絕索引操做來減輕風險。

冰山一角
本文檔提供了Elasticsearch如何處理數據的高級概述。 固然，還有不少事情要作。 諸如primary terms， cluster state publishing 和 master election 等都在保持系統正常運行方面發揮了做用。 本文檔也不涵蓋已知和重要的錯誤（包括已關閉和打開）。 咱們認識到GitHub很難跟上。 爲了幫助人們保持最佳狀態，在咱們的網站上維護了專用的彈性頁面。 強烈建議你閱讀它。

官方文檔：https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-replication.html