es 是一個分布式系統，當我們存儲一個文檔到 es 上之后，這個文檔實際上是被存儲到 master 節點中的某一個主分片上。

例如新建一個索引，該索引有兩個分片，0個副本，如下：

接下來，向該索引中保存一個文檔：

PUT blog/_doc/a {"title":"a" }

文檔保存成功后，可以查看該文檔被保存到哪個分片中去了：

GET _cat/shards/blog?v

查看結果如下：

index shard prirep state docs store ip node blog 1 p STARTED 0 208b 127.0.0.1 slave01 blog 0 p STARTED 1 3.6kb 127.0.0.1 master

從這個結果中，可以看出，文檔被保存到分片 0 中。

那么 es 中到底是按照什么樣的規則去分配分片的？

es 中的路由機制是通過哈希算法，將具有相同哈希值的文檔放到一個主分片中，分片位置的計算方式如下：

shard=hash(routing) % number_of_primary_shards

routing 可以是一個任意字符串，es 默認是將文檔的 id 作為 routing 值，通過哈希函數根據 routing 生成一個數字，然后將該數字和分片數取余，取余的結果就是分片的位置。

默認的這種路由模式，最大的優勢在于負載均衡，這種方式可以保證數據平均分配在不同的分片上。但是他有一個很大的劣勢，就是查詢時候無法確定文檔的位置，此時它會將請求廣播到所有的分片上去執行。另一方面，使用默認的路由模式，后期修改分片數量不方便。

當然開發者也可以自定義 routing 的值，方式如下：

PUT blog/_doc/d?routing=javaboy {"title":"d" }

如果文檔在添加時指定了 routing，則查詢、刪除、更新時也需要指定 routing。

GET blog/_doc/d?routing=javaboy

自定義 routing 有可能會導致負載不均衡，這個還是要結合實際情況選擇。

典型場景：

對于用戶數據，我們可以將 userid 作為 routing，這樣就能保證同一個用戶的數據保存在同一個分片中，檢索時，同樣使用 userid 作為 routing，這樣就可以精準的從某一個分片中獲取數據。

總結

以上是生活随笔為你收集整理的ElasticSearch 文档路由，你的数据到底存在哪一个分片上_06的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。