背景：目前国内有大量的公司都在使用 Elasticsearch，包括阿里、京东、滴滴、今日头条、小米、vivo等诸多知名公司。除了搜索功能之外，Elasticsearch还结合Kibana、Logstash、Elastic Stack还被广泛运用在大数据近实时分析领域，包括日志分析、指标监控等多个领域。 

本节内容：了解ElasticSearch集群的水平扩容和数据保障机制。

目录

1、空集群概念与主从节点职能

2、如何判断一个集群是否健康

2.1 green

2.2 yellow

2.3 red

3、添加索引分析

4、如何对故障进行转移

5、如何对集群做水平扩容

---

1、 空集群概念与主从节点职能

当启动了一个单独的节点，并且里面不包含任何的数据和索引，这个时候的集群被称为空集群。

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

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

当发起一个请求后，客户端可以将请求发送到集群中的任何一个可用节点 ，当然也包括主节点。 每个节点都知道任意文档所处的位置，并且能够将客户端的请求直接转发到存储所需文档的节点。

另外，无论客户端将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。参考前面文章  一张图让你读懂ElasticSearch强大的搜索能力

2、如何判断一个集群是否健康

Elasticsearch的集群监控信息中包含了许多的统计数据，其中最为重要的一项就是集群健康状态 ， 它在status字段中展示为 green、yellow或red。

集群监控查询请求

http://127.0.0.1:9200/_cluster/health

请求返回结果

status 字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下：

2.1 green

表示所有的主分片和副本分片都正常运行。

2.2 yellow

表示所有的主分片都正常运行，但不是所有的副本分片都正常运行。

2.3 red

表示有主分片没能正常运行。

回到我们的请求结果，集群status值为yellow 。集群的健康状况为yellow则表示全部 主 分片都正常运行（集群可以正常服务所有请求），但是副本分片没有全部处在正常状态。

实际上，从返回结果 unassigned_shards，发现2个副本分片都是 unassigned —— 它们都没有被分配到任何节点。 在同一个节点上既保存原始数据又保存副本是没有意义的，因为一旦失去了那个节点，我们也将丢失该节点上的所有副本数据。此时，当前我们的集群是正常运行的，但是在硬件故障时有丢失数据的风险。

3、添加索引分析

我们往 Elasticsearch 添加数据时需要用到索引 —— 保存相关数据的地方。 索引实际上是指向一个或者多个物理分片的逻辑命名空间 。

一个分片是一个底层的工作单元 ，它仅保存了全部数据中的一部分。 在后面的分片内部机制中，我将详细介绍分片是如何工作的，而现在我们只需知道一个分片是一个 Lucene 的实例，以及它本身就是一个完整的搜索引擎。 我们的文档被存储和索引到分片内，但应用程序是直接与索引进行交互，而不是与分片。

我们知道Elasticsearch是利用分片将数据分发到集群内各节点。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。 当集群规模扩大或者缩小时， Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。

一个分片可以是主分片，也可以是副本分片。 索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量。

从理论上来讲，一个主分片最大能够存储 Integer.MAX_VALUE - 128 个文档，但是实际最大值还需要参考你的使用场景：包括你使用的硬件， 文档的大小和复杂程度，索引和查询文档的方式以及你期望的响应时长。

一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务。在索引建立的时候就已经确定了主分片数，但是副本分片数可以随时修改。
 

4、如何对故障进行转移

当集群中只有一个节点在运行时，意味着会有一个单点故障问题。

如何解决呢？

幸运的是，我们只需再启动一个节点即可防止数据丢失。

那如何启动第二个节点呢？

为了测试第二个节点启动后的情况，你可以在同一个目录内，完全依照启动第一个节点的方式来启动一个新节点。安装过程参考前面的文章 Elasticsearch各版本特性总结。保证多个节点可以共享同一个目录。（由于篇幅问题，我会在后面单独章节演示单机多实例）

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

当启动了第二个节点后，集群将会拥有两个节点的集群——所有主分片和副本分片都已被分配。当第二个节点加入到集群后，3个副本分片将会分配到这个节点上——每个主分片对应一个副本分片。 这意味着当集群内任何一个节点出现问题时，数据都完好无损不会出现丢失问题。

同时，所有最近被索引的文档都将会保存在主分片上，然后被并行的复制到对应的副本分片上。这样就保证了我们既可以从主分片又可以从副本分片上获得文档。

5、如何对集群做水平扩容

怎么样为正在增长的业务数据按需扩容呢？ 

比如，对于一个拥有三个节点的集群，为了分散负载会对分片进行重新分配。Node 1和Node 2 上各有一个分片被迁移到了新的 Node 3 节点，现在每个节点上都拥有2个分片，而不是之前的3个。 这表示每个节点的CPU, RAM, I/O将被更少的分片所共享，每个分片的性能将会得到提升。

但是，如果我们想要扩容超过6个节点怎么办？

主分片的数目在索引创建时就已经确定了下来。实际上，这个数目定义了这个索引能够存储的最大数据量。此时，我们可以在运行中的集群上是可以动态调整副本分片数目的，按需伸缩集群。

PUT /blogs/_settings
{
   "number_of_replicas" : 2
}

这意味着我们可以将集群扩容到9个节点，每个节点上一个分片。相比原来3个节点时，集群搜索性能可以提升 3 倍。

优点：如果只是在相同节点数目的集群上增加更多的副本分片并不能提高性能，因为每个分片从节点上获得的资源会变少。 你需要增加更多的硬件资源来提升吞吐量。

不足：更多的副本分片数提高了数据冗余量：按照上面的节点配置，我们可以在失去2个节点的情况下不丢失任何数据。