shard03replica
客户端
优点：返回的数据量是准确的。 缺点：性能一般，并且数据排名不准确。
索引查询
shard02replica
客户端发送请求到任意一个node，成为coordinate node
机器1
协调节点进行哈希，去 调对应
elasticsearch进程01
6、把各个分片数据合并排序返回
优点：这种搜索方式是最快的。因为相比后面的几种es的搜索方式，这种查询方法只需要去shard查询一次。 缺点：返回的数据量不准确， 可能返回(N*分片数量)的数据并且数据排名也不准确，同时各个shard返回的结果的数量之和可能是用户要求的size的n倍。
随意挑选一个节点查询doc{ID}
每隔1S刷新新
SearchType类型搜索
搜索详细图初步分两种
buffer中的数据每隔1s就会吧数据刷新到os cache中，buffer 中发数据就好被清空，并且刷新到os cache中的数据就可以被搜索到了
.del文件磁盘文件
协调节点
shard01replica
5、返回document
返回元素文档（ document）和计算后的排名信息一起返回
shard02primary
协调节点发给所有节点
segment file（磁盘删除）
把各个分片数据合并排序返回
shard01primary
各分片返回的文档的分数进行重新排序和排名 取前 size 个文档。
内存buffer
当一个搜索请求被发送到某个节点时，这个节点就变成了协调节点。 这个节点的任务是广播查询请求到所有相关分片并将它们的响应整合成全局排序后的结果集合，这个结果集合会返回给客户端。
如果primary和replica shard都写完了，协调节点就会返回写成功的响应给客户端
Elasticsearch的搜索类型（SearchType类型）
segment file磁盘文件中
当segment file文件到达一定数量就会merge把segment file文件合并，同时把.del文件物理删除，合并成新的segment file文件 删除所有旧文件
es 默认的搜索方式
删除数据.写入.del文件中标识一下。这条数据被删除
segment file（磁盘）
shard03primary
elasticsearch进程02协调节点
4、根据文档ID查询document
每隔5s写入
commit point（磁盘）
1、根据搜索方式随机找台机器
elasticsearch进程03
translog日志文件
机器3
机器2
os cache（系统缓存）
translog不断变大，大到一定阈值或30 分钟，就会触发commit操作
translog作用，就是在执行commit之前，数据停留在buffer和在os cache中都是在内存中，一旦这台机器死了，内存中的数据就丢失了，再次重启es，就会读取translog恢复到buffer和os cache中
3、文档 id（ 没有document）和排名信息一起返回
