摘要：節(jié)點使用文檔的確定文檔屬于。將文檔返回給，然后將文檔返回給客戶端。如果文檔已經(jīng)被另一個進程修改沖突，它會重試步驟，超過次后放棄。當一個子請求操作成功時，并行轉發(fā)新文檔或刪除到，然后執(zhí)行下一個子請求。

確定shard的公式：

shard = hash(routing) % number_of_primary_shards

routing 默認是文檔的 _id ，也可以設置成一個自定義的值。

因此要在創(chuàng)建索引的時候就確定好主分片的數(shù)量，并且永遠不會改變這個數(shù)量，因為如果數(shù)量變化了，那么所有之前路由的值都會無效。

每個節(jié)點都知道集群中任一文檔位置，所以可以直接將請求發(fā)到任意節(jié)點。當然，為了擴展負載，更好的做法是輪詢發(fā)送集群中所有的節(jié)點。

步驟：

戶端向 Node 1 發(fā)送新建、索引或者刪除請求。

節(jié)點使用文檔的 _id 確定文檔屬于shard 0 。請求會被轉發(fā)到 Node 3（因為shard 0 被分配在 Node 3 上）。

Node 3 在shard 0上面執(zhí)行請求。如果成功了，它將請求并行轉發(fā)到 Node 1 和 Node 2 的replica R0上。一旦所有的R0都報告成功, Node 3 將向Node 1報告成功，Node 1向客戶端報告成功。

步驟：

客戶端向 Node 1 發(fā)送查詢請求。

node 1使用文檔的 _id 來確定文檔屬于shard 0 。replica 0 存在于Node 1、Node 2上。 這種情況下，每次請求都會輪詢路由Node 1、Node 2，這里假設路由到Node 2。

Node 2將文檔返回給Node 1 ，然后Node 1將文檔返回給客戶端。

注意：
在文檔被檢索時，已經(jīng)被索引的文檔可能已經(jīng)存在于shard上但是還沒有復制到replica。即強一致性無法保證，但最終一致性可以保證。

POST /{index}/{type}/{id}/_update

步驟略。
注意：
Node 3 從P0檢索文檔，修改 _source 字段中的 JSON ，并且嘗試重新索引主分片的文檔。 如果文檔已經(jīng)被另一個進程修改（_version沖突），它會重試步驟 3 ，超過 retry_on_conflict 次后放棄。
如果 Node 3 成功地更新文檔，它將新版本的文檔并行轉發(fā)（新建、索引或者刪除請求的步驟里轉發(fā)的是請求而不是文檔）到 Node 1 和 Node 2 上的R0，重新建立索引。一旦所有R0都返回成功，Node 3 向Node 1返回成功，Node 1向客戶端返回成功。

為什么要轉發(fā)文檔而不是請求？
因為轉發(fā)請求是異步的，不能保證到達replica的順序，若轉發(fā)更新請求，則可能以錯誤的順序應用更改，導致得到損壞的文檔。而轉發(fā)文檔，則replica可以直接根據(jù)_version來獲取最大版本號的文檔。

bulk步驟：

客戶端向 Node 1 發(fā)送 bulk 請求。

Node 1 為每個命中的shard創(chuàng)建一個批量請求，并將這些請求并行轉發(fā)到每個包含該shard的節(jié)點。

shard按順序（請求報文體中的子請求順序）執(zhí)行每個操作。當一個子請求操作成功時，shard并行轉發(fā)新文檔（或刪除）到replica，然后執(zhí)行下一個子請求。 一旦所有的子請求的replica向shard報告完成（無論執(zhí)行是否成功），該shard將向node 1報告，node 1將這些響應收集整理并返回給客戶端。

consistency

解決分布式腦裂問題，參數(shù)的值可以設為 one （只要該index的shard狀態(tài) ok 就允許執(zhí)行_寫_操作）,all（必須要該index的shard和多個replica的狀態(tài)沒問題才允許執(zhí)行_寫_操作）, 或 quorum （默認值）。

# quorum 即大于一半的分片，注意，number_of_replicas是primary shard對應的replica數(shù)量，不是全部replica數(shù)量
int( (primary + number_of_replicas) / 2 ) + 1

注意：新索引默認有 1 個replica，這意味著為了滿足consistency至少需要兩個活動的node。 這就會阻止我們在單一node上做任何事情。為了避免這個問題，ES要求只有當 number_of_replicas 大于1的時候，consistency策略才會執(zhí)行。

timeout
如果沒有足夠的replica，Elasticsearch會等待，直到滿足consistency策略。默認最多等待1分鐘。 你可以使用 timeout 參數(shù) 使它更早終止： 100 是100毫秒，30s 是30秒。

一個Lucene索引在Elasticsearch稱作shard。 一個Elasticsearch索引是shard的集合。