ES集群核心原理

xianghan收藏册

已于 2022-10-19 07:20:54 修改

阅读量717

点赞数 1

分类专栏： ElasticSearch 文章标签： elasticsearch 大数据搜索引擎

于 2022-10-18 08:27:59 首次发布

本文链接：https://blog.csdn.net/xianghanscce/article/details/127380671

版权

ElasticSearch 专栏收录该内容

11 篇文章 0 订阅

订阅专栏

ES集群核心原理

1、节点类型

1）master节点master节点特点：

整个集群只会有一个master节点，它将负责管理集群范围内的所有变更，例如增加、删除索引；或者增加、删除节点等。而master节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个master节点的情况下，即使流量的增加它也不会成为瓶颈。

master节点需要从众多候选master节点中选择一个。

master节点的作用：

负责集群节点上下线，shard分片的重新分配。创建、删除索引。

负责接收集群状态(`cluster state`)的变化，并推送给所有节点。集群节点都各有一份完整的cluster state，只是master node负责维护。

利用自身空闲资源，协调创建索引请求或者查询请求，将请求分发到相关node服务器。

master节点的配置如下（elasticsearch.yml）

node.master: true

node.data: false

数据节点

负责存储数据，提供建立索引和搜索索引的服务。

data节点消耗内存和磁盘IO的性能比较大。

data节点的配置如下（elasticsearch.yml）

node.master: false

node.data: true

协调节点

不会被选作主节点，也不会存储任何索引数据。主要用于查询负载均衡。将查询请求分发给多个node服务器，并对结果进行汇总处理。

协调节点的作用：

第一：诸如搜索请求或批量索引请求之类的请求可能涉及保存在不同数据节点上的数据。例如，搜索请求在两个阶段中执行（query 和 fetch），这两个阶段由接收客户端请求的节点 - 协调节点协调。

第二：在请求阶段，协调节点将请求转发到保存数据的数据节点。每个数据节点在本地执行请求并将其结果返回给协调节点。在收集fetch阶段，协调节点将每个数据节点的结果汇集为单个全局结果集。

第三：每个节点都隐式地是一个协调节点。这意味着将所有三个node.master，node.data设置为false 的节点作为仅用作协调节点，无法禁用该节点。结果，这样的节点需要具有足够的内存和CPU以便处理收集阶段。

协调节点最好不要分离，跟数据节点在一起就行。

协调节点的配置如下（elasticsearch.yml）

node.master: false

node.data: false

注意：

一个节点可以充当一个或多个角色。默认 3个角色都有。

2、索引分片

分片是Elasticsearch在集群中分发数据的关键。把分片想象成数据的容器。文档存储在分片中，然后分片分配到你集群中的节点上。当你的集群扩容或缩小，Elasticsearch将会自动在你的节点间迁移分片，以使集群保持平衡。

# 分片详情(文档存储、主分片、分片引擎)

分片可以是主分片(primary shard)或者是复制分片(replica shard)。你索引中的每个文档属于一个单独的主分片，所以主分片的数量决定了索引最多能存储多少数据，每一个分片都是一个搜索引擎。

# 分片存储大小限制

理论上主分片能存储的数据大小是没有限制的，限制取决于你实际的使用情况。分片的最大容量完全取决于你的使用状况：硬件存储的大小、文档的大小和复杂度、如何索引和查询你的文档，以及你期望的响应时间。

# 副本分片作用

复制分片只是主分片的一个副本，它可以防止硬件故障导致的数据丢失，同时可以提供读请求，比如搜索或者从别的shard取回文档。

# 主分片数量及副本分片数量

当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整。

3、集群选举

涉及配置参数

1、如果同时启动，按照nodeid进行排序，取出最小的做为master节点

2、如果不是同时启动，则先启动的候选master节点，会竞选为master节点。

# 如果`node.master`设置为了false，则该节点没资格参与`master`选举。

node.master = true

# 默认3秒，最好增加这个参数值，避免网络慢或者拥塞，确保集群启动稳定性

discovery.zen.ping_timeout: 3s

# 用于控制选举行为发生的集群最小master节点数量，防止脑裂现象

discovery.zen.minimum_master_nodes : 2 # 新节点加入集群的等待时间discovery.zen.join_timeout : 10s

#设置集群自动发现机器ip集合discovery.zen.ping.unicast.hosts:

["192.168.68.129:9300","192.168.68.130:9300","192.168.68.131:9300

新节点加入

节点完成选举后，新节点加入，会发送join request 到master 节点。

宕机再次选举

如果宕机，集群node会再次进行ping 过程，并选出一个新的master 。

4、脑裂问题

什么是脑裂现象

由于部分节点网络断开，集群分成两部分，且这两部分都有master选举权。就成形成一个与原集群一样名字的集群，这种情况称为集群脑裂（split-brain）现象。这个问题非常危险，因为两个新形成的集群会同时索引和修改集群的数据。

解决方案

# 决定选举一个master最少需要多少master候选节点。默认是1。

# 这个参数必须大于等于为集群中master候选节点的quorum数量，也就是大多数。

# quorum算法：master候选节点数量 / 2 + 1

# 例如一个有3个节点的集群，minimum_master_nodes 应该被设置成 3/2 + 1 = 2（向下取整） discovery.zen.minimum_master_nodes:2

# 等待ping响应的超时时间,默认值是3秒。如果网络缓慢或拥塞，会造成集群重新选举，建议略微调大这个值。

# 这个参数不仅仅适应更高的网络延迟，也适用于在一个由于超负荷而响应缓慢的节点的情况。

discovery.zen.ping.timeout:10s

# 当集群中没有活动的Master节点后，该设置指定了哪些操作（read、write）需要被拒绝（即阻塞执行）。有两个设置值：all和write，默认为wirte。

discovery.zen.no_master_block : write

场景分析

一个生产环境的es集群，至少要有3个节点，同时将discovery.zen.minimum_master_nodes设置为

2，那么这个是参数是如何避免脑裂问题的产生的呢？

比如我们有3个节点，quorum是2。现在网络故障，1个节点在一个网络区域，另外2个节点在另外一个网络区域，不同的网络区域内无法通信。这个时候有两种情况情况：

1. 如果master是单独的那个节点，另外2个节点是master候选节点，那么此时那个单独的master节点因为没有指定数量的候选master node在自己当前所在的集群内，因此就会取消当前master的角色，尝试重新选举，但是无法选举成功。然后另外一个网络区域内的node因为无法连接到master，就会发起重新选举，因为有两个master候选节点，满足了quorum，因此可以成功选举出一个master。此时集群中就会还是只有一个master。
2. 如果master和另外一个node在一个网络区域内，然后一个node单独在一个网络区域内。那么此时那个单独的node因为连接不上master，会尝试发起选举，但是因为master候选节点数量不到quorum，因此无法选举出master。而另外一个网络区域内，原先的那个master还会继续工作。这也可以保证集群内只有一个master节点。

综上所述，通过在elasticsearch.yml 中配置discovery.zen.minimum_master_nodes: 2 ，就可以避免脑裂问题的产生。

但是因为ES集群是可以动态增加和下线节点的，所以可能随时会改变quorum 。所以这个参数也是可以通过api随时修改的，特别是在节点上线和下线的时候，都需要作出对应的修改。而且一旦修改过后，这个配置就会持久化保存下来

PUT /_cluster/settings { "persistent" : { "discovery.zen.minimum_master_nodes" : 2 } }

5、集群扩展

横向扩展

一个索引可以存储超出单个结点硬件限制的大量数据。

# 问题：随着应用需求的增长，我们该如何扩展？

如果我们启动第三个节点，我们的集群会重新组织自己。分片已经被重新分配以平衡负载

Node3 包含了分别来自 Node 1 和 Node 2 的一个分片，这样每个节点就有两个分片，和之前相比少了一个，这意味着每个节点上的分片将获得更多的硬件资源（CPU、RAM、I/O）

注意：分片本身就是一个完整的搜索引擎，它可以使用单一节点的所有资源。我们拥有6个分片（3个主分片和三个复制分片），最多可以扩展到6个节点，每个节点上有一个分片，每个分片可以100%使用这个节点的资源。

继续扩展

如果我们要扩展到6个以上的节点，要怎么做？

主分片的数量在创建索引时已经确定。实际上，这个数量定义了能存储到索引里数据的最大数量（实际的数量取决于你的数据、硬件和应用场景）。

然而，主分片或者复制分片都可以处理读请求——搜索或文档检索，所以数据的冗余越多，我们能处理的搜索吞吐量就越大。复制分片的数量可以在运行中的集群中动态地变更，这允许我们可以根据需求扩大或者缩小规模。让我们把复制分片的数量从原来的 1 增加到 2 ：

更新副本数量：

# 更新副本数量

PUT /blogs/_settings

{

"number_of_replicas" : 2

}

从图中可以看出，索引现在有9个分片：3个主分片和6个复制分片。这意味着我们能够扩展到9个节点，再次变成每个节点一个分片。这样使我们的搜索性能相比原始的三节点集群增加三倍。

当然，在同样数量的节点上增加更多的复制分片并不能提高性能，因为这样做的话平均每个分片的所占有的硬件资源就减少了（大部分请求都聚集到了分片少的节点，导致一个节点吞吐量太大，反而降低性能），你需要增加硬件来提高吞吐量。不过这些额外的复制节点使我们有更多的冗余：通过以上对节点的设置，我们能够承受两个节点故障而不丢失数据。