Elasticsearch集群内的原理

Upaaui

已于 2023-10-12 11:30:17 修改

阅读量378

点赞数

分类专栏： # Elasticsearch 文章标签： elasticsearch

于 2023-08-30 15:42:18 首次发布

本文链接：https://blog.csdn.net/qq_42428269/article/details/132584077

版权

Elasticsearch 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

简介

一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成，它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。

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

作为用户，我们可以将请求发送到集群中的任何节点，包括主节点。每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。

查看集群健康状态：

#curl -X GET "localhost:9200/_cluster/health"

返回值status 字段指示着当前集群在总体上是否工作正常：

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

Yellow：所有的主分片都正常运行，但不是所有的副本分片都正常运行。Red：有主分片没能正常运行。
添加索引：索引实际上是指向一个或者多个物理分片的逻辑命名空间。一个分片是一个底层的工作单元，它仅保存了全部数据中的一部分。一个分片是一个 Lucene 的实例，以及它本身就是一个完整的搜索引擎。我们的文档被存储和索引到分片内，但是应用程序是直接与索引而不是与分片进行交互。Elasticsearch 利用分片将数据分发到集群内各处。一个分片可以是主分片或者副本分片。索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量。技术上来说，一个主分片最大能够存储 Integer.MAX_VALUE - 128 个文档：一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务。副本分片数可以随时修改。

number_of_shards：主分片个数
number_of_replicas：副本分片格式

添加第二个节点：在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。但是在不同机器上启动节点的时候，为了加入到同一集群，需要配置一个可连接到的单播主机列表。

discovery.zen.ping.unicast.hosts: ["host1", "host2:port”]

分片内部原理

分片是如何工作的
- 为什么ES搜索是近实时性的
- 为什么CRUD 操作也是实时性
- ES 是怎么保证更新被持久化时断电也不丢失数据
- 为什么删除文档不会立即释放空间
- refresh, flush, 和 optimize API 作用
使文本可被搜索 倒排索引的结构 词项文档列表 Term | Doc 1 | Doc 2 | Doc 3 | ... brown | X | | X | ... fox | X | X | X | ... quick | X | X | | ... the | X | | X | ...
倒排索引的不变性
- 不需要锁
- 可被内核的文件系统缓存，停留在内存中，大部分请求会直接请求到内存，不会落到磁盘上
- filter缓存，在索引的生命周期始终有效。不需要再每次数据改变时重建
- 写入单个较大的倒排索引使允许数据被压缩
如何在索引不变情况下 动态更新索引
- 使用更多的索引，来解决这个问题
- 通过增加新的补充索引来反映新近的修改，而不是直接重写整个倒排索引
- 一个 Lucene 索引包含一个提交点和三个段
- 逐段搜索的流程
  - 新文档被收集到内存索引缓存
  - 不时地, 缓存被提交
    - 一个新的段----一个追加的倒排索引--被写入磁盘
    - 一个新的包含新段名字的提交点被写入磁盘
    - 磁盘进行同步 — 所有在文件系统缓存中等待的写入都刷新到磁盘
  - 新的段被开启，让它包含的文档可见以被搜索
  - 内存缓存被清空，等待接收新的文档
- 一个在内存缓存中包含新文档的 Lucene 索引
- 在一次提交后，一个新的段被添加到提交点而且缓存被清空
删除和更新文档
- 段是不可改变的，每个提交点都会有一个.del文件。在这个文件中能列出这些删除文档的短信息
- 当文档被删除时不是删除，只是在.del文件中被登记
- 文档的更新也是这样的，先将更新的文档标记为删除。然后文档的新版本被索引到一个新的段中

近实时搜索

提交（Commiting）一个新的段到磁盘需要一个 fsync 来确保段被物理性地写入磁盘，这样在断电的时候就不会丢失数据。但是每次提交的一个新的段都fsync 这样操作代价过大。可以使用下面这种更轻量的方式
在内存缓冲区中包含了新文档的 Lucene 索引
- Lucene 允许新段被写入和打开--使其包含的文档在未进行一次完整提交时便对搜索可见
缓冲区的内容已经被写入一个可被搜索的段中，但还没有进行提交
- 这里新段会被先写入到文件系统缓存--这一步代价会比较低，稍后再被刷新到磁盘--这一步代价比较高
默认情况下每个分片会每秒自动刷新一次
- 近实时搜索: 文档的变化并不是立即对搜索可见，但会在一秒之内变为可见
- POST /_refresh // 刷新Refresh 所有的索引
- POST /blogs/_refresh // 只刷新Refresh blogs 索引 可以在settings 设置对定时刷新频率的大小

PUT /my_logs
{
"settings": {
"refresh_interval": "30s" //30秒刷新一次
"refresh_interval": "-1" //关闭自动刷新
"refresh_interval": "1s"//每秒自动刷新
}
}

复制

持久化变更

在没有 fsync 把数据从内存刷新到硬盘中，我们不能保证数据在断电或程序退出时之后依然存在

即时每秒刷新，也不能实现近实时搜索。我们任然有另外的方法确保从失败中回复数据
ES 增加一个translog，或者叫做事务日志。在每次操作是均进行日志记录
整个流程是如下的操作
1. 一个文档被索引之后，就会被添加到内存缓冲区，并且追加到了 translog -
1. 刷新（refresh）使分片处于缓存被清空，但是事务日志不会的状态
  - 内存缓冲区的文档被写入新的段中，但是没有进行fsync
  - 段被打开，且可被搜索到
  - 内存缓冲区被清空
2. 进程继续进行，更多的文档被添加到内存缓冲区和追加的事务日志中
3. 每隔一段时间，translog太大或索引被刷新。一个新的translog被创建，并且被全量提交 -
- 所有内存缓冲区的文档都被写入一个新的段中
- 缓冲区内清空
- 一个提交点被写入硬盘
- 文件系统缓存通过fsync被刷新
- 老的translog 被删除
translog 提供所有没有被刷新到磁盘操作的一个持久化记录。当ES启动时，会根据最后一个提交点去恢复已知的段
translog 也可供用来提供实时的CRUD。但我们进行一些CRUD操作时，它会首先检查translog任何最近的变更。
flush API ** 执行一次提交，并截断translog**的操作
- 分片默认每30M自动flush一次。translog太大也会自动flush
- 可通过自己执行flush API操作 POST /blogs/_flush //刷新索引 POST /_flush?wait_for_ongoing //刷新索引并等待所有的刷新结果返回