0 集群结点的职责

• master节点：对CPU要求高，但是内存要求低
• data节点：对CPU和内存要求都高
• coordinating节点：对网络带宽、CPU要求高

1 什么是脑裂现象

在ElasticSearch集群初始化或者主节点宕机的情况下，由候选主节点中选举其中一个作为主节点。指定候选主节点的配置为：node.master:true。
当主节点负载压力过大，或者集群环境中的网络问题，导致其他节点与主节点通讯的时候，主节点没来及响应，这样的话，某些节点就认为主节点宕机，重新选择新的主节点，这样的话整个集群的工作就有问题了，比如我们集群中有10个节点，其中7个候选主节点，1个候选主节点成为了主节点，这种情况是正常的情况。但是如果现在出现了我们上面所说的主节点响应不及时，导致其他某些节点认为主节点宕机而重选主节点，那就有问题了，这剩下的6个候选主节点可能有3个候选主节点去重选主节点，最后集群中就出现了两个主节点的情况，这种情况官方成为“脑裂现象”。
集群中不同的节点对于master的选择出现了分歧，出现了多个master竞争，导致主分片和副本的识别也发生了分歧，把一些分歧中的分片标识为了坏片。

总结起来，脑裂现象就是：因主节点节点访问阻塞或者网络不可用导致出现分区，不同分区选举出不同的主节点的现象

2 造成脑裂现象的原因

2.1 网络问题（最常见）

集群间的网络延迟导致一些节点访问不到master,认为master挂掉了从而选举出新的master

2.2 主节点负载过大，资源耗尽，别的结点ping不到主节点

主节点的角色既为master又为data，访问量较大时可能会导致ES停止响应造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。

2.3 主节点JVM内存回收时间过长导致

• data节点上的ES进程占用的内存较大，引发JVM的大规模内存回收，造成ES进程失去响应。
• STW:stop the world 人垃圾回收期间，会把任务线程挂起，然后等垃圾回收结束后，在继续执行；假如STW耗时过长，也会导致主节点超时的问题。

3 脑裂现象的解决方案

3.1 局域网部署

主节点和备选主节点尽量部署在同一个局域网（同一个机房内），这样网络环境更下安全可靠，信息传输效率也高；

3.2 角色分离（单一职责原则，一个节点只做一件事）

master节点与data节点分离，限制角色；数据节点时需要承担存储和搜索的工作的，压力会很大。所以如果该节点同时作为候选主节点和数据节点，那么一旦选上它作为主节点了，这时主节点的工作压力将会非常大，出现脑裂现象的概率就增加了。

3.3 延长超时设置

置主节点的响应时间，在默认情况下，主节点3秒没有响应，其他节点就认为主节点宕机了，那我们可以把该时间设置得长一点，该配置是：discovery.zen.ping_timeout:5

3.4 提高主节点选举票数✦✦✦ 【官方默认】–>过半选举机制

• 触发discovery.zen.minimum_master_nodes:1(以前默认是1，最新版本票数过半),该属性定义的是为了形成一个集群，有主节点资格并互相连接的节点的最小数目

• 举例：一个有10节点的集群，且每个节点都有成为主节点的资格，discovery.zen.minimum_master_nodes参数设置为6。

  正常情况下，10个节点，互相连接，大于6，就可以形成一个集群。

  若某个时刻，其中有3个节点断开连接。剩下7个节点，大于6，继续运行之前的集群。而断开的3个节点，小于6，不能形成一个集群。该参数就是为了防止脑裂的产生；

  说白了，就像班级投票，每人只能投一票，如果有一半多的人投了A，则必然投票B的人小于一半，这样就避免脑裂问题了；

• 建议设置为（候选主节点数/2）+1。