https://www.cnblogs.com/Neeo/articles/10869556.html

前言

当索引一个文档的时候，文档会被存储到一个主分片中。那么，elasticsearch如何知道一个文档应该存放到哪个分片中呢？
在《13 如何确定数据保存在哪个shard》中我们知道。

shard = hash(routing) % number_of_primary_shards

routing是一个可变值，默认是文档的_id，也可以是自定义的值。hash函数将routing值哈希后生成一个数字，然后这个数字再除以number_of_primary_shards（主分片的数量）得到余数，这个分布在0到number_of_primary_shards减一（计数从0开始，比如5个主分片，那么范围就是0~4）之间的余数，就是文档存放的分片位置。
比如一篇文档的id为123，那么它就应该存在：

  1. >>>hash(123) % 5
  2. 3

这篇文档就存在P3主分片上。
这也就解释了为什么在创建索引时，主分片的数量一经定义就不能改变，
因为如果数量变化了，那么之前所有的路由（routing）值都会无效，文档就再也找不到了。

一般的，elasticsearch的默认路由算法都会根据文档的id值作为依据将其哈希到相应的主分片上，该算法基本上会将所有的文档平均分布在所有的主分片上，而不会产生某个分片数据过大而导致集群不平衡的情况。
那么我们在向一个有100个主分片的索引发送查询某篇文档的请求时，该请求发送到集群，集群干了什么呢？

  • 这个请求会被集群交给主节点。
  • 主节点接收这个请求后，将这个查询请求广播到这个索引的每个分片上（包含主、复制分片）。
  • 每个分片执行这个搜索请求，并将结果返回。
  • 结果在主节点上合并、排序后返回给用户。

在这里面就有些问题了。因为在存储文档时，通过hash算法将文档平均分布在各分片上，这就导致了elasticsearch也不确定文档的位置，所以它必须将这个请求广播到所有的分片上去执行。为了避免不必要的查询，我们使用自定义的路由模式，这样可以使我们的查询更具目的性。比如之前的查询是这样的：
**

搜索请求来了，**索引下的所有分片**都要检查一下自己是否有符合条件的文档

当能自定义路由后的查询变成了：

请求来了，分片3、5你俩把文档给我返回

自定义路由

所有的文档 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一个叫做 routing 的路由参数 ，通过这个参数我们可以自定义文档到分片的映射。一个自定义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被存储到同一个分片中。

  1. PUT r1/doc/1?routing=user1
  2. {
  3.     "title":"论母猪的产前保养"
  4. }
  6. PUT r1/doc/2?routing=user1
  7. {
  8.     "title":"论母猪的产后护理"
  9. }

上例中，该文档使用user1作为路由值而不是使用_id。这样，具有相同user1的文档将会被分配同一个分片上。

通过路由查询文档

自定义路由可以减少搜索，不需要将搜索请求分发到所有的分片，只需要将请求发送到匹配特定的路由值分片既可。
我们来查询：

  1. GET r1/doc/1?routing=user1
  2. #结果如下
  3. {
  4.   "_index" : "r1",
  5.   "_type" : "doc",
  6.   "_id" : "1",
  7.   "_version" : 3,
  8.   "_routing" : "user1",
  9.   "found" : true,
  10.   "_source" : {
  11.       "title" : "论母猪的产前保养"
  12.   }
  13. }

也可通过这个路由值查询文档：

  1. GET r1/doc/_search
  2. {
  3.   "query": {
  4.     "terms": {
  5.         "_routing":["user1"]
  6.     }
  7.   }
  8. }
  9. #结果如下
  10. {
  11.   "took" : 0,
  12.   "timed_out" : false,
  13.   "_shards" : {
  14.     "total" : 5,
  15.     "successful" : 5,
  16.     "skipped" : 0,
  17.     "failed" : 0
  18.   },
  19.   "hits" : {
  20.     "total" : 2,
  21.     "max_score" : 1.0,
  22.     "hits" : [
  23.       {
  24.         "_index" : "r1",
  25.         "_type" : "doc",
  26.         "_id" : "2",
  27.         "_score" : 1.0,
  28.         "_routing" : "user1",
  29.         "_source" : {
  30.           "title" : "论母猪的产后护理"
  31.         }
  32.       },
  33.       {
  34.         "_index" : "r1",
  35.         "_type" : "doc",
  36.         "_id" : "1",
  37.         "_score" : 1.0,
  38.         "_routing" : "user1",
  39.         "_source" : {
  40.           "title" : "论母猪的产前保养"
  41.         }
  42.       }
  43.     ]
  44.   }
  45. }

删除文档

我们来删除文档。

  1. DELETE r1/doc/1
  2. # 结果如下
  3. {
  4.   "_index" : "r1",
  5.   "_type" : "doc",
  6.   "_id" : "1",
  7.   "_version" : 1,
  8.   "result" : "not_found",
  9.   "_shards" : {
  10.     "total" : 2,
  11.     "successful" : 1,
  12.     "failed" : 0
  13.   },
  14.   "_seq_no" : 2,
  15.   "_primary_term" : 1
  16. }

由上例可见，不提供路由，无法删除文档。

  1. DELETE r1/doc/1?routing=user1
  2. # 结果如下
  3. {
  4.   "_index" : "r1",
  5.   "_type" : "doc",
  6.   "_id" : "1",
  7.   "_version" : 2,
  8.   "result" : "deleted",
  9.   "_shards" : {
  10.     "total" : 2,
  11.     "successful" : 1,
  12.     "failed" : 0
  13.   },
  14.   "_seq_no" : 4,
  15.   "_primary_term" : 1
  16. }

给上路由就OK了。
由此可见，在查询、删除、更新文档时都要提供相同的路由值。

查询多个路由

除了指定查询单个路由值之外，还可以指定多个路由值查询：

  1. PUT r2/doc/1?routing=user1
  2. {
  3.     "title":"母猪产前保养重点在多喂饲料，辅以人工按摩"
  4. }
  5. PUT r2/doc/2?routing=user2
  6. {
  7.     "title":"母猪产后护理重点在母子隔离喂养"
  8. }

此搜索请求将仅在与user1和user2路由值关联的分片上执行。

  1. GET r2/doc/_search?routing=user1,user2
  2. {
  3.   "query": {
  4.     "match": {
  5.       "title": "母猪"
  6.     }
  7.   }
  8. }
  9. 结果如下
  10. {
  11.   "took" : 0,
  12.   "timed_out" : false,
  13.   "_shards" : {
  14.     "total" : 2,
  15.     "successful" : 2,
  16.     "skipped" : 0,
  17.     "failed" : 0
  18.   },
  19.   "hits" : {
  20.     "total" : 2,
  21.     "max_score" : 0.68324494,
  22.     "hits" : [
  23.       {
  24.         "_index" : "r2",
  25.         "_type" : "doc",
  26.         "_id" : "2",
  27.         "_score" : 0.68324494,
  28.         "_routing" : "user2",
  29.         "_source" : {
  30.           "title" : "母猪产后护理重点在母子隔离喂养"
  31.         }
  32.       },
  33.       {
  34.         "_index" : "r2",
  35.         "_type" : "doc",
  36.         "_id" : "1",
  37.         "_score" : 0.5753642,
  38.         "_routing" : "user1",
  39.         "_source" : {
  40.           "title" : "母猪产前保养重点在多喂饲料，辅以人工按摩"
  41.         }
  42.       }
  43.     ]
  44.   }
  45. }

忘了路由值怎么办

由之前的示例可以看到，在自定义的路由中，索引、查询、删除、更新文档时，都要提供路由值。但是我们有可能会忘记路由值，导致文档在多个分片建立索引：

  1. PUT r3/doc/1?routing=u1
  2. {
  3.     "title":"小猪仔真可爱"
  4. }
  5. PUT r3/doc/2
  6. {
  7.     "title":"可爱可爱一盘菜"
  8. }

正如上例所示，我们在创建文档2的时候，忘记路由了，导致这篇文档被默认分配到别的分片上了。那我们想通过u1路由查询就会发现：

  1. GET r3/doc/_search
  2. {
  3.   "query": {
  4.     "terms": {
  5.         "_routing":["u1"]
  6.     }
  7.   }
  8. }
  9. #结果如下
  10. {
  11.   "took" : 1,
  12.   "timed_out" : false,
  13.   "_shards" : {
  14.     "total" : 5,
  15.     "successful" : 5,
  16.     "skipped" : 0,
  17.     "failed" : 0
  18.   },
  19.   "hits" : {
  20.     "total" : 1,
  21.     "max_score" : 1.0,
  22.     "hits" : [
  23.       {
  24.         "_index" : "r3",
  25.         "_type" : "doc",
  26.         "_id" : "1",
  27.         "_score" : 1.0,
  28.         "_routing" : "u1",
  29.         "_source" : {
  30.           "title" : "小猪仔真可爱"
  31.         }
  32.       }
  33.     ]
  34.   }
  35. }

可以发现，那个文档2通过这个路由值查询不到，但是可以通过普通的查询：

  1. GET r3/doc/_search

这样，两篇文档都会有被返回。
为了避免类似上述的情况出现，我们必须采取安全措施，加个套！在自定义映射关系时，使用_routing参数生成那个安全套！

  1. #以下是6.5.4版本的写法
  2. PUT r4
  3. {
  4.   "mappings": {
  5.     "doc":{
  6.       "_routing":{
  7.           "required": true
  8.       }
  9.     }
  10.   }
  11. }
  12. #以下是7.0官方文档的的写法
  13. PUT my_index2
  14. {
  15.   “mappings”：{
  16.     “_ usting”：{
  17.       “required”：true
  18.     }
  19.   }
  20. }

在_routing参数内，将required:true就表明在对文档做CURD时需要指定路由。不然就会抛出一个routing_missing_exception错误。就像下面的示例一样。

  1. PUT r4/doc/1
  2. {
  3.     "title":"母猪不怀孕怎么办？"
  4. }
  5. # 结果是报错
  6. {
  7.   "error": {
  8.     "root_cause": [
  9.       {
  10.         "type": "routing_missing_exception",
  11.         "reason": "routing is required for [r4]/[doc]/[1]",
  12.         "index_uuid": "na",
  13.         "index": "r4"
  14.       }
  15.     ],
  16.     "type": "routing_missing_exception",
  17.     "reason": "routing is required for [r4]/[doc]/[1]",
  18.     "index_uuid": "na",
  19.     "index": "r4"
  20.   },
  21.   "status": 400
  22. }

有了这种规范，我们在自定义路由时，就可以避免一些不必要的情况发生了。

自定义路由唯一ID

索引指定自定义_routing的文档时，不能保证索引中所有分片的_id唯一性。 事实上，如果使用不同的_routing值索引，具有相同_id的文档可能最终会出现在不同的分片上。
我们应确保ID在索引中是唯一的。

路由到索引分区

问题来了，在实际开发中，可能由于业务场景问题碰到某个路由的文档量非常大，造成该分片非常大，而某些路由的文档却非常小，这就会造成数据偏移而导致集群不平衡。我们该如何办呢？
我们可以配置索引，使得自定义路由值将转到分片的子集而不是单个分片。这有助于降低上述问题导致集群不平衡的风险，同时仍然可以减少搜索的影响。
这是通过在索引创建时提供索引级别设置index.routing_partition_size来完成的。随着分区大小的增加，数据分布越均匀，代价是每个请求必须搜索更多分片。

  1. PUT r6
  2. {
  3.   "mappings": {
  4.     "doc":{
  5.       "_routing":{
  6.         "required": true
  7.       }
  8.     }
  9.   },
  10.   "settings": {
  11.     "index.routing_partition_size": 3
  12.   }
  13. }

通俗的说，这是限制文档分布到指定个数分片上，而不是默认的所有分片上，既提高了请求效率，也减小单一分片数据量过大的问题。
当此设置存在时，计算分片的公式变为：

shard_num = (hash(_routing) + hash(_id) % routing_partition_size) % num_primary_shards


也就是说，_routing字段用于计算索引中的一组分片，然后_id用于选择该集合中的分片。
要启用此功能，index.routing_partition_size应具有大于1且小于index.number_of_shards的值。
启用后，分区索引将具有以下限制：

  • 无法在其中创建具有join field关系的映射。
  • 索引中的所有映射都必须将_routing字段标记为必需。