原文地址：ES腦裂問題
概述：
一個正常es集羣中只有一個主節點，主節點負責管理整個集羣，集羣的所有節點都會選擇同一個節點作爲主節點所以無論訪問那個節點都可以查看集羣的狀態信息。 而腦裂問題的出現就是因爲從節點在選擇主節點上出現分歧導致一個集羣出現多個主節點從而使集羣分裂，使得集羣處於異常狀態。
原因：
1：網絡原因
內網一般不會出現此問題，可以監控內網流量狀態。外網的網絡出現問題的可能性大些。
2：節點負載
主節點即負責管理集羣又要存儲數據，當訪問量大時可能會導致es實例反應不過來而停止響應，此時其他節點在向主節點發送消息時得不到主節點的響應就會認爲主節點掛了，從而重新選擇主節點。
3：回收內存
大規模回收內存時也會導致es集羣失去響應。
所以內網負載的可能性大，外網網絡的可能性大。
再來看看ES（Elastic Search）主動選舉機制：
elasticsearch集羣一旦建立起來以後，會選舉出一個master，其他都爲slave節點。但是具體操作的時候，每個節點都提供寫和讀的操作。就是說，你不論往哪個節點中做寫操作，這個數據也會分配到集羣上的所有節點中。
這裏有某個節點掛掉的情況，如果是slave節點掛掉了，那麼首先關心，數據會不會丟呢？不會。如果你開啓了replicate，那麼這個數據一定在別的機器上是有備份的。別的節點上的備份分片會自動升格爲這份分片數據的主分片。這裏要注意的是這裏會有一小段時間的yellow狀態時間。
如果是主節點掛掉怎麼辦呢？當從節點們發現和主節點連接不上了，那麼他們會自己決定再選舉出一個節點爲主節點。但是這裏有個腦裂的問題，假設有5臺機器，3臺在一個機房，2臺在另一個機房，當兩個機房之間的聯繫斷了之後，每個機房的節點會自己聚會，推舉出一個主節點。這個時候就有兩個主節點存在了，當機房之間的聯繫恢復了之後，這個時候就會出現數據衝突了。
預防方案：
1：角色分離
在es集羣中配置2到3個主節點並且讓它們只負責管理不負責存儲，從節點只負責存儲。另外從節點禁用自動發現機制併爲其指定主節點，在elasticsearch.yml文件中。
主節點：node.master =true node.data=false
從節點：node.master =false node.data=ture
discovery.zen.ping.multicast.enabled:false
discovery.zen.ping.unicast.hosts:[“host1”, “host2:port”]
2：參數配置
discovery.zen.ping_timeout:3
此參數指定從節點訪問主節點後如果3秒之內沒有回覆則默認主節點掛了，我們可以適當的把它改大，這樣可以減少出現腦裂的概率。
discovery.zen.minimum_master_nodes:1
該參數的意思是，當具備成爲主節點的從節點的個數滿足這個數字且都認爲主節點掛了則會進行選舉產生新的主節點。
例如：es集羣有三個從節點有資格成爲主節點，這時這三個節點都認爲主節點掛了則會進行選舉，此時如果這個參數的值是4則不會進行選舉。
我們可以適當的把這個值改大，減少出現腦裂的概率，官方給出的建議是(n/2)+1,n爲有資格成爲主節點的節點數node.master=true。