一、Elasticsearch中Master的作用
Elasticsearch的Master最重要的作用就是維護集羣狀態
集羣狀態中包括以下信息：
- 集羣層面的設置
- 集羣內有哪些節點
- 各索引的設置，映射，分析器和別名
- 索引內各分片所在的節點位置
上述的集羣狀態信息，由Master節點進行維護，並且同步到集羣中所有節點。也就是說集羣中的任何節點都存儲着集羣狀態信息，但只有Master能夠改變信息
主節點負責創建索引、刪除索引、mapping的修改，跟蹤哪些節點是集羣的一部分，並決定哪些分片分配給相關的節點、追蹤集羣中節點的狀態等，並將這些修改同步到其它節點
舉例說明下：
如果我們設置了dynamic=true,這個時候如果發現新字段，數據節點是需要跟Master通信，通知Master修改Mapping。這個時候的index寫入是阻塞的。等Master修改了集羣狀態之後，再同步到所有節點，纔可以繼續寫入
通過這種場景我們發現可以對ES進行調優：
- 對於已知的mapping，可以選擇禁用動態修改，這樣就不會導致寫入過程中，由於mapping的改變而導致性能的下降。後果就是不符合mapping規則的寫入，最終結果是寫入失敗。禁用：”dynamic”:”strict”
- 對於每天需要大批量新建索引的場景，比如日誌。我們可以選擇在業務峯值很低的時間點把index預建出來，這樣就會降低高峯時期新建索引對性能的影響。這對於field過多的bulk請求尤其重要
Elasticsearch中的Master並不像mysql、hadoop集羣的master那樣，它既不是集羣數據的唯一流入點，也不是所有元數據的存放點。所以，一般情況下Elasticsearch的Master負載是很低的
二、Elasticsearch的Master選舉機制
Elasticsearch並不依賴zookeeper，Elasticsearch自帶有一套選舉機制
什麼時候觸發選主?
- 集羣啓動
- Master 失效
選舉算法：Bully算法
比較常見的一種算法，它假定所有的節點都有一個唯一id，並對根據id進行排序。然後選舉出最大的id，作爲Master
這種方法的弊端是容易造成一種反覆選舉的情況。比如最大的id負載過大，導致假死，這個時候選舉出第二大的最爲Master。過一會第一大的id恢復了，又選最大的作爲Master，然後又假死
Elasticsearch的解決方法是通過推遲選舉直到當前Master失效之後，纔會進行新的Master選舉。但是這種做法也有個弊端，就是會產生腦裂，同時選舉多個Master出來
Elasticsearch的選主是ZenDiscovery模塊負責的，主要包含Ping（節點之間通過這個RPC來發現彼此）和Unicast（單播模塊包含一個主機列表以控制哪些節點需要ping通）這兩部分
默認情況下，有兩種方法可用於配置種子節點列表，就是需要Ping的節點列表
單播
單播發現 配置靜態主機列表， 指定爲主機名的主機在每輪 ping 操作期間解析爲 IP 地址。可以在 elasticsearch.yml 配置文件中使用discovery.zen.ping.unicast.hosts靜態設置設置主機列表
基於文件
通過外部文件提供主機列表。Elasticsearch在更改時會重新加載此文件，以便種子節點列表可以動態更改，而無需重新啓動每個節點
投票其實就是發起加入集羣的請求
選主流程：
- 首先節點會ping所有節點
- 過濾候選節點
- 判斷候選節點是否達到法定人數（Eligible Node /2 +1）
- 選舉算法就是把 node 列表根據 nodeid排序,取第一個
- 已經選出了一個 master, 但只是臨時的,準備向其投票
- 等待非主節點的連接到足夠數量(投票達到法定人數)，以完成選舉
- 投票：投票信息包含該節點的基本信息以及該節點認爲的 master 節點
- 如果一個節點收到足夠多的票數，並且該節點也爲自己投票，那麼它將扮演領導者的角色，開始發佈集羣狀態。如果等待超時後投票數沒有超過半數，則認爲選舉失敗，重新開始
- 在這期間， 如果是其他節點選爲Master
- 停止連接數的累加
- 向Master發送請求，申請加入集羣。
- 獲取集羣狀態clusterState，如果集羣狀態中與選擇的Master不一致，則重新開始
新Master獲取最新集羣狀態
新選舉出的Master並不一定具備最新的集羣狀態，它是通過gateway 模塊來實現集羣狀態的持久化和恢復
- 枚舉集羣中所有具備成爲Master 資格的節點列表（相當於找到候選節點列表）
- 通過listGatewayMetaState獲取這些節點上存儲的集羣狀態
- 通過版本號確定最新的集羣狀態並使用
三、腦裂
一個集羣分裂成兩個集羣，出現了兩個Master
- 適當調大響應時間，減少誤判
通過參數discovery.zen.ping_timeout設置節點狀態的響應時間，默認爲3s，可以適當調大，如果master在該響應時間的範圍內沒有做出響應應答，判斷該節點已經掛掉了。 - 角色分離
候選主節點和數據節點進行角色分離，這樣可以減輕主節點的負擔，防止主節點的假死狀態發生，減少對主節點“已死”的誤判 - 控制法定投票人數
設置參數discovery.zen.munimum_master_nodes
discovery.zen.minimum_master_nodes=N/2+1
如果達不到N/2+1，就是超過半數，就會選舉失敗，重新選舉
假設10臺機器組成的集羣產生網絡分區,3臺一組,7臺一組,產生分區前, Master位於3臺中的一個,此時7臺1組的節點會重新併成功選取 Master, 這種情況如何處理?
當有節點從集羣離開時, Master 節點會檢查一下當前集羣總節點數是否具備法定節點數(過半),如果不具備,他會重新加入集羣,放棄 Master 資格,因此不會產生雙主
3臺一組的集羣不能達到法定節點數，不能選舉，7臺一組則可以選舉成功