Elasticsearch 7.x 之节点、集群、分片及副本

导读	Elasticsearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java语言开发的，并作为Apache许可条款下的开放源码发布，是一种流行的企业级搜索引擎。

Elasticsearch 分布式特性包括如下几个点：

什么是高可用？CAP 定理是分布式系统的基础，也是分布式系统的 3 个指标：

Consistency（一致性）

Availability（可用性）

Partition tolerance（分区容错性）

那高可用（High Availability）是什么？高可用，简称 HA，是系统一种特征或者指标，通常是指，提供一定性能上的服务运行时间，高于平均正常时间段。反之，消除系统服务不可用的时间。

衡量系统是否满足高可用，就是当一台或者多台服务器宕机的时候，系统整体和服务依然正常可用。举个例子，一些知名的网站保证 4 个 9 以上的可用性，也就是可用性超过 99.99%。那 0.01% 就是所谓故障时间的百分比。

Elasticsearch 在高可用性上，体现如下两点：

服务可用性：允许部分节点停止服务，整体服务没有影响

数据可用性：允许部分节点丢失，最终不会丢失数据

随着公司业务发展，Elasticsearch 也面临两个挑战：

搜索数据量从百万到亿量级

搜索请求 QPS 也猛增

那么需要将原来节点和增量数据重新从 10 个节点分布到 100 个节点。Elasticsearch 可以横向扩展至数百（甚至数千）的服务器节点，同时可以处理PB级数据。Elasticsearch 为了可扩展性而生，由小规模集群增长为大规模集群的过程几乎完全自动化，这是水平扩展的体现。

上面通过可扩展性，可以看出 Elasticsearch 分布式的好处明显：

存储可以水平扩容，水平空间换时间

部分节点停止服务，整个集群服务不受影响，照样正常提供服务

Elasticsearch 在后台自动完成了分布式相关工作，如下：

自动分配文档到不同分片或者多节点上

均衡分配分片到集群节点上，index 和 search 操作时进行负载均衡

复制每个分片，支持数据冗余，防止硬件故障数据丢失

集群扩容时，无缝整合新节点，并且重新分配分片

Elasticsearch 集群知识点如下：

不同集群通过名字区分，默认集群名称为 “elasticsearch”

集群名 cluster name ，可以通过配置文件修改或者命令行 -E cluster.name=user-es-cluster 进行设置一个集群由多个节点组成

Elasticsearch 集群有多个节点组成，形成分布式集群。那么，什么是节点呢？

节点（Node），就是一个 Elasticsearch 应用实例。大家都知道 Elasticsearch 源代码是 Java 写的，那么节点就是一个 Java 进程。

所以类似 Spring 应用一样，一台服务器或者本机可以运行多个节点，只要对应的端口不同即可。但生产服务器中，一般一台服务器运行一个 Elasticsearch 节点。还有需要注意：

Elasticsearch 都会有 name ，通过 -E node.name=node01 指定或者配置文件中配置

每个节点启动成功，都会分配对应得一个 UID ，保存在 data 目录

可以通过命令 _cluster/health 查看集群的健康状态，如下：

Green 主分片与副本分片都正常

Yellow 主分片正常，副本分片不正常

Red 有主分片不正常，可能某个分片容量超过了磁盘大小等

如图，有主（Master）节点和其他节点。那么节点有多少类型呢？

Elasticsearch 被启动后，默认就是 Master-eligible Node。然后通过参与选主过程，可以成为 Master Node。具体选主原理，后续单独写一篇文章。Master Node 有什么作用呢？

Master Node 负责同步集群状态信息：

所有节点信息

所有索引即其 Mapping 和 Setting 信息

所有分片路由信息

只能 Master 节点可以修改信息，是因为这样就能保证数据得一致性

Data Node，又称数据节点。用于保存数据，其在数据扩展上起至关重要的作用。

Coordinating Node，是负责接收任何 Client 的请求，包括 REST Client 等。该节点将请求分发到合适的节点，最终把结果汇集到一起。一般来说，每个节点默认起到了 Coordinating Node 的职责。

还有其他节点类型，虽然不常见，但需要知道：

Hot & Warm Node：不同硬件配置的 Data Node，用来实现冷热数据节点架构，降低运维部署的成本

Machine Learning Node：负责机器学习的节点

Tribe Node：负责连接不同的集群。支持跨集群搜索 Cross Cluster Search

一般在开发环境中，设置单一的角色节点：

master node：通过 node.master 配置，默认 true

data node：通过 node.data 配置，默认 true

ingest node：通过 node.ingest 配置，默认 true

coordinating node：默认每个节点都是 coordinating 节点，设置其他类型全部为 false。

machine learning：通过 node.ml 配置，默认 true，需要通过 x-pack 开启。

同样看这个图，3 个节点分别为 Node1、Node2、Node3。并且 Node3 上面有一个主分片 P0 和一个副本 R2。那什么是主分片呢？

主分片，用来解决数据水平扩展的问题。比如上图这个解决可以将数据分布到所有节点上：

节点上可以有主分片，也可以没有主分片

主分片在索引创建的时候确定，后续不允许修改。除非 Reindex 操作进行修改

副本，用来备份数据，提高数据的高可用性。副本分片是主分片的拷贝

副本分片数，可以动态调整

增加副本数，可以一定程度上提高服务读取的吞吐和可用性

如何查看 Elasticsearch 集群的分片配置呢？可以从 settings 从看出：

number_of_shards 主分片数
number_of_replicas 副本分片数
{
  "my_index": {
    "settings": {
      "index": {
        "number_of_shards": "8",
        "number_of_replicas": "1"
      }
    }
  }
}

实战建议：对生产环境中，分片设置很重要，需要最好容量评估与规划

根据数据容量评估分配数，设置过小，后续无法水平扩展；单分片数据量太大，也容易导致数据分片耗时严重

分片数设置如果太大，会导致资源浪费，性能降低；同时也会影响搜索结果打分和搜索准确性

索引评估，每个索引下面的单分片数不用太大。如何评估呢？比如这个索引 100 G 数据量，那设置 10 个分片，平均每个分片数据量就是 10G 。每个分片 10 G 数据量这么大，耗时肯定严重。所以根据评估的数据量合理安排分片数即可。如果需要调整主分片数，那么需要进行 reindex 等迁索引操作。

比如知道了搜索性能场景，例如多少数据量，多大的写入，是写为主还是查询为主等等，才可以确定：

磁盘，推荐 SSD，JVM最大 Xmx 不要超过30G。副本分片至少设置为1。主分片，单个存储不要超过 30 GB，按照这个你推算出分片数，进行设定。

集群中磁盘快满的时候，你再增加机器，确实可能导致新建的索引全部分配到新节点上去的可能性。最终导致数据分配不均。所以要记得监控集群，到70%就需要考虑删除数据或是增加节点可以设置最大分片数缓解这个问题。

分片的尺寸如果过大，确实也没有快速恢复的办法，所以尽量保证分片的size在40G以下。