在生产环境进行Elasticsearch集群部署时，涉及很多的参数配置，其中又涉及Elasticsearch的底层原理。本章，我们就来聊聊生产环境中这些集群参数的含义和配置。
首先说明一点，Elasticsearch的默认参数已经经过了相当好的优化，适合绝大多数的情况，尤其是一些性能相关的配置。因此，生产环境下的ES集群，几乎所有的配置参数都可以用默认的。也许MySQL或Oracle这种关系型数据库，非常看重调优，但是Elasticsearch真的不需要。如果我们真的面临一些Elasticsearch的性能问题，通常建议的解决方案是更好的进行数学建模，或者增加更多的机器资源。
但是在生产环境中，还是有一些业务相关的配置是需要我们修改的，这些配置往往和具体的业务场景相关联，是没法预先给予最好的默认配置的。
一、名称配置
1.1 集群名称
我们首先来看下集群名称的配置，可以在elasticsearch.yml中配置Elasticsearch集群的名称：
cluster.name: your_es_name
默认情况下，Elasticsearch会启动一个名称为elasticsearch的集群，建议一定要将集群名称重新进行命名，主要是避免公司网络环境中，也许某个开发人员的开发机无意中加入你的集群。
1.2 节点名称
每个node启动的时候，Elasticsearch会分配一个随机的名称，这个不适合在生产环境中使用，因为这会导致我们没法记住每台机器，而且每次重启节点都会随机分配，就导致node名称每次重启都会变化。因此，我们在生产环境中是需要给每个node都分配一个名称的，可以在elasticsearch.yml中配置node节点的名称：
node.name: es_node_name
二、路径配置
2.1 目录
默认情况下，Elasticsearch会将plugin、log、data、config等都放在安装目录中。这有一个问题，就是在进行ES升级的时候，这些目录可能会被覆盖掉，导致我们丢失之前安装好的plugin、log、data、config等。
所以建议在生产环境中，必须将这些重要的文件路径都重新设置一下，放在ES安装目录以外的地方，可以通过配置elasticsearch.yml来改变这些目录位置：
- path.data：用于设置数据文件的目录，可以指定多个目录，用逗号分隔即可，如果多个目录在不同的磁盘上，那么这就是一个最简单的RAID 0方式；
- path.logs：用于设置日志文件的目录；
- path.plugins：用于设置插件存放的目录。
一般建议的目录地址是：
path.logs: /var/log/elasticsearch
path.data: /var/data/elasticsearch
path.plugins: /var/plugin/elasticsearch
2.2 配置文件
我们还可以自定义Elasticsearch的配置文件的目录，可以通过以下命令来重新设置：
./bin/elasticsearch -Epath.conf=/etc/elasticsearch/
三、脑裂配置
所谓脑裂问题，其实就是因为网络问题导致的网络分区，比如集群被划分成了两片，每片都有多个data node以及一个master node，那么整个集群中就出现了两个master node。但是因为master node是集群中非常重要的一个角色，主宰了集群状态的维护、shard分配，所以如果有两个master的话就会造成数据不一致。
3.1 最少master候选节点
Elasticsearch中有一个很重要的参数：discovery.zen.minimum_master_nodes。
这个参数告诉Elasticsearch：只有master候选节点的数量满足这个值时，才可以进行master选举。这个参数的值，必须设置为集群中master候选节点的quorum数量，也就是大多数（master候选节点数量 / 2 + 1）。
所以， 一个生产环境的Elasticsearch集群，至少要有3个节点，同时将这个参数设置为master候选节点数的quorum，就可以防止脑裂问题的产生 。
但是因为es集群是可以动态增加和下线节点的，所以可能随时会改变quorum。所以这个参数也是可以通过API随时修改的，特别是在节点上线和下线的时候，都需要作出对应的修改。而且一旦修改过后，这个配置就会持久化保存下来：
PUT /_cluster/settings
{
"persistent" : {
"discovery.zen.minimum_master_nodes" : 2
}
}
四、shard recovery配置
在集群启动的时候，有一些配置会影响shard恢复的过程。首先，我们需要理解在默认配置下，shard恢复的过程会发生什么事情：
首先，假设我们有10个node，每个node都有一个shard（总共5个primary shard，5个replica shard）。如果我们将集群关闭后进行一些维护性的操作，当我们重启集群的时候，此时可能会出现5个节点先启动了，然后剩下5个节点还没启动。
接着，这5个启动的节点会通过gossip协议互相通信，选举出一个master，然后组成一个集群。他们会发现数据没有被均匀的分布，因为有5个节点没有启动，那么那5个节点上的shard就是不可用的。此时在线的5个node就会将部分replica shard提升为primary shard，同时为每个primary shard复制足够的replica shard。
最后，剩下的5个节点加入了集群。但是这些节点发现本应该由他们持有的shard已经被复制了，此时他们就会删除自己本地的数据。然后集群又会开始进行shard的rebalance操作，将最早启动的5个node上的shard均匀分布到后来启动的5个node上去。
在这个过程中，shard重新复制、移动、删除、再次移动的过程，会耗费大量的网络和磁盘资源。对于数据量庞大的集群来说，可能导致每次集群重启时都有TB级别的数据移动，导致集群启动会耗费很长时间。
4.1 gateway.expected_nodes
如果可以让整个集群中的所有节点都完全上线之后，再进行复制和移动shard，那情况就会好很多。所以，Elasticsearch提供了一个gateway.recover_after_nodes参数，这个参数可以让ES等待足够的node都上线之后，再开始进行shard recovery的过程。
gateway.recover_after_nodes参数一般和gateway.recover_after_time、gateway.expected_nodes配合使用，比如进行如下设置：
gateway.recover_after_nodes: 8
gateway.recover_after_time: 5m
gateway.expected_nodes: 10
上述配置后，Elasticsearch集群的行为会变成这样：等待至少8个节点在线，然后等待最多5分钟或者10个节点都在线，才开始进行shard recovery的过程。这样就可以避免少数node启动时，就立即开始shard recovery，消耗大量的网络和磁盘资源，甚至可以将shard recovery过程从数小时缩短为数分钟（大数据量场景下）。
五、总结
本章，我主要介绍了Elasticsearch的一些通用参数配置，包括集群的名称配置、node名称配置，以及配置文件的默认路径修改。
Java 面试宝典是大明哥全力打造的 Java 精品面试题，它是一份靠谱、强大、详细、经典的 Java 后端面试宝典。它不仅仅只是一道道面试题，而是一套完整的 Java 知识体系，一套你 Java 知识点的扫盲贴。
它的内容包括：
- 大厂真题：Java 面试宝典里面的题目都是最近几年的高频的大厂面试真题。
- 原创内容：Java 面试宝典内容全部都是大明哥原创，内容全面且通俗易懂，回答部分可以直接作为面试回答内容。
- 持续更新：一次购买，永久有效。大明哥会持续更新 3+ 年，累计更新 1000+，宝典会不断迭代更新，保证最新、最全面。
- 覆盖全面：本宝典累计更新 1000+，从 Java 入门到 Java 架构的高频面试题，实现 360° 全覆盖。
- 不止面试：内容包含面试题解析、内容详解、知识扩展，它不仅仅只是一份面试题，更是一套完整的 Java 知识体系。
- 宝典详情：https://www.yuque.com/chenssy/sike-java/xvlo920axlp7sf4k
- 宝典总览：https://www.yuque.com/chenssy/sike-java/yogsehzntzgp4ly1
- 宝典进展：https://www.yuque.com/chenssy/sike-java/en9ned7loo47z5aw
目前 Java 面试宝典累计更新 400+ 道，总字数 42w+。大明哥还在持续更新中，下图是大明哥在 2024-12 月份的更新情况：
想了解详情的小伙伴，扫描下面二维码加大明哥微信【daming091】咨询
同时，大明哥也整理一套目前市面最常见的热点面试题。微信搜[大明哥聊 Java]或扫描下方二维码关注大明哥的原创公众号[大明哥聊 Java] ，回复【面试题】 即可免费领取。
