上图展示了获取文档的过程，每个步骤解释如下：
- 客户端(Client)发送一个请求到节点1。
- 该节点利用文档的_id字段来判断该文档属于分片0。分片0的分片拷贝(主要分片或者是副本分片)存在于所有的3个节点上。这一次，它将请求转发到了节点2。
- 节点2将文档返回给节点1，节点1随即将文档返回给客户端。
对于读请求(Read Request)，请求节点(Requesting Node)每次都会选择一个不同的分片拷贝来实现负载均衡 - 循环使用所有的分片拷贝。
可能存在这种情况，当一份文档正在被索引时，该文档在主要分片已经就绪了，但是还未被拷贝到其他副本分片上。此时副本分片或许报告文档不存在(译注：此时有读请求来获取该文档)，然而主要分片能够成功返回需要的文档 。一旦索引请求返回给用户的响应是成功，那么文档在主要分片以及所有副本分片上都是可用的。
文档的部分更新(Partial Update)
update API会结合读和写来完成一次部分更新。
下面对部分更新的步骤进行解释：
- 客户端发送一个更新请求到节点1。
- 节点1将请求转发到节点3，因为主要分片被分配在该节点上。
- 节点3从主要分片中获取对应的文档，修改JSON文档中的_source字段，然后试图在该主要分片中对修改后的文档重新索引(Reindex)。如果该文档已经另外一个进程给修改了，那么它会根据
retry_on_conflict设置的次数重试。 - 如果节点3能够成功更新文档，它会将新版本的文档通过并行的方式给转发到副本分片所在的节点1和节点2上，也让它们进行重索引的操作。一旦所有的副本节点也执行成功，节点3就会将这一消息发送给请求节点(Requesting Node，此处就是节点1)。然后请求节点给客户端返回响应。
update API也能够接受接受
routing，'replication'，'consistency'和'timeout'参数。基于文档的复制 当一个主要分片将修改转发给它的副本分片时，它不会转达更新请求。它转发的是新版本的完整文档。需要记住这些转发到副本分片的请求是异步的，也就是说它们到达的顺序和发送的顺序是不确定的。如果ES仅仅是转发修改，那么这些修改就可能以错误地顺序被接受，从而导致数据的损毁。
多文档模式(Multi-Document Patterns)
mget和bulk API的行为模式和单个的文档操作是类似的。区别主要在于请求节点知道每份文档被保存在那个分片上，因此就能够将一个多文档请求(Multi-Document Request)给拆分为针对每个分片的多文档请求，然后并行地将这些请求转发到对应的节点上。
一旦它从每个节点上获得了答案，它会将这些答案整理成一个单独的响应并返回给客户端。
使用一个mget请求来获取多份文档的步骤如下：
- 客户端发送一个mget请求到节点1。
- 节点1为每个分片(可以是主要分片或者副本分片)创建一个mget请求，然后将它们并行地转发到其他分片所在的节点。一旦节点1获得了所有的结果，就会将结果组装成响应最后返回给客户端。
每份文档都可以设置routing参数，通过传入一个docs数组来完成。
使用一个bulk请求来完成对多份文档的创建，索引，删除及更新的步骤如下：
- 客户端发送一个bulk请求到节点1。
- 节点1为每个分片(只能是主要分片)创建一个bulk请求，然后将它们并行地转发到其他主要分片所在的节点。
- 主要分片会逐个执行bulk请求中出现的指令。当每个指令成功完成后，主要分片会将新的文档(或者删除的)并行地转发到它关联的所有副本分片上，然后执行下一条指令。一旦所有的副本分片对所有的指令都确定其成功了，那么当前节点就会向请求节点(Requesting Node)发送成功的响应，最后请求节点会整理所有的响应并最终发送响应给客户端。
bulk API也能够在整个请求的顶部接受
replication和consistency参数，在每个具体的请求中接受routing参数。