Elasticsearch：深入集群优化

为打造一个高查询和高索引吞吐量、高稳定性的 Elasticsearch 集群，相信以下几点配置优化都很重要。

1、设置Java堆大小

-Xmx和-Xms设置成同样的值，例如16G

不宜超过物理内存的一半，比如服务器是32G，Heap大小可以设置为16G，官方说了，不要设置太大超过32G，可能导致长GC。

2、索引日常维护
日常维护也是一个很重要的工作，不仅仅可以释放内存、节省磁盘空间，还可以加快检索速率

1）删除过期索引

2）关闭日常没有搜索的索引
3）不更新的索引可以进行强制合并

3、Index刷写速率配置
调整索引刷新频率，但是不能太小。太小会造成索引频繁刷新，新的数据写进去就慢了，索引速度也并不一定就快。

可以提高提吐量：

index.refresh_interval:15s

4、可以分开配置主节点和数据节点

尽可能保持高可用，设置 node.master和node.data，这样大家职责清楚，要么接受主节点（只接受请求和管理节点）和数据节点（只存储数据）

例如在： elasticsearch.yml配置数据节点

node.master: false

node.data: true

5、主节点选取的配置：防止脑裂

所谓脑裂问题（类似于精神分裂），就是同一个集群中的不同节点，对于集群的状态有了不一样的理解。集群如果6个节点，故障恢复后，有时候可能会形成2个--3节点的集群，导致不能正常工作。

可能导致的原因：

1.）网络：由于是内网通信，网络通信问题造成某些节点认为master死掉，而另选master的可能性较小；进而检查Ganglia集群监控，也没有发现异常的内网流量，故此原因可以排除。

2.）节点负载：由于master节点与data节点都是混合在一起的，所以当工作节点的负载较大（确实也较大）时，导致对应的ES实例停止响应，而这台服务器如果正充当着master节点的身份，那么一部分节点就会认为这个master节点失效了，故重新选举新的节点，这时就出现了脑裂；同时由于data节点上ES进程占用的内存较大，较大规模的内存回收操作也能造成ES进程失去响应。所以，这个原因的可能性应该是大的。

解决方法：

discovery.zen.minimum_master_nodes属性，连接节点的小数目

设置为所有可用节点个数加1的50%（如果6个节点数量， 官方的推荐值是(N/2)+1，就是4），将只会有一个4节点的集群。另外2个无法组成一个集群，只能等待重新连接会到集群。

6、配置单播和多播

使用单播时，总是设置discovery.zen.ping.multicast.enabled为false。

7、节点ping设置，更多等待时间设置

discovery.zen.fd.ping_interval：该属性默认为1s（1秒钟），指定了节点互相ping的时间间隔。

 discovery.zen.fd.ping_timeout：该属性默认为30s（30秒钟），指定了节点发送ping信息后等待响应的时间，超过此时间则认为对方节点无响应。

 discovery.zen.fd.ping_retries：该属性默认为3，指定了重试次数，超过此次数则认为对方节点已停止工作。

希望对大家有帮助，谢谢。