（十四）Elasticsearch集群配置

本文作者：罗海鹏，叩丁狼高级讲师。原创文章，转载请注明出处。

前言

  在我们es系列文章开篇介绍中，已经提到，elasticsearch是天生支持集群的，他不需要依赖其他的服务发现和注册的组件，如zookeeper这些，因为他内置了一个名字叫ZenDiscovery的模块，是elasticsearch自己实现的一套用于节点发现和选主等功能的组件，所以elasticsearch做起集群来非常简单，不需要太多额外的配置和安装额外的第三方组件。

数据分片

  我们在前面的篇章中介绍过elasticsearch的一些重要的基本概念了，但是为了循序渐进的学习elasticsearch，我们并没有把所有概念都一次性列出来，而是在学习的过程中不断的补充，那现在我们需要学习elasticsearch的集群了，就需要补充一个基本概念，叫做“分片（shard）”，分片在集群中起到了非常关键的作用，那接下来，我们来看看分片是什么。
分片的概念和作用
  分片是一个底层的工作单元 ，它仅保存了全部数据中的一部分，一个分片是一个 Lucene 的实例，它本身就是一个完整的搜索引擎，我们的文档被存储和索引到分片内。
  每个分片又有一个副本分片，副本分片就是主分片的copy，对于分布式搜索引擎来说, 分片及副本的分配将是高可用及快速搜索响应的设计核心.主分片与副本都能处理查询请求，它们的唯一区别在于只有主分片才能处理更新请求，这就有点像我们常见的“主从”的概念了。
  Elasticsearch 是利用分片将数据分发到集群内各处的。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。当你的集群规模扩大或者缩小时， Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。所以集群和分片关系非常密切，学习集群之前，需要了解分片的概念和作用。

ES集群节点类型

  通过前面对elasticsearch的基本概念了解到，在一个elasticsearch集群（cluster）中，有多个节点（node），并且这些节点有不同的类型：我们部署一个elasticsearch集群常用的节点类型有：主节点，数据节点，候选主节点，客户端节点。
这些节点的类型是通过在elasticsearch主配置文件path/to/config/elasticsearch.yml文件指定的，配置属性如下：

node.master: true/false #该节点有机会成为master节点
node.data: true/false #该节点可以存储数据

 &emsp通过以上两行配置的组合，我们可以指定出elasticsearch的节点类型。
每种节点的作用如下：

1、主节点：

  主节点负责创建索引、删除索引、分配分片、追踪集群中的节点状态等工作。Elasticsearch中的主节点的工作量相对较轻，用户的请求可以发往集群中任何一个节点，由该节点负责分发和返回结果，而不需要经过主节点转发。而主节点是由候选主节点通过ZenDiscovery机制选举出来的，所以要想成为主节点，首先要先成为候选主节点。

2、候选主节点

  在elasticsearch集群初始化或者主节点宕机的情况下，由候选主节点中选举其中一个作为主节点。指定候选主节点的配置为：node.master: true。
  但是在elasticsearch集群中，会有偶尔出现这样的一种现象，就是当主节点负载压力过大，或者集中环境中的网络问题，导致其他节点与主节点通讯的时候，主节点没来的及响应，这样的话，某些节点就认为主节点宕机，重新选择新的主节点，这样的话整个集群的工作就有问题了，比如我们集群中有10个节点，其中7个候选主节点，1个候选主节点成为了主节点，这种情况是正常的情况。但是如果现在出现了我们上面所说的主节点响应不及时，导致其他某些节点认为主节点宕机而重选主节点，那就有问题了，这剩下的6个候选主节点可能有3个候选主节点去重选主节点，最后集群中就出现了两个主节点的情况，这种情况官方成为“脑裂现象”。
如果避免这种问题呢？主要从以下几个方面来避免：
（1）尽量不要让候选主节点同时作为数据节点，因为数据节点是需要承担存储和搜索的工作的，压力会很大。所以如果该节点同时作为候选主节点和数据节点，那么一旦选上它作为主节点了，这时主节点的工作压力将会非常大，出现脑裂现象的概率就增加了。
（2）配置主节点的响应时间，在默认情况下，主节点3秒没有响应，其他节点就认为主节点宕机了