一、路由文档到分片
当你索引一个文档的时候，他被存储在单独一个主分片上。Elasticsearch根据一个算法来找到所在分片上。
shard=hash(routing)%number_of_primary_shards
routing值是一个任意字符串，默认是_id但也可以自定义。这个routing通过哈希函数生成一个数字，然后除以主切片的数量得到一个榆树。这也就是为什么主分片的数量只能在创建索引时定义且不能修改：如果主分片的数量在未来改变了，所有先前的路由值就失效了，文档就永远找不到了。
所有的文档API都接受一个routing参数，用来定义文档到分片的映射。
二、分片交互
这里有三个节点的集群，他包含一个叫做bblogs的索引并拥有两个主分片。每个主分片有两个复制分片。相同的分片不会再同一个节点上。
我们可以发送请求给集群中任意一个节点，每个节点都有能力处理任意请求。每个节点都知道任意文档所在的节点。所以也可以请求转发到需要的节点。
在我们发送请求时，最好的做法是循环通过所有节点请求，这样可以平衡负载。
三、新建索引和删除文档
新建索引和删除文档都是写操作，他们必须在主分片上成功完成才能复制到相关的复制分片上
以下为在主分片和复制分片上成功新建索引和删除文档的步骤：
①：客户端给Node1发送新建索引或删除请求
②：节点使用文档的_id确定文档属于分片0.他转发请求到Node3,分片0位于这个节点上
③：Node3在主分片上执行请求，如果成。他组案发请求到相应的位于Node1和Node2的复制节点上，当所有的复制节点报告成功，Node3报告成功到请求的节点，请求的节点再报告给客户端。
客户端接收到成功响应的时候，文档的修改已经被应用于主分片和所有的复制分片，你的修改就生效了。
replication：
复制的默认值是sync.这将导致主分片得到复制分片的成功响应后才返回。
如果你设置replication为async,请求在主分片上被执行后就会返回客户端，他依旧会转发请求给复制节点，但是你将不知道复制节点成功与否。
consistency:
默认主分片在尝试写入时需要规定数量（quorum）或过半的分片可用。为了防止数据被写入到错的网络分区。
int((primary+number_of_replicas)/2)+1
consistency允许值为一个 全部过过半分区、
timeout：
当分片副本不足时，Elasticsearch会等待更多的分片出现，默认等待一分钟还可以自己设置。
四、检索文档
文档能够从主分片或任意一个复制分片被检索
以下为从主分片或复制分片上检索一个文档的步骤：
①：客户端给Node1发送请求
②：节点使用文档的_id确定文档属于分片0、分片0对应的复制分片在三个节点上都有。此时。他转发请求到Node2
③：Node2返回endangered给Node1然后返回给客户端
五、局部更新文档
以下为局部更新的步骤：
①：客户端给Node1发送更新请求
②：他转发请求到主分片所在节点Node3
③：Node3从主分片检索出文档，修改_source字段的JSON。然后在主分片上重建索引。如果有其他进程修改了文档，他以retry_on_confluct设置的次数重复步骤3，都未成功则放弃
④：如果Node3成功更新文档，他同时转发文档的新版本到Node1和Node2上的复制节点以重建索引，当所有复制节点报告成功，Node3返回成功给请求节点，然后返回给客户端
六、批量请求
mget和bulk API与单独的文档类似。差别是请求节点知道每个文档所在的分片。它把多文档请求拆成每个分片的对文档请求，然后转发每个参与的节点。
一旦接收到每个节点的应答，然后整理这些响应组合为一个单独的响应，最后返回给客户端。
以下为请求步骤：
1.客户点向Node1发送mget请求
2.Node1为每个分片构建一个多条数据检索请求，然后转发到这些请求所需的主分片或复制分片上。当所有回复被接受，Node1构建响应并返回给客户端
routing参数可以被docs中的每个文档设置
下面我们将罗列使用一个bulk执行多个create、index、delete和update请求的顺序步骤：
- 客户端向
Node 1发送bulk请求。 Node 1为每个分片构建批量请求，然后转发到这些请求所需的主分片上。- 主分片一个接一个的按序执行操作。当一个操作执行完，主分片转发新文档（或者删除部分）给对应的复制节点，然后执行下一个操作。复制节点为报告所有操作完成，节点报告给请求节点，请求节点整理响应并返回给客户端。
bulk API还可以在最上层使用replication和consistency参数，routing参数则在每个请求的元数据中使用。