Elasticsearch学习笔记(04) - 基本概念：集群、节点、分片和副本

简介

Elasticsearch本身是一个分布式系统，天然支持高可用和水平扩展。站在运维的角度，我们可能更加关注于部署和监控。本章我们将讲述一些核心的、基本的概念 -- 集群、节点、分片和副本。

架构

我们知道，一个可靠的分布式系统必须具有高可用性和可扩展性。

1. 高可用性
   • 服务可用性 - 允许部分节点停止服务
   • 数据可用性 - 部分节点丢失数据，整个系统不会丢失数据
2. 可扩展性
   • 请求量的上升、数据量的增加，集群系统有能力将数据分散到各个节点上，从而实现水平扩展

而在Elasticsearch中，其分布式架构又带来了以下好处

1. 存储的水平扩展
2. 系统的高可用性，部分节点停止服务，整个集群服务不受影响

Elasticsearch的分布式架构

1. 不同集群是通过集群名称来区分的，默认集群名称为elasticsearch
2. 可在配置文件（elasticsearch.yml）中修改集群名称，也可以在启动命令中通过 cluster.name=${clusterName} 指定
3. 一个集群可以有一个或多个节点

节点

一个节点，其实是一个Elasticsearch的实例。节点本质上是一个Java进程。一台机器可运行多个Elasticsearch进程。但是，在生产环境中，我们建议一台机器运行一个Elasticsearch实例。

每个节点都有自己的名字，可以在配置文件中配置，也可以在启动命令中通过 -E node.name=${nodeName} 指定。

每个节点启动之后，系统会分配一个全局唯一的uid，保存在data目录下。

节点根据其用途和场景，可分为很多种，参考官网的节点说明。

1. Master-eligible节点和Master节点

• 每个节点启动后，默认就是一个Master-eligible节点，但可通过node:master = false来禁止
• Master-eligible节点可参加选主流程，有机会成为Master节点
• 当第一个节点启动的时候，它会将自己选举成为Master节点
• 每个节点都会保存集群的状态，只有Mater节点才可修改集群的状态信息
  1. 集群状态，维护了一个集群中的必要信息，包括：
     • 所有的节点信息
     • 所有的索引及其相关的Mapping和Setting信息
     • 分片的路由信息
  2. 任意节点都能修改信息的话，将导致数据不一致

2. Data节点和Coordinating节点

Data节点，可以保存数据的节点，在数据的水平扩展方面起到了很重要的作用。

Coordinating节点，负责接收客户端请求，并将请求分发到合适的节点，最终又将结果进行汇总。每个节点默认都起到了 Coordinating节点 的作用

3. 其他节点

1. Hot Node & Warm Node 。又叫冷热节点，比如日志场景
2. Machine Learning node 。跑机器学习的job
3. tribe node deprecend 。开始被废弃，使用Cross Cluster Search来代替

4. 节点的配置

1. 开发环境，一个节点可承担多种角色
2. 生产环境，应设置单一节点角色

节点类型	配置参数	默认值
master.eligible节点	node.master	true
Data节点	node.data	true
Ingest节点	node.ingest	true
Coordinating节点	无	无
Machine Learning节点	node.ml	true

分片

在Elasticsearch中，分片分为两种。主分片（Primary shard） & 副本分片（Replica shard）。

• 主分片，解决了数据水平扩展问题。可以将数据分布到集群内的所有节点
  1. 一个分片就是一个运行的Lucene实例
  2. 主分片数在创建索引时指定，后续不允许修改，除非reindex
• 副本分片，解决了数据高可用问题
  1. 副本分片数可动态调整
  2. 增加副本分片数，一定程度上可提高服务可用性、读吞吐量等

接下来，我们看一个节点和分片关系的例子。

节点和分片

在这个例子中，我们创建了一个blogs的索引，其主分片数为3，副本分片为1。
同时，我们有3个节点，分别为Node1、Node2、Node3，每个节点都包含一个主分片和副本分片，且当前主分片和当前主分片关联的副本分片并不在同一个节点上。
通过这种机制，即使某一个节点宕掉了，也不会影响整个集群的功能。

【注意】：关于分片数的设定，需要提前做好容量规划。

• 分片数过小
  1. 后续无法增加节点来实现水平扩展
  2. 单个分片数据量太大，导致数据重新分配耗时
• 分片数过大。7.0开始，默认主分片数由0更改为1，从而解决了over-sharding的问题
  1. 影响搜索结果相关性分数，影响统计结果的准确性
  2. 单个节点上过多分片，资源浪费，也会影响性能

集群的健康状态

1. green - 主副分片都正常
2. yellow - 主分片全部正常分配，副本分片不能正常分配
3. red - 有主分片不能分配，比如：服务器磁盘容量使用超过85%时，创建一个新的索引

在Kibana中，我们可以通过一些接口来查看集群的信息，包括健康状态、节点、分片等。

通过接口 - GET _cluster/health，我们可以看到集群的健康状态。集群名为clusterName，状态为green，节点数为2，激活的主分片数为6，激活的所有分片数为12。

集群健康状态

通过接口 - GET _cat/nodes，我们可以看到节点的信息

节点信息

通过接口 - GET _cat/shards，我们可以看到分片的信息

分片信息

在Kibana的Stack Monitoring中，我们可以通过直观的UI界面，来比较全面地查看这些信息。

Stack Monitoring

除了Kibana，我们还可以通过监控工具Cerebro来实时查看集群的情况。限于篇幅，本章不讲解Cerebro。

总结

本章，我们站在运维的角度，宏观地分析了集群、节点、分片和副本的概念，也了解了查看集群状态的方式，例如Kibana的monitoring、Cerebro等等。