ElasticSearch架构

• Beats 是单一用途的数据传输平台，它可以将多台机器的数据发送到 Logstash 或 ElasticSearch。

• Logstash 是一个动态数据收集管道。支持以 TCP/UDP/HTTP 多种方式收集数据（也可以接受 Beats 传输来的数据），并对数据做进一步丰富或提取字段处理。

• ElasticSearch 是一个基于 JSON 的分布式的搜索和分析引擎。作为 ELK 的核心，它集中存储数据。

• Kibana 是 ELK 的用户界面。它将收集的数据进行可视化展示（各种报表、图形化数据），并提供配置、管理 ELK 的界面

ElasticSearch简介

Elasticsearch 基于搜索库 Lucene 开发。ElasticSearch 隐藏了 Lucene 的复杂性，提供了简单易用的 REST API / Java API 接口（另外还有其他语言的 API 接口）。

ElasticSearch 可以视为一个文档存储，它将复杂数据结构序列化为 JSON 存储。

ElasticSearch 是近乎于实时的全文搜素，这是指：

• 从写入数据到数据可以被搜索，存在较小的延迟（大概是 1s）

• 基于 ES 执行搜索和分析可以达到秒级

核心概念

• 索引（Index） 可以认为是文档（document）的优化集合。

• 每个 文档（document） 都是字段（field）的集合。

• 字段（field） 是包含数据的键值对。

• 默认情况下，Elasticsearch 对每个字段中的所有数据建立索引，并且每个索引字段都具有专用的优化数据结构。

• 每个索引里可以有一个或者多个类型（type）。类型（type） 是 index 的一个逻辑分类，

• 当单台机器不足以存储大量数据时，Elasticsearch 可以将一个索引中的数据切分为多个 分片（shard） 。 分片（shard） 分布在多台服务器上存储。有了 shard 就可以横向扩展，存储更多数据，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能。每个 shard 都是一个 lucene index。

• 任何一个服务器随时可能故障或宕机，此时 shard 可能就会丢失，因此可以为每个 shard 创建多个 副本（replica）。replica 可以在 shard 故障时提供备用服务，保证数据不丢失，多个 replica 还可以提升搜索操作的吞吐量和性能。primary shard（建立索引时一次设置，不能修改，默认 5 个），replica shard（随时修改数量，默认 1 个），默认每个索引 10 个 shard，5 个 primary shard，5 个 replica shard，最小的高可用配置，是 2 台服务器。

原理结构

参考：https://github.com/doocs/advanced-java/blob/main/docs/high-concurrency/es-write-query-search.md

es-写过程

• 客户端选择一个 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，成为 coordinating node。

• coordinating node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin 随机轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡。

• 接收请求的 node 返回 document 给 coordinating node。

• coordinating node 返回 document 给客户端。

es-检索数据

你根据 java 关键词来搜索，将包含 java 的 document 给搜索出来。es 就会给你返回：java 真好玩儿啊，java 好难学啊。

• 客户端发送请求到一个 coordinating node。

• 协调节点将搜索请求转发到所有的 shard 对应的 primary shard 或 replica shard ，都可以。

• query phase：每个 shard 将自己的搜索结果（其实就是一些 doc id ）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。

• fetch phase：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。

写请求是写入 primary shard，然后同步给所有的 replica shard；读请求可以从 primary shard 或 replica shard 读取，采用的是随机轮询算法。

es-写数据底层原理

数据先写入内存 buffer，然后每隔 1s，将数据 refresh 到 os cache，到了 os cache 数据就能被搜索到（所以我们才说 es 从写入到能被搜索到，中间有 1s 的延迟）。每隔 5s，将数据写入 translog 文件（这样如果机器宕机，内存数据全没，最多会有 5s 的数据丢失），translog 大到一定程度，或者默认每隔 30mins，会触发 commit 操作，将缓冲区的数据都 flush 到 segment file 磁盘文件中。