elasticsearch：避免es叢集的“腦裂”現象
所謂腦裂問題（類似於精神分裂），就是同一個叢集中的不同節點，對於叢集的狀態有了不一樣的理解。
情況描述，通過以下命令檢視叢集狀態：
curl -XGET 'es-1:9200/_cluster/health'
發現，叢集的總體狀態是red，本來9個節點的叢集，在結果中只顯示了4個；但是，將請求發向不同的節點之後，卻發現即使是總體狀態是red的，但是可用的節點數量卻不一致。
es叢集由多個資料節點和一個主節點（可以有多個備選主節點）組成。其中資料節點負責資料儲存和具體操作，如執行搜尋、聚合等任務，計算壓力較大。主節點負責建立、刪除索引、分配分片、追蹤叢集中的節點狀態等工作，計算壓力較輕
正常情況下，當主節點無法工作時，會從備選主節點中選舉一個出來變成新主節點，原主節點回歸後變成備選主節點。但有時因為網路抖動等原因，主節點沒能及時響應，叢集誤以為主節點掛了，選舉了一個新主節點，此時一個es叢集中有了兩個主節點，其他節點不知道該聽誰的排程，結果將是災難性的！這種類似一個人得了精神分裂症，就被稱之為“腦裂”現象。
造成es“腦裂”的因素有以下幾個：
1、網路抖動
內網一般不會出現es叢集的腦裂問題，可以監控內網流量狀態。外網的網路出現問題的可能性大些。
2、節點負載
如果主節點同時承擔資料節點的工作，可能會因為工作負載大而導致對應的 ES 例項停止響。
3、記憶體回收
由於資料節點上es程序佔用的記憶體較大，較大規模的記憶體回收操作也能造成es程序失去響應。
避免es“腦裂”的措施主要有以下三個：
1、不要把主節點同時設為資料節點（node.master和node.data不要同時設為true）
2、將節點響應超時（discovery.zen.ping_timeout）稍稍設定長一些（預設是3秒），避免誤判。
3、設定需要超過半數的備選節點同意，才能發生主節點重選，類似需要參議院半數以上通過，才能彈劾現任總統。（discovery.zen.minimum_master_nodes = 半數以上備選主節點數）