聚合操作模式（mget，bulk）APIS和单个操作和类似，不同的是，接受请求的node知道操作的document在那个shard上，他根据各个shard拆分总的multi-document请求到单个的multi-document，然后一起分发到各个node。
一旦负责请求的node从各个node收到响应，这个请求node就整理这些请求到一个响应体，返回给客户端。
下图是使用mget进行多文档检索：
步骤如下：
1：客户端发送mget请求到node1
2：node1根据shard拆分到多个multi-get请求，然后一起发送到相应的node中的primary或者replica
shard。一旦所有的相应都被node1收到，node1就把相应报告给客户端。
routing参数能设置到docs数组的每个document。preference参数能设置到顶级的mget请求中。
下图使用bulk进行document的修改：
下面列出在一个bulk中执行create，index，delete请求的必要步骤：
1：客户端向node1发送请求
2：node1根据shard构建bulk请求，转发到相对应的primary shard。
3：primary shard连续的执行每个动作，当每个动作都成功，primary
shard转发新的document（或删除的document）到他的replica shard，然后在去执行下一个动作。当所有的replica
shad都成功执行了所有的动作，各个node就会向requesting node作出成功的报告，然后requestiong
node向客户端发送成功报告。
bulk API也接受replication和consistency参数作为整个bulk请求的顶级参数，routing参数可以对每个请求设置。
为什么是这种格式？
当我们在Cheaper
in
bulk学习Bulk请求的时候，你或许会问：为什么bulkAPI要对新的一行格式化一个换行符呢，而不是像mget一样包装到JSON的数组中？
回答这个问题之前，我们要解释一下背景：
每个bulk请求中的document也许是属于不同的primary
shard，请求的document或许要分配到cluster中的任意的node上，也就是说，bulk中的每个请求动作，都需要转发到正确的node中正确shard上。
如果单个的请求是被包装在JSON数组中，要做如下的事情：
1：解析JSON到一个数组（包括document的数据，或许还会很大）
2：查看每个请求，决定这个请求要到那个shard上
3：为每个shard的请求都创建一个数组
4：序列化这些数组到内部的格式
5：把请求发送到每个shard
这也能工作，但是需要更多的内存备份本质上一样的数据，并且要创建很多的数据结构，然后JVM要花费一定的性能回收这些垃圾。
ES建立了网络缓冲，原始请求数据到达就直接读取。他使用了换行符标记解析action/metadate决定那个shard应该处理这个请求。
原始数据被直接的转发到正确的shard。没有冗余数据，没有浪费的数据结构。整个请求进程实在一个很小的内存中进行处理的。
原文：http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/distrib-multi-doc.html
多文档模式（multi-document parrerns）,布布扣,bubuko.com