目录
一、Elasticsearch 架构
Elasticsearch 是由 Lucene 提供支持的搜索引擎。 它为 “搜索部分” 提供了强大的动力，而 Elasticsearch 为你提供了可扩展性，可用性，REST API，专门的数据结构等（从广义上来说）。
Elasticsearch 架构的概略示意图
从图中可以看出，Elasticsearch 在可用节点上对每个 Lucene 索引进行了分片。 分片可以是主分片或副本分片。
每个分片都是一个 Lucene 索引，这些索引中的每个索引都可以具有多个 segment，每个 segement 都是一个反向索引。
这些 segment 是在文档摄入期间创建的，并且是不可变的。 这意味着，当你编辑或删除 Lucene 段中已经存在的文档时，将创建一个新 segment，而不是更改前一个 segment。
这是要考虑的非常重要的事情。 由于这种架构，Elasticsearch 不支持更新，甚至不支持部分更新。
每次更新文档中的单个字段时，都会创建一个新的 segment，并且上一个 segment 中的信息会标记为已删除。
二、索引编制过程
索引编制过程中的文件路径
在此图中，我们可以看到 Elasticsearch 如何存储新文档。一旦文档到达，它将被提交到一个称为 “translog” 的事务日志和一个内存缓冲区。
事务日志是ES如何恢复仅在发生故障时在内存中的数据的方式。当 “刷新/refresh” 操作发生时，内存缓冲区中的所有文档将生成一个内存中的 Lucene segment。此操作用于使新文档可供搜索。
最终，根据不同的触发条件（稍后将对此进行详细介绍），所有这些段都合并为一个 segment 并保存到磁盘中，并且清除了事务日志。
三、写入原理一
数据写入ES集群，主要是经过以下2个主要步骤：
1. 读取数据 -> 验证（master节点分发给data节点处理，或直接访问data节点主分片）
2. 同时写入buffer缓冲区和translog日志文件 -> 生成segment file -> 合并小segment file生成大segment file -> 将合并的segment file刷写到系统缓存，此时可以数据可以被搜索到（refresh） -> 用fsync将所有缓存数据刷写到磁盘（flush）。
四、写入原理二
先写入内存 buffer，在 buffer 里的时候数据是搜索不到的；同时将数据写入 translog 日志文件。
如果 buffer 快满了，或者到一定时间，就会将内存 buffer 数据 refresh 到一个新的 segment file 中
但是此时数据不是直接进入 segment file 磁盘文件，而是先进入 os cache 。这个过程就是 refresh。
每隔 1 秒钟，es 将 buffer 中的数据写入一个新的 segment file，每秒钟会产生一个新的磁盘文件 segment file
这个 segment file 中就存储最近 1 秒内 buffer 中写入的数据。
但是如果 buffer 里面此时没有数据，那当然不会执行 refresh 操作
如果 buffer 里面有数据，默认 1 秒钟执行一次 refresh 操作，刷入一个新的 segment file 中。
操作系统里面，磁盘文件其实都有一个东西，叫做 os cache，即操作系统缓存
就是说数据写入磁盘文件之前，会先进入 os cache，先进入操作系统级别的一个内存缓存中去。只要 buffer中的数据被 refresh 操作刷入 os cache中，这个数据就可以被搜索到了。
所以上面小结一下数据写入经历的几个点：
es-client --> node --> node.buffer --> os cache（数据写到这里可提供查询） --> 磁盘
从buffer-->os cache 这个是通过refresh每秒钟一次刷进去
从os cache --> 磁盘 是靠系统的fsync来完成数据落盘
五、节点的协调关系
客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node（协调节点）。
coordinating node 对 document 进行路由，将请求转发给对应的 node（有 primary shard）。
实际的 node 上的 primary shard 处理请求，然后将数据同步到 replica node。
coordinating node 如果发现 primary node 和所有 replica node 都搞定之后，就返回响应结果给客户端。
六、ES读数据过程
可以通过 doc id 来查询，会根据 doc id 进行 hash，判断出来当时把 doc id 分配到了哪个 shard 上面去，从那个 shard 去查询。
客户端发送请求到任意一个 node，成为 coordinate node。
coordinate node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin随机轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡。
接收请求的 node 返回 document 给 coordinate node。
coordinate node 返回 document 给客户端。
七、ES搜索数据过程
es 最强大的是做全文检索，就是比如你有三条数据：java真好玩儿啊，java好难学啊，j2ee特别牛
你根据 java 关键词来搜索，将包含 java的 document 给搜索出来。es 就会给你返回：java真好玩儿啊，java好难学啊。
客户端发送请求到一个 coordinate node。
协调节点将搜索请求转发到所有的 shard 对应的 primary shard 或 replica shard，都可以。
query phase：每个 shard 将自己的搜索结果（其实就是一些 doc id）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。
fetch phase：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。
写请求是写入 primary shard，然后同步给所有的 replica shard；
读请求可以从 primary shard 或 replica shard 读取，采用的是随机轮询算法。
八、删除/更新数据底层原理
如果是删除操作，commit 的时候会生成一个 .del 文件，里面将某个 doc 标识为 deleted 状态，那么搜索的时候根据 .del 文件就知道这个 doc 是否被删除了。
如果是更新操作，就是将原来的 doc 标识为 deleted 状态，然后新写入一条数据。
buffer 每 refresh 一次，就会产生一个 segment file，所以默认情况下是 1 秒钟一个 segment file，这样下来 segment file 会越来越多
此时会定期执行 merge。每次 merge 的时候，会将多个 segment file 合并成一个
同时这里会将标识为 deleted 的 doc 给物理删除掉，然后将新的 segment file 写入磁盘
这里会写一个 commit point，标识所有新的 segment file，然后打开 segment file 供搜索使用，同时删除旧的 segment file。
参考文献
https://blog.csdn.net/sinat_26811377/article/details/102667279
互联网大厂技术-elasticsearch(es)- 在数据量很大的情况下（数十亿级别）提高查询效率_码者人生的博客-CSDN博客
901
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
