了解了倒排索引之后，这边来讲下文档怎么存储到分片上
大纲
文档会存储在具体的某个主分片和副本分片上
例如：文档1，会存储在P0和R0分片上
文档和分片的映射算法
确保文档能均匀分布在所用分片上
随机/Round Robin。当需要查询文档1，但分片数很多，需要多次查询才可以查到文档1
潜在算法
维护文档到分片的映射关系，当文档数据量大的时候，维护成本高
实时计算（✔），通过文档1，自动算出需要去那个分片上获取文档。
充分利用硬件资源，避免部分机器空闲，部分机器繁忙
文档到分片的路由算法
shard = hash(_routing) % number_of_primary_shards
hash算法确保文档均匀分散到分片中
默认的_routing值是文档id
可以自行指定routing数值，例如相同国家的商品，都分配到指定的shard
设置Index Settings后，Primary数将不能随意修改，否则将导致路由算法紊乱
插入文档指定_routing
PUT my_index
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1
}
}
#创建主分片为3的索引
PUT my_index/_doc/1?routing=1
{
"xm":"张三",
"xb":"男"
}
PUT my_index/_doc/2?routing=1
{
"xm":"张三",
"xb":"男"
}
PUT my_index/_doc/3?routing=1
{
"xm":"张三",
"xb":"男"
}
#创建3个文档，id从1~3，routing都为1
通过Cerebro查看各主分片shard stats可以发现3个文档都在编号为2的主节点上复制
文档增删改的处理流程
增删改的请求一定作用在主分片上
客户端发起一个PUT请求，该请求将被协调节点(coordinating node)接受，并根据路由信息计算该文档存储在哪个主分片
假设通过计算发现该文档将被存储在node2上的P0节点，则该请求将被转发到node2节点
P0根据请求信息进行操作（注意修改需要先删除再添加），操作完毕后将信息同步到自己的副本节点R0上
P0和R0将通知协调节点(coordinating node)，任务完成情况
协调节点(coordinating node)响应客户端最终处理情况
文档查的请求流程
注意：document如果还在建立索引过程中，可能只有primary shard有，任何一个replica shard都没有，此时请求如果作用到replica shard上可能会导致无法读取到document信息。但是document完成索引建立之后，primary shard和replica shard就都有了
客户端发送读请求到协调节点(coordinating node)
协调节点(coordinating node)根据请求信息对document进行路由计算，将请求转发到对应的节点。此时会使用随机轮询（round-robin）算法，在主节点及其对应的副本中随机选择一个，让读请求负载均衡
接受到请求的节点将处理结果返回给协调节点(coordinating node)
协调节点(coordinating node)将最终的结果反馈给客户
