Elasticsearch 项目中使用到Es的父子结构、在数据填充之后，查看每个节点的数据分布情况，发现有的节点数据多，有的节点少的情况，在未使用Es父级结构之前，每个节点的数据分布还算平均，如下图：
左边的数据是未使用父子结构之前每个节点的数据分布数量，右边的是使用了父子结构之后的数据节点分布数量，最下面一行红色的数字是节点平均数量，可以看出，左边的数据与平均值相差不大，右边的数据与平均值最大相差400万，这个差距还是蛮大的，为什么会有这么大的差距呢？围绕着这个问题，进行了一番研究，今天就来学习学习下Elasticsearch 的路由机制。
首先，Es的路由机制与其分片机制有着直接的关系，Es的路由机制是通过哈希算法，将具有相同哈希值的文档放置在同一分片中的，通过这个哈希算法来进行负载均衡的效果，这个就是为什么左侧图中的每个节点的数据都与平均值相差不大的原因。
计算公式是：
shard = hash(routing) % number_of_primary_shards
routing 值是一个任意字符串，它默认是_id但也可以自定义。这个routing 字符串通过哈希函数生成一个数字，然后除以主切片的数量得到一个余数(remainder)，余数的范围永远是0到number_of_primary_shards - 1，这个数字就是特定文档所在的分片。
所以，每一条数据在写入的时候，是放在分片1上，还是分片2上，不是瞎蒙的，是通过计算得来的。这也解释了为什么主分片的数量只能在创建索引时定义且不能修改：如果主分片的数量在未来改变了，所有先前的路由值就失效了，文档也就永远找不到了。
上面解释清楚了，在来解释下，为什么我使用了Es父子结构之后，每个节点的数据发生了那么大的差距呢？
解释这个之前，先来看下Es父子结构情况下，写入子数据的写法（怎么创建父子结构这里就不赘述了）：
PUT /company/employee/1?parent=london
{
"name": "Alice Smith",
"dob": "1970-10-24",
"hobby": "hiking"
}
在创建子文档的时候你必须指出他们的父文档的id，为什么要指定父文档的ID呢？这是因为Es在存储子数据的时候，会用父文档的ID去计算存放在那个分片，它会把父文档相同的数据都存放在同一个分片上面；
举个例子，如果父文档1，下面子文档有10个，存储在A分片；
分文档2，下面子文档有500个，存储在B分片上；
这样，随着每个父文档对应的子文档数据分布不均，节点的数据量就会越来越不均衡，这就说明了为什么使用了Es父子结构之后，节点数据差距较大的情况了。
问题来了，那么怎么解决分布不均的问题呢？
可以通过指定个性化路由来处理，所有的文档API（get，index，delete，update和mget）都能接收一个routing参数，可以用来形成个性化文档分片映射。
写入数据时怎么指定存储的分片，可以参考这篇： ，别人已经写好，我就不重新去写了。
来说一说设置分片的好处，我画了个图，举个例子，现在你去找一本计算机相关的图书，现在有四个节点，在没有指定分片存储之前，所有的书是平均放的，每一个节点上面都会有计算机相关的图书，
然后，Es就会去四个节点上面分别去找，黑色的线，ES会向每个节点都发送一个请求，然后节点就开始找找，找呀找，然后，找到了，节点开始返回数据了，就是红色的线；
ES把所有的节点的响应数据都汇总之后，然后在按照评分去做下排序，把评分最高，相关性比较高的数据在返回给你。
那么，如果在存储的时候，就告诉ES，把所有计算机相关的书籍都给我放置到节点3上面，然后在查询的时候，告诉ES，在节点3上面给我找计算机相关的书籍。如下图：
很明显，这样的查询，就不会去向所有的节点都广播，定位很精准，在某一程度上，效率可能会高一点，但是，这样做的话，就会增加ES节点分片的维护成本，就违背了Es高可用性，拓展性的设计理念了
所以，要根据具体业务具体需求去定响应的方案。
