Elasticsearch分布式原理

依然

已于 2022-12-29 10:35:58 修改

阅读量704

点赞数 1

文章标签： elasticsearch 分布式

于 2022-12-28 16:44:42 首次发布

本文链接：https://blog.csdn.net/chenjf0221/article/details/128469716

版权

1：核心配置

cluster.name：集群名称，唯一确定一个集群

node.name：节点名称，一个集群中的节点名称是唯一固定的，不同节点不能同名

node.master：主节点属性值

node.data：数据节点属性值

network.host：本节点的绑定ip，及提供服务的ip地址

http.port：本节点的http端口

transport.port：9300 集群之间通信的端口，若不指定默认：9300

discovery.seed_hosts：节点发现需要配置一些种子节点，与7.X之前老版本： discvoery.zen.ping.unicast.hosts类似，一般配置集群中的全部节点

cluster.initial_master_nodes：指定集群初次选举中用到具有主节点资格的节点，称为集群引导，只在第一次形成集群时需要

开发模式：开发模式是默认配置(未配置集群发现设置)，修改集群配置会触发引导检查，设置项 discovery.type = single-node，此配置为指定节点为单节点发现以绕过引导检查，节点会选举自己成为active master节点

生产模式：如修改了有关集群的配置会触发生产模式，在生产模式下服务启动会触发ES的引导检查或启动检查(bootstrap checks)：在服务启动之前对一些重要的配置项进行检查，检查其配置值是否合理。包括对JVM大小，内存锁，虚拟内存，最大线程数，集群发现相关配置等相关的检查，如果某一项或几项的配置不合理，ES会拒绝启动服务，并且在开发模式下的某些警告会升级成错误信息输出。宁可拒绝服务也要阻止用户启动服务是为了防止用户在对ES的基本使用不了解的前提下启动服务而导致后期性能问题无法解决或麻烦。一旦服务以某种不合理的配置启动，时间久了可能会产生较大的性能问题，但此时集群已变得难以维护。

引导检查(Bootstrap Checks)

检查项：

堆大小检查

文件描述符检查

内存锁检查

最大线程数检查

最大文件大小检查

虚拟内存检查

文件系统映射数检查

客户端JVM检查

串行收集器检查

系统调用过滤器检查

OnError和OnOOMError检查

早期访问检查

所有权限检查

发现配置检查

2：主从模式

主从模式适合节点数量不多，并且节点状态改变(加入集群或者离开集群)不频繁的情况

分布式哈希表支持每小时数千个节点的加入或离开，响应约4-10跳

ES的应用场景一般单个集群中不会有太多节点，节点的数量远远小于单个节点(主节点)所能维护的连接数。并且通常主节点不必经常处理节点的加入离开，处于相对稳定的对等网络中。

3：节点

候选节点/投票节点(master-eligible ，也叫master节点)

默认情况下，master-eligible节点是那些在集群状态发布期间参与选举并执行某些任务的节点，配置了master角色的节点都是有效的投票节点，可以参与选举也可以投票

仅投票节点

配置了master和voting_only角色的节点将成为仅投票节点，仅投票节点虽然也是候选节点，但是在选举过程中仅可以投票而不参与竞选。不过仅投票节点可以同时也是数据节点，不具备被选举为Master的资格，但是参与投票，可以在选举过程中发挥关键票的作用

主节点 active master

避免重负载：主节点负责轻量级集群范围的操作。

(1)创建或删除索引，跟踪哪些节点是集群的一部分以及决定将哪些分片分配给哪些节点。

(2)避免master被其它任务超载，将所有符合master的节点配置为仅具有master的角色的专用节点，使它们能够专注于集群管理。

(3)专用master节点仍将充当协调节点，将请求从客户端路由到集群中其它节点，但是不要以负责均衡器的目的而设置候选节点

(4)一般小型或轻负载的集群主节点具有其它角色和职责，则有可能运行良好，一旦集群中包含多个节点，使用专用的主节点通常是有意义的

任何不是voting-only的master-eligible节点都可以被选举为active master

主节点必须有一个path.data目录，其内容在重启后仍然存在，这是存储集群元数据的地方。集群元数据描述了如何读取存储在数据节点上的数据，因此如果丢失，则无法读取存储在数据节点上的数据

高可用性(HA)集群需要至少三个候选节点，其中至少两个不是仅投票节点，这样即使其中一个节点发生故障，也可以保证剩下的节点能够选举出一个主节点

数据节点

数据节点保存已编入索引的文档的分片。数据节点处理数据相关操作，如CRUP、搜索和聚合。这些操作是I/O密集型，内存密集型和CPU密集型的。监控这些资源并在它们过载时添加更多数据节点非常重要

协调节点

如果主动关闭了master、data和ingest的角色配置，当前节点就剩下一个只能路由请求，处理搜索减少阶段和分发批量索引功能的仅协调节点。本质上，仅协调节点就相当于一个只能负载均衡器。

仅协调节点过的会增加集群负担，因为主节点更新集群状态必须等待每个节点的确认，而仅协调节点从这个角度讲是一种负担。数据节点可以完成转发任务

4：ES模块：Mudules

Cluster：

Allocation：

Bootstrap：

Ingest：

Monitor：

Discovery：

Gateway：

Indices：

HTTP：

Transport：

5：分片 Shard

Shard即数据分片，是ES的数据载体。

在ES中数据分为parimary shard(主分片)和replica shard(副本分片)，每一个primary承载单个索引的一部分数据，分布于各个节点。replica为某个primary的副本，即备份。分片分配的原则是尽量均匀的分配在集群中的各个节点，以最大程度降低部分shard在出现意外时对整个集群乃至服务造成的影响。每个分片就是一个Lucene实例，具有完整的功能。

6：分片创建策略

分片的分配策略极大程度上都是围绕如何提高高可用性而来的，如分片分配感知，强制感知

分片的分配策略主要从两个指标来衡量：数量和单个分片的大小

分片分配策略

(1)ES使用数据分片(shard)来提高服务的可用性，将数据分散保存在不同的节点上以降低单个节点发生故障时对数据完整性的影响，同时使用副本(replica)来保证数据的完整性。

(2)ES在分配单个索引的分片时会将每个分片尽可能分配到更多的节点上。实际情况取决于集群拥有的分片和索引的数量以及它们的大小，不一定总能均匀的分布。

(3)Primary只能在索引创建时配置数量，而replica可以在任何时间分配，并且primary支持读和写操作，replica只支持客户端的读取操作，数据由es自动管理，从primary同步

(4)ES不允许primary和它的replica放在同一个节点中，且同一个节点不接受完全相同的两个replica

(5)同一个节点允许多个索引的分片同时存在

7：分片的数量

避免分片过多：大多数搜索会命中多个分片。每个分片在单个CPU线程上运行搜索，虽然分片可以运行多个并发搜索，但跨大量分片的搜索会耗尽节点的搜索线程池，会导致低吞吐量和缓慢的搜索速度

分片越少越好：每个分片都使用内存和CPU资源，在大多数情况下，一个小组大分片比许多小分片使用更少的资源

分片的合理容量：10GB-50GB。不是硬性限制，10GB-50GB之间的分片往往效果很好。根据网络和用例，也许可以使用更大的分片。在索引的生命周期管理中，一般设置50GB为单个索引的最大阈值

堆内存容量和分片数量的关联：小于20分片/每GB堆内存，一个节点可以容纳的分片数量与节点的堆内存成功正比。如一个30GB堆内存的节点最多有600个分片，如果节点超过每GB20个分片，考虑添加另一个节点

查询当前节点堆内存大小：GET _cat/nodes?v=true&h=heap.current

避免重负载节点：如果分配给特定节点的分片过多，会造成当前节点为重负载节点

8：重要配置

自定义属性： node.attr.{attribute}

查看节点属性：GET _cat/nodeattrs?v

索引级配置

index.routing.allocation.include.{attirbute}：表示索引可以分配在包含多个值中的一个节点上

index.routing.allocation.require.{attribute}：表示索引要分配在包含索引指定值的节点上(一般设置一个值)

index.routing.allocation.exclude.{attribute}：表示索引只能分配在不包含所有指定值的节点上

//索引创建之前执行

PUT <index_name>

{

"setting":{

"number_of_shards" : 3,

"number_of_replicas" : 1,

"index.routing.allocation.include._name":"node1"

}

集群级配置

elasticsearch修改集群范围设置提供两种方式

persistent：永久性修改，persistent相关的修改保存在/path.data/cluster.name/ndoes/0/_state/global-n.st，如果删除设置，删除此文件即可

transient：集群重启后失效

PUT _cluster/settings

{

"persistent":{

"cluster.routing.allocation.awareness.attributes" : "rack_id"

}

9：索引分片分配：Index Shard Allocation

分片均衡策略：shard rebalance

当集群在每个节点上具有相同数量的分片而没有集中在任何节点上的任何索引的分片时，集群时平衡的。Elasticsearch运行一个称为rebalancing的自动过程，它在集群中的节点之间移动分片以改善其平衡。重新平衡遵循所有其他分片分配规则，如分配过滤，强制意识，这可能会阻止它完全平衡集群。重新平衡会在配置的规则内实现最平衡的集群

cluster.routing.rebalance.enable：动态为特定类型的分片启用或禁用重新平衡

all (默认) 允许对所有类型的分片进行分片平衡

primaries 只允许主分片的分片平衡

replicas 仅允许对副本分片进行分片平衡

none 任何索引都不允许进行任何类型的分片平衡

cluster.routing.allocation.allow_rebalance：动态指定何时允许分片重新平衡

always 始终允许重新平衡

indices_primaries_active 仅当集群中所主有节点都已分配时

indices_all_active (默认)仅当集群中的所有分片(主分片和副本)都被分配时

延迟分配策略（默认1m）

当节点出于任何原因离开集群时，主节点会做出以下反应

(1)将副本分片提升为主分片以替换节点上的任何主分片