1：一條數據是如何落地到對應的shard上的
當索引一個文檔的時候，文檔會被存儲到一個主分片中。 Elasticsearch 如何知道一個文檔應該存放到哪個分片中呢？
首先這肯定不會是隨機的，否則將來要獲取文檔的時候我們就不知道從何處尋找了。實際上，這個過程是根據下面這個算法決定的：
shard = hash(routing) % number_of_primary_shards
routing 是一個可變值，默認是文檔的 _id ，也可以設置成一個自定義的值。 routing 通過 hash 函數生成一個數字，然后這個數字再除以 number_of_primary_shards （主分片的數量）后得到 余數 。這個分布在 0 到 number_of_primary_shards-1 之間的余數，就是我們所尋求的文檔所在分片的位置。
這就解釋了為什么我們要在創建索引的時候就確定好主分片的數量 並且永遠不會改變這個數量：因為如果數量變化了，那么所有之前路由的值都會無效，文檔也再也找不到了
2：路由機制
現在我們在探討一個關於路由的問題：
假設你有一個100個分片的索引。當一個請求在集群上執行時會發生什么呢？
1. 這個搜索的請求會被發送到一個節點
2. 接收到這個請求的節點，將這個查詢廣播到這個索引的每個分片上（可能是主分片，也可能是復制分片）
3. 每個分片執行這個搜索查詢並返回結果
4. 結果在通道節點上合並、排序並返回給用戶
因為默認情況下，Elasticsearch使用文檔的ID（類似於關系數據庫中的自增ID），如果插入數據量比較大，文檔會平均的分布於所有的分片上，這導致了Elasticsearch不能確定文檔的位置，所以它必須將這個請求廣播到所有的N個分片上去執行
這種操作會給集群帶來負擔，增大了網絡的開銷；
路由使用：
PUT my_index/my_type/1?routing=user1&refresh=true
{
"title": "This is a document"
}
GET my_index/my_type/1?routing=user1
上面的代碼中，指定了一個用戶屬性作為路由進行分區，然后查詢的時候也必須指定路由。這一點需要注意 只要在索引時候加入路由字段，那么在以后的get，delete，update操作中都必須使用路由字段，否則會出現問題。
有時候我們會把某些具有相似屬性的數據放在同一個路由下，這樣可以提高查詢的效率；比如：我們把不同季度的銷售數據存儲在不同的路由下；然后在查詢的時候，直接根據路由字段本身進行查詢即可，而不需要直接掃描全年的數據：
PUT department1/order/1?routing=jidu1
{
"productName" : "phone",
"total_price" : 10000000,
"times" : "2017-01-01"
}
PUT department1/order/2?routing=jidu1
{
"productName" : "huawei",
"total_price" : 10000000,
"times" : "2017-2-01"
}
PUT department1/order/1?routing=jidu2
{
"productName" : "phone",
"total_price" : 10009000,
"times" : "2017-5-01"
}
查詢季度1的所有數據
GET department1/_search
{
"query": {
"terms" : {
"_routing" : [ "jidu1" ]
}
}
}
查詢季度1和季度2的所有數據：
GET department1/_search
{
"query": {
"terms": {
"_routing": [ "jidu1" , "jidu2"]
}
}
}
當然，有時候我們需要查詢第一、第二季度的產品中叫做huawei的文檔。那么在查詢中也是可以指定多個路由的：
GET department1/_search?routing=jidu1,jidu2
{
"query": {
"match": {
"productName": "huawei"
}
}
}
注意：
如果加入路由字段之后，其他的操作(indexing,getting,deleting,updating)都必須指定路由字段，為了避免在使用時忘記添加 路由字段，導致同類數據會分布在多個shard上，這就違反了路由的原則，我們可以在mapping中 設置路由字段是必須字段，否則會提示錯誤：
PUT department1
{
"mappings": {
"order": {
"_routing": {
"required": true
}
}
}
}