简介
Elasticsearch本身是一个分布式系统，天然支持高可用和水平扩展。站在运维的角度，我们可能更加关注于部署和监控。本章我们将讲述一些核心的、基本的概念 -- 集群、节点、分片和副本。
架构
我们知道，一个可靠的分布式系统必须具有高可用性和可扩展性。
- 高可用性
- 服务可用性 - 允许部分节点停止服务
- 数据可用性 - 部分节点丢失数据，整个系统不会丢失数据
- 可扩展性
- 请求量的上升、数据量的增加，集群系统有能力将数据分散到各个节点上，从而实现水平扩展
而在Elasticsearch中，其分布式架构又带来了以下好处
- 存储的水平扩展
- 系统的高可用性，部分节点停止服务，整个集群服务不受影响
Elasticsearch的分布式架构
- 不同集群是通过集群名称来区分的，默认集群名称为elasticsearch
- 可在配置文件（elasticsearch.yml）中修改集群名称，也可以在启动命令中通过
cluster.name=${clusterName}指定 - 一个集群可以有一个或多个节点
节点
一个节点，其实是一个Elasticsearch的实例。节点本质上是一个Java进程。一台机器可运行多个Elasticsearch进程。但是，在生产环境中，我们建议一台机器运行一个Elasticsearch实例。
每个节点都有自己的名字，可以在配置文件中配置，也可以在启动命令中通过 -E node.name=${nodeName} 指定。
每个节点启动之后，系统会分配一个全局唯一的uid，保存在data目录下。
节点根据其用途和场景，可分为很多种，参考官网的节点说明。
1. Master-eligible节点和Master节点
- 每个节点启动后，默认就是一个Master-eligible节点，但可通过
node:master = false来禁止 - Master-eligible节点可参加选主流程，有机会成为Master节点
- 当第一个节点启动的时候，它会将自己选举成为Master节点
- 每个节点都会保存集群的状态，只有Mater节点才可修改集群的状态信息
- 集群状态，维护了一个集群中的必要信息，包括：
- 所有的节点信息
- 所有的索引及其相关的Mapping和Setting信息
- 分片的路由信息
- 任意节点都能修改信息的话，将导致数据不一致
- 集群状态，维护了一个集群中的必要信息，包括：
2. Data节点和Coordinating节点
Data节点，可以保存数据的节点，在数据的水平扩展方面起到了很重要的作用。
Coordinating节点，负责接收客户端请求，并将请求分发到合适的节点，最终又将结果进行汇总。每个节点默认都起到了 Coordinating节点 的作用
3. 其他节点
- Hot Node & Warm Node 。又叫冷热节点，比如日志场景
- Machine Learning node 。跑机器学习的job
- tribe node deprecend 。开始被废弃，使用Cross Cluster Search来代替
4. 节点的配置
- 开发环境，一个节点可承担多种角色
- 生产环境，应设置单一节点角色
| 节点类型 | 配置参数 | 默认值 |
|---|---|---|
| master.eligible节点 | node.master | true |
| Data节点 | node.data | true |
| Ingest节点 | node.ingest | true |
| Coordinating节点 | 无 | 无 |
| Machine Learning节点 | node.ml | true |
分片
在Elasticsearch中，分片分为两种。主分片（Primary shard） & 副本分片（Replica shard）。
- 主分片，解决了数据水平扩展问题。可以将数据分布到集群内的所有节点
- 一个分片就是一个运行的Lucene实例
- 主分片数在创建索引时指定，后续不允许修改，除非reindex
- 副本分片，解决了数据高可用问题
- 副本分片数可动态调整
- 增加副本分片数，一定程度上可提高服务可用性、读吞吐量等
接下来，我们看一个节点和分片关系的例子。
在这个例子中，我们创建了一个blogs的索引，其主分片数为3，副本分片为1。
同时，我们有3个节点，分别为Node1、Node2、Node3，每个节点都包含一个主分片和副本分片，且当前主分片和当前主分片关联的副本分片并不在同一个节点上。
通过这种机制，即使某一个节点宕掉了，也不会影响整个集群的功能。
【注意】：关于分片数的设定，需要提前做好容量规划。
- 分片数过小
- 后续无法增加节点来实现水平扩展
- 单个分片数据量太大，导致数据重新分配耗时
- 分片数过大。7.0开始，默认主分片数由0更改为1，从而解决了
over-sharding的问题- 影响搜索结果相关性分数，影响统计结果的准确性
- 单个节点上过多分片，资源浪费，也会影响性能
集群的健康状态
- green - 主副分片都正常
- yellow - 主分片全部正常分配，副本分片不能正常分配
- red - 有主分片不能分配，比如：服务器磁盘容量使用超过85%时，创建一个新的索引
在Kibana中，我们可以通过一些接口来查看集群的信息，包括健康状态、节点、分片等。
通过接口 - GET _cluster/health，我们可以看到集群的健康状态。集群名为clusterName，状态为green，节点数为2，激活的主分片数为6，激活的所有分片数为12。
通过接口 - GET _cat/nodes，我们可以看到节点的信息
通过接口 - GET _cat/shards，我们可以看到分片的信息
在Kibana的Stack Monitoring中，我们可以通过直观的UI界面，来比较全面地查看这些信息。
除了Kibana，我们还可以通过监控工具Cerebro来实时查看集群的情况。限于篇幅，本章不讲解Cerebro。
总结
本章，我们站在运维的角度，宏观地分析了集群、节点、分片和副本的概念，也了解了查看集群状态的方式，例如Kibana的monitoring、Cerebro等等。
