什么是“脑裂”现象？
由于某些节点的失效，部分节点的网络连接会断开，并形成一个与原集群一样名字的集群，这种情况称为集群脑裂（split-brain）现象。这个问题非常危险，因为两个新形成的集群会同时索引和修改集群的数据。
如何避免脑裂问题？
避免脑裂现象，用到的一个参数是：discovery.zen.minimum_master_nodes。这个参数决定了要选举一个Master需要多少个节点（最少候选节点数）。默认值是1。根据一般经验这个一般设置成 N/2 + 1，N是集群中节点的数量，例如一个有3个节点的集群，minimum_master_nodes 应该被设置成 3/2 + 1 = 2（向下取整）。
用到的另外一个参数是：discovery.zen.ping.timeout，等待ping响应的超时时间，默认值是3秒。如果网络缓慢或拥塞，建议略微调大这个值。这个参数不仅仅适应更高的网络延迟，也适用于在一个由于超负荷而响应缓慢的节点的情况。
如果您刚开始使用elasticsearch，建议搭建拥有3个节点的集群，这种方式可以把discovery.zen.minimum_master_nodes设置成2，这样就限制了发生脑裂现象的可能，且保持着高度的可用性：如果你设置了副本，在丢失一个节点的情况下，集群仍可运行。
真的高枕无忧了？
其实问题依然存在，ES的issue空间也在讨论一个特例情况《#2488》：即使 minimum_master_nodes 设置了一个正确的值，脑裂也有可能发生。
如何识别这个问题？
在您的集群里面尽快识别这个问题非常重要。一个比较容易的方法是定时获取每一个节点/_nodes响应，它返回了集群中所有节点的状态报告，如果两个节点返回的集群状态不一样，就是一个脑裂情况发生的警示信号。
新增解决方案
对于一个具有全功能的ES节点，必须要有一个活动的Master节点。ES1.4.0.Beta1后，新增了一项没有Master时阻塞集群操作设置：discovery.zen.no_master_block。
当集群中没有活动的Master节点后，该设置指定了哪些操作（read、write）需要被拒绝（即阻塞执行）。有两个设置值：all和write，默认为wirte。
这项配置不会对基本api（例如集群状态、节点信息和状态API）产生影响，这些节点在任何节点上执行都不会被阻塞。
总结
脑裂问题依然是一个比较难以解决的问题，最终解决方案也是妥协的结果。这个问题也是分布式系统都会面临的问题。一下子想到了前几天看到的CAP理论，难道只有CP或者AP？
总体感觉ES还很年轻，但因为它的开箱即用、天生集群、自动容错、扩展性强等优点，还是选择它来做全文检索。
参考资料
http://xingxiudong.com/2015/01/05/resolve-elasticsearch-split-brain/
