什么是“腦裂”現象？
由於某些節點的失效，部分節點的網絡連接會斷開，並形成一個與原集群一樣名字的集群，這種情況稱為集群腦裂（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/