一、文檔分佈到集羣
1.路由規則
索引一個文檔的時候，文檔會被存儲到一個主分片中，Elasticsearch需要一種規則來確定具體分佈到哪個主分片上面，因爲一般會有多個主分片存在，這個規則如下：
shard = hash(routing) % number_of_primary_shards
routing 是一個可變值，默認是文檔的 _id ，也可以設置成一個自定義的值，routing 通過 hash 函數生成一個hash值，然後這個數值再除以 number_of_primary_shards （主分片的數量）後得到餘數 。這個餘數分佈在 0 到 number_of_primary_shards-1 之間，這就是我們所尋求的文檔所在分片的位置。
我們要在創建索引的時候就確定好主分片的數量，並且永遠不會改變這個數量：因爲如果數量變化了，那麼所有之前路由的值都會無效，文檔也再也找不到了。
所有的文檔 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一個叫做 routing 的路由參數 ，通過這個參數我們可以自定義文檔到分片的映射，通過這個自定義的路由參數可以用來確保某些類型的文檔都被存儲到同一個分片中。
2.分片間的交互
我們可以發送請求到集羣中的任一節點。，每個節點都有能力處理任意請求。，每個節點都知道集羣中任一文檔位置，所以可以直接將請求轉發到需要的節點上。
我們將接收請求的節點稱爲協調節點(coordinating node) ，由它負責向其他節點進一步發送請求以及收集結果返回給客戶端。
新建、索引和刪除請求都是寫操作， 必須在主分片上面完成之後才能被複制到相關的副本分片，大概過程如下：
- 客戶端向某個節點（以下稱協調節點）發送新建、索引或者刪除請求。
- 協調節點使用規則（shard = hash(routing) % number_of_primary_shards）確定文檔所在分片（這裏指主分片）的位置，協調節點將請求轉發到分片對應的節點（以下稱處理節點）。
- 處理節點在主分片上面執行請求，處理成功後將請求並行轉發到該主分片的副本分片上。一旦所有的副本分片都報告成功,處理節點將向協調節點報告成功，協調節點向客戶端報告成功。
- 在客戶端收到成功響應時，文檔變更已經在主分片和所有副本分片執行完成，變更是安全的。
上面說到所有的副本分片都報告成功,處理節點纔會向協調節點報告成功，這樣雖然保證了數據的安全性，但是會有性能的損失，Elasticsearch也提供了一些參數以數據安全爲代價提升性能，比如可以設置部分副本分片成功就算成功，或者只要主分片成功就返回給客戶端成功的消息。
二、從集羣中檢索文檔
檢索文檔是讀請求，可以從主分片或者從其它任意副本分片檢索文檔，以下是從主分片或者副本分片檢索文檔的步驟順序：
- 客戶端向協調節點發送獲取請求。
- 協調節點使用路由規則確定文檔所在的分片 。
- 協調節點將請求轉發到相應的處理節點。
- 處理節點將文檔返回給協調節點，然後協調節點將文檔返回給客戶端。
在處理讀取請求時，協調結點在每次請求的時候都會通過輪詢所有的副本分片來達到負載均衡。
三、總結
Elasticsearch的文檔是分佈式存儲的，文檔所在的分片會分佈在不同的節點上，因此當客戶端發起一個創建、查詢或者是修改等等的請求時，我們請求操作的數據如果在其他節點上，那麼當前請求的節點將作爲一個協調節點，由它將請求轉發到其他節點，等待其他節點返回處理結果，然後它再將結果返回給客戶端。對於寫操作的請求都是在主分片完成，主分片完成後需要將本次請求的變更同時推送到其副本分片，等待副本分片都響應成功後，纔會將結果返回給客戶端。