名词解释：

分片：分片就是对数据切分成了多个部分，Elasticsearch 默认会把一个索引分成五个分片，

数据保存在分片内，分片又被分配到集群内的各个节点里

副本：副本就是对原分片的复制，和原分片的内容是一样的，Elasticsearch 默认会生成一份副本，所以相当于是五个原分片和五个分片副本，相当于一份数据存了两份，并分了十个分片

主节点：即 Master 节点。主节点的主要职责是和集群操作相关的内容，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。稳定的主节点对集群的健康是非常重要的。默认情况下任何一个集群中的节点都有可能被选为主节点。索引数据和搜索查询等操作会占用大量的cpu，内存，io资源，为了确保一个集群的稳定，分离主节点和数据节点是一个比较好的选择。虽然主节点也可以协调节点，路由搜索和从客户端新增数据到数据节点，但最好不要使用这些专用的主节点。一个重要的原则是，尽可能做尽量少的工作。

数据节点：即 Data 节点。数据节点主要是存储索引数据的节点，主要对文档进行增删改查操作，聚合操作等。数据节点对 CPU、内存、IO 要求较高，在优化的时候需要监控数据节点的状态，当资源不够的时候，需要在集群中添加新的节点。

负载均衡节点：也称作 Client 节点，也称作客户端节点。当一个节点既不配置为主节点，也不配置为数据节点时，该节点只能处理路由请求，处理搜索，分发索引操作等，从本质上来说该客户节点表现为智能负载平衡器。独立的客户端节点在一个比较大的集群中是非常有用的，他协调主节点和数据节点，客户端节点加入集群可以得到集群的状态，根据集群的状态可以直接路由请求。

预处理节点：也称作 Ingest 节点，在索引数据之前可以先对数据做预处理操作，所有节点其实默认都是支持 Ingest 操作的，也可以专门将某个节点配置为 Ingest 节点。

ES的节点类型

1.Master：主节点，每个集群都有且只有一个

尽量避免Master节点又是数据节点： node.data true

主节点的主要职责是负责集群层面的相关操作，管理集群变更，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。

2.Voting：投票节点

node.voting_only = true（仅投票节点，即使配置了data.master = true，也不会参选, 但是仍然可以作为数据节点）。

3.Coordinating：协调节点

每一个节点都隐式的是一个协调节点，如果同时设置了data.master = false和data.data=false，那么此节点将成为仅协调节点。

4.Master-eligible node（候选节点）

可以通过选举成为Master的节点

5.Data node（数据节点）

主要负责数据存储和查询服务

配置：

1. node.master = true node.data = true

这是ES节点默认配置，既作为候选节点又作为数据节点，这样的节点一旦被选举为Master，压力是比较大的，通常来说Master节点应该只承担较为轻量级的任务，比如创建删除索引，分片均衡等。

2. node.master = true node.data = false

只作为候选节点，不作为数据节点，可参选Master节点，当选后成为真正的Master节点。

3. node.master = false node.data = false

既不当候选节点，也不作为数据节点，那就是仅协调节点，负责负载均衡

4. node.master=false node.data=true

不作为候选节点，但是作为数据节点，这样的节点主要负责数据存储和查询服务。

协调节点是如何工作的，他是怎么找到对应的节点的?

每个节点都保存了集群的状态,只有Master节点才能修改集群的状态信息
集群状态(Cluster Starte),维护了一个集群中,必要的信息
所有的节点信息
所有的索引和其相关的Mapping与Setting信息
分片的路由信息

协调节点作为es节点中的一个节点，默认情况下es集群中所有的节点都能当协调节点，主要作用于请求转发，请求响应处理等轻量级操作。

这意味着如果它们接收到用户请求，它们就可以处理用户请求

集群健康状态

GET /_cluster/health

status 字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下：

green所有的主分片和副本分片都正常运行。

yellow所有的主分片都正常运行，但不是所有的副本分片都正常运行。

red有主分片没能正常运行

路由一个文档到一个分片中

当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？

首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：

shard = hash(routing) % number_of_primary_shards

routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。

主分片和副本分片如何交互

我们可以发送请求到集群中的任一节点。 每个节点都有能力处理任意请求。 每个节点都知道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。 在下面的例子中，将所有的请求发送到 Node 1 ，我们将其称为 协调节点(coordinating node) 。

新建、索引和删除文档

以下是在主副分片和任何副本分片上面 成功新建，索引和删除文档所需要的步骤顺序：

1. 客户端向 Node 1 发送新建、索引或者删除请求。
2. 节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3，因为分片 0 的主分片目前被分配在 Node 3 上。
3. Node 3 在主分片上面执行请求。如果成功了，它将请求并行转发到 Node 1 和 Node 2 的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功，协调节点向客户端报告成功

consistency 一直性：参数的值可以设为 one （只要主分片状态 ok 就允许执行_写_操作）,all（必须要主分片和所有副本分片的状态没问题才允许执行_写_操作）, 或 quorum 。默认值为 quorum , 即大多数的分片副本状态没问题就允许执行_写_操作。

int( (primary + number_of_replicas) / 2 ) + 1

es怎么实现master选举

master选举当然是由master-eligible节点发起

1. 没有master节点；
2. 脑裂 产生2个master节点

深入理解 Elasticsearch 7.x 新的集群协调层：

https://easyice.cn/archives/332

Elasticsearch的选举机制

https://www.jianshu.com/p/bba684897544

elasticsearch 选主流程

https://www.easyice.cn/archives/164

elasticsearch的master选举机制

https://www.cnblogs.com/jelly12345/p/15319549.html

https://blog.csdn.net/ailiandeziwei/article/details/87856210

错误识别：

主节点ping集群中所有其他的节点，而且每个节点也会ping主节点来确认无需选举。

每个节点每隔discovery.zen.fd.ping.interval（默认是1s）发送一个ping请求，等待discovery.zen.fd.ping.timeout（默认30s）的时间，并尝试最多discovery.zen.fd.ping_retries（默认3）次。如果ping不同，则宣布节点失联，并在需要的时候进行新的分片路由和主节点选举。

一旦一个节点ping不通，节点连接不上，es做的第一件事是自动地将剩余节点中的副本分片升级为主分片，因为所以操作会首先更新为主分片。

副本分片变为主分片之后，集群就会变成黄色的状态，表明有副本分片没有分片到某个节点。es下一步需要创建更多的副本分片来保持索引的高可用。

一旦副本分片重新创建，并用与弥补损失的节点，集群将重新回绿色状态，全部的主分片和其副本分布都分配到某个节点，在这段时间之内由于没有数据丢失，整个集群都可用于搜索和索引，如果有丢失的数据，则集群状态为红色，可以使用多个副本来增强风险

http://localhost:9201/_cluster/state/master_node,nodes?pretty

每一个可以成为master的节点都会保有一个集群状态版本号

每个可以成为master的节点都有一个id

选取集群状态版本号高的作为master，如果 版本号都一致，则选取id最小的节点成为主节点master。

ES写入数据的过程

1. 客户端选择一个node发送请求过去，这个node就是coordinating node (协调节点)
2. coordinating node，对document进行路由，将请求转发给对应的node
3. 实际上的node上的primary shard处理请求，然后将数据同步到replica node
4. coordinating node，如果发现primary node和所有的replica node都搞定之后，就会返回请求到客户端

shard_num = hash(_routing) % num_primary_shards

其中 _routing 是一个可变值，默认是文档的 _id 的值 ，也可以设置成一个自定义的值。 _routing 通过 hash 函数生成一个数字，然后这个数字再除以 num_of_primary_shards （主分片的数量）后得到余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。

写入数据底层原理

1. 数据先写入到buffer里面，在buffer里面的数据时搜索不到的，同时将数据写入到translog日志文件之中；
2. 如果buffer快满了，或是一段时间之后(定时)，就会将buffer数据refresh到一个新的OS cache之中，然后每隔1秒，就会将OS cache的数据写入到segment file之中，但是如果每一秒钟没有新的数据到buffer之中，就会创建一个新的空的segment file，只要buffer中的数据被refresh到OS cache之中，就代表这个数据可以被搜索到了。当然可以通过restful api 和Java api，手动的执行一次refresh操作，就是手动的将buffer中的数据刷入到OS cache之中，让数据立马搜索到，只要数据被输入到OS cache之中，buffer的内容就会被清空了。同时进行的是，数据到shard之后，就会将数据写入到translog之中，每隔5秒将translog之中的数据持久化到磁盘之中
3. 重复以上的操作，每次一条数据写入buffer，同时会写入一条日志到translog日志文件之中去，这个translog文件会不断的变大，当达到一定的程度之后，就会触发commit操作。
4. 将一个commit point写入到磁盘文件，里面标识着这个commit point 对应的所有segment file强行将OS cache 之中的数据都fsync到磁盘文件中去。

解释：translog的作用：在执行commit之前，所有的而数据都是停留在buffer或OS cache之中，无论buffer或OS cache都是内存，一旦这台机器死了，内存的数据就会丢失，所以需要将数据对应的操作写入一个专门的日志问价之中，一旦机器出现宕机，再次重启的时候，es会主动的读取translog之中的日志文件的数据，恢复到内存buffer和OS cache之中。

将现有的translog文件进行清空，然后在重新启动一个translog，此时commit就算是成功了，默认的是每隔30分钟进行一次commit，但是如果translog的文件过大，也会触发commit，整个commit过程就叫做一个flush操作，我们也可以通过ES API,手动执行flush操作，手动将OS cache 的数据fsync到磁盘上面去，记录一个commit point，清空translog文件

补充：其实translog的数据也是先写入到OS cache之中的，默认每隔5秒之中将数据刷新到硬盘中去，也就是说，可能有5秒的数据仅仅停留在buffer或者translog文件的OS cache中，如果此时机器挂了，会丢失5秒的数据，但是这样的性能比较好，我们也可以将每次的操作都必须是直接fsync到磁盘，但是性能会比较差。

如果时删除操作，commit的时候会产生一个.del文件，里面讲某个doc标记为delete状态，那么搜索的时候，会根据.del文件的状态，就知道那个文件被删除了。

如果时更新操作，就是讲原来的doc标识为delete状态，然后重新写入一条数据即可。

buffer每次更新一次，就会产生一个segment file 文件，所以在默认情况之下，就会产生很多的segment file 文件，将会定期执行merge操作

每次merge的时候，就会将多个segment file 文件进行合并为一个，同时将标记为delete的文件进行删除，然后将新的segment file 文件写入到磁盘，这里会写一个commit point，标识所有的新的segment file，然后打开新的segment file供搜索使用。

删除和更新

段是不可改变的，所以既不能从把文档从旧的段中移除，也不能修改旧的段来进行反映文档的更新。 取而代之的是，每个提交点会包含一个 .del 文件，文件中会列出这些被删除文档的段信息。

当一个文档被 “删除” 时，它实际上只是在 .del 文件中被 标记 删除。一个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。

文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除，文档的新版本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就已经被移除。

段合并

由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。

Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。

段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。

合并大的段需要消耗大量的I/O和CPU资源，如果任其发展会影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制，所以搜索仍然 有足够的资源很好地执行

Elasticsearch-head 图形化界面的安装

https://blog.csdn.net/qq_21299835/article/details/106534644

http.cors.enabled: true
http.cors.allow-origin: "*"
# 统一的集群名
cluster.name: my-es
#当前节点名
node.name: node-1
#对外暴露端口使外网访问
network.host: 127.0.0.1
#对外暴露端口
http.port: 9201
#集群间通讯端口号
transport.tcp.port: 9301
#集群的ip集合
discovery.zen.ping.unicast.hosts: ["127.0.0.1:9301","127.0.0.1:9302","127.0.0.1:9303"]


http.cors.enabled: true
http.cors.allow-origin: "*"
# 统一的集群名
cluster.name: my-es
#当前节点名
node.name: node-2
#对外暴露端口使外网访问
network.host: 127.0.0.1
#对外暴露端口
http.port: 9202
#集群间通讯端口号
transport.tcp.port: 9302
#集群的ip集合
discovery.zen.ping.unicast.hosts: ["127.0.0.1:9301","127.0.0.1:9302","127.0.0.1:9303"]

http.cors.enabled: true
http.cors.allow-origin: "*"
# 统一的集群名
cluster.name: my-es
#当前节点名
node.name: node-3
#对外暴露端口使外网访问
network.host: 127.0.0.1
#对外暴露端口
http.port: 9203
#集群间通讯端口号
transport.tcp.port: 9303
#集群的ip集合
discovery.zen.ping.unicast.hosts: ["127.0.0.1:9301","127.0.0.1:9302","127.0.0.1:9303"]