ES建立、索引和删除文檔的節點執行情況
以下是在主副分片和任何副本分片上面 成功建立，索引和删除文檔所需要的步驟順序：
- 用戶端向 Node 1 發送建立、索引或者删除請求。
- 節點使用文檔的 _id 确定文檔屬于分片 0 。請求會被轉發到 Node 3
，因為分片 0 的主分片目前被配置設定在
- Node 3 在主分片上面執行請求。如果成功了，它将請求并行轉發到 Node 1 和 Node 2 的副本分片上。一旦所有的副本分片都報告成功, Node 3 将向協調節點報告成功，協調節點向用戶端報告成功。
- 在用戶端收到成功響應時，文檔變更已經在主分片和所有副本分片執行完成，變更是安全的。
取回單個文檔
可以從主分片或者從其它任意副本分片檢索文檔
以下是從主分片或者副本分片檢索文檔的步驟順序：
- 用戶端向 Node 1 發送擷取請求。
- 節點使用文檔的 _id 來确定文檔屬于分片 0 。分片 0 的副本分片存在于所有的三個節點上。 在這種情況下，它将請求轉發到 Node 2 。
- Node 2 将文檔傳回給 Node 1 ，然後将文檔傳回給用戶端。
在處理讀取請求時，協調結點在每次請求的時候都會通過輪詢所有的副本分片來達到負載均衡。
在文檔被檢索時，已經被索引的文檔可能已經存在于主分片上但是還沒有複制到副本分片。 在這種情況下，副本分片可能會報告文檔不存在，但是主分片可能成功傳回文檔。 一旦索引請求成功傳回給使用者，文檔在主分片和副本分片都是可用的。
局部更新文檔
以下是部分更新一個文檔的步驟：
- 用戶端向 Node 1 發送更新請求。
- 它将請求轉發到主分片所在的 Node 3 。
- Node 3 從主分片檢索文檔，修改 _source 字段中的 JSON ，并且嘗試重新索引主分片的文檔。 如果文檔已經被另一個程序修改，它會重試步驟 3 ，超過 retry_on_conflict 次後放棄。
- 如果 Node 3 成功地更新文檔，它将新版本的文檔并行轉發到 Node 1 和 Node 2 上的副本分片，重建立立索引。 一旦所有副本分片都傳回成功， Node 3 向協調節點也傳回成功，協調節點向用戶端傳回成功。
基于文檔的複制
當主分片把更改轉發到副本分片時， 它不會轉發更新請求。 相反，它轉發完整文檔的新版本。請記住，這些更改将會異步轉發到副本分片，并且不能保證它們以發送它們相同的順序到達。 如果Elasticsearch僅轉發更改請求，則可能以錯誤的順序應用更改，導緻得到損壞的文檔。
多文檔模式
mget 和 bulk API 的 模式類似于單文檔模式。差別在于協調節點知道每個文檔存在于哪個分片中。 它将整個多文檔請求分解成 每個分片 的多文檔請求，并且将這些請求并行轉發到每個參與節點。
協調節點一旦收到來自每個節點的應答，就将每個節點的響應收集整理成單個響應，傳回給用戶端。
圖 . 使用 mget 取回多個文檔
以下是使用單個 mget 請求取回多個文檔所需的步驟順序：
- 用戶端向 Node 1 發送 mget 請求。
- Node 1 為每個分片建構多文檔擷取請求，然後并行轉發這些請求到托管在每個所需的主分片或者副本分片的節點上。一旦收到所有答複， Node 1 建構響應并将其傳回給用戶端。
可以對 docs 數組中每個文檔設定 routing 參數。
圖 . 使用 bulk 修改多個文檔
bulk API 按如下步驟順序執行：
- 用戶端向 Node 1 發送 bulk 請求。
- Node 1 為每個節點建立一個批量請求，并将這些請求并行轉發到每個包含主分片的節點主機。
- 主分片一個接一個按順序執行每個操作。當每個操作成功時，主分片并行轉發新文檔（或删除）到副本分片，然後執行下一個操作。 一旦所有的副本分片報告所有操作成功，該節點将向協調節點報告成功，協調節點将這些響應收集整理并傳回給用戶端。
bulk API 還可以在整個批量請求的最頂層使用 consistency 參數，以及在每個請求中的中繼資料中使用 routing 參數。