發現模塊和集群的形成
目標
發現節點Master選舉組成集群，在Master信息發生變化時及時更新。故障檢測細分為幾個子模塊
Discovery發現模塊
Discover是在集群Master節點未知時，互相發現對方的過程，例如新節點的加入或是先前的主節點宕機，如果一個節點不滿足Master資格，則它將繼續發現，直到發現了選定的主節點為止，其中，重試配置的屬性為：discovery.findpeersinterval，默認值1s。
官網上master-eligible的含義：設置了node-master：true的節點，表示有資格成為Master的節點。
一、基於單播的方式發現
可以在 elasticsearch.yml 配置文件中使用discovery.zen.ping.unicast.hosts靜態設置設置主機列表。discovery.zen.ping.unicast.hosts: ["host1", "host2"]具體的值是一個主機數組或逗號分隔的字符串。每個值應採用host：port或host的形式（其中port默認為設置transport.profiles.default.port。
二、基於配置文件的方式發現
elasticsearch可以在文件中配置種子主機列表，來進行節點發現，這種方式在容器化環境可以很好的支持動態擴展，可以隨時更改文件內容，不用重啟節點。文件配置方式為主機ip，主機ip:埠，也可以使用主機名配置，這會觸發DNS查找，每次在DNS查找中的等待時間屬性：discovery.zen.ping.unicast.resolvetimeout，默認為5S，如不指定埠，默認按順序搜索transport.profiles.default.port、transport.port。注意: 如果還配置了discovery.seedhosts，則會把兩個配置合併起來。
選舉
一、選舉Master 選舉Master需要所有的Master候選節點共同工作，即使某些節點發生了故障，這個工作也必須能夠正常進行，es需要通過仲裁的方式選取出還能正常工作的節點，再組成集群，避免形成「腦裂」，這裡「腦裂」是指，可能出現不止一個Master節點，比如節點間的通信斷開後，各個Master候選節點都有可能認為其他節點都宕機，提升自己為Master，造成集群狀態不一致的情況。由此衍生出參與選主時，需要配置能通信的候選節點數量。discovery.zen.minimummasternodes，預設配置是1.一個基本的原則是這裡需要設置成 N/2+1, N是集群中節點的數量。
由上面的分析我們可以知道，是否發生選舉，在於節點彼此間的通信感知，由此可知節點間的網絡通信同樣重要，就像是API接口調用，有調用就會有超時，所以在網絡環境差的情況下，超時配置顯得尤為重要。discovery.zen.ping.timeout用來指定兩個節點間的通信超時時間，默認是3S。根據網絡情況，調整這個參數，儘量避免由於網絡延遲，帶來的不必要的選舉。
二、改變集群狀態
投票配置
在elasticsearch7的版本中，當有一半的候選主節點宕機後，集群將不會自動恢復，在剩下的，這種極端情況下，最容易的解決辦法就是讓這些節點重新上線，在三個節點的集群中，通常能容忍一個節點的宕機。節點加入或離開集群後，Elasticsearch會通過自動對投票配置進行相應的更改來做出反應，以確保集群儘可能具有彈性。相關配置如下：
# 將節點加入投票配置排除列表中# 默認超時時間30s，可以指定超時時間POST /_cluster/voting_config_exclusions/node_name?timeout=1m集群啟動項
一、集群自舉首次啟動Elasticsearch集群需要在集群中的一個或多個Master候選節點上顯式定義初始一組主資格節點 . 這個行為稱為集群自舉。符合主機要求的初始節點集是在cluster.initialmasternodes設置中，要求如下：
節點的節點名稱。該節點的主機名，如果node.name沒有設置，因為node.name默認為節點的主機名.根據系統配置，必須使用標準主機名或裸機主機名.節點的發布地址的IP位址（如果無法使用該節點的node.name 。這是network.host解析到的IP位址，但是可以覆蓋此IP位址。節點發布地址的IP位址和埠，格式為IP:PORT ，如果不可能使用節點的node.name ，並且有多個節點共享一個IP位址注意：啟動Master候選節點時，可以在命令行上或elasticsearch.yml文件中提供此設置. 群集形成後，不再需要此設置，並且會忽略它，也就是說，這個屬性就只是在集群首次啟動時有用。並且可以不需要在非Master候選節點上設置。特別要小心的是，對於Master候選節點的配置最好採用持久化的方式來替代使用CMD命令行的方式啟動，因為如果一旦重啟Master候選節點時，指定錯誤，則有可能形成兩套不相同的集群。這有可能帶來數據丟失的。
通過cluster.name設置，可以創建彼此分離的多個群集. 節點在首次相互連接時會驗證它們是否同意其集群名稱，並且Elasticsearch將僅由具有相同集群名稱的節點組成集群. 集群名稱的默認值是elasticsearch ，但是建議更改此值以反映集群的邏輯名稱。
添加OR刪除節點
由於elasticsearch集群節點時可以動態上線下線的，那在這個過程中，我們能夠理解或需要夠操作什麼呢。在主伺服器選舉期間或加入現有的已形成集群時，節點會向主伺服器發送加入請求，以便將其正式添加到集群中. 可以使用cluster.join.timeout設置來配置節點在發送加入集群的請求後等待多長時間. 其默認值為30s。
刪除符合主機資格的節點時，重要的是不要同時刪除太多節點。例如，如果當前有七個Master候選的節點，希望將其減少到三個，則不可能簡單地一次停止四個節點：這樣做將只剩下三個節點，這少於一半投票配置，這意味著群集無法採取任何進一步的措施.只要集群中至少有三個符合主控條件的節點，通常，最好一次刪除一個節點，從而為集群留出足夠的時間來自動調整表決配置並適應故障新節點集的容差級別。這裡，我們需要注意，節點上線下線，我們都需要關注防止「腦裂」的配置，通過調用Elasticsearch APi的方式，將配置持久化下來，而不用重啟節點。
curl -uelastic:passwd -XGET "EsIP:9200/_cluster/settings"-H "Content-Type:application/json"-d '{ "persistent" : { "discovery.zen.minimum_master_nodes" : 2 }}'發布集群的狀態
只有Master節點可以更改集群狀態。更改後會將更新的狀態發布到集群中所有的節點上，每個節點都會接受這個消息，並進行Ack確認。但是不會應用這個更新。主節點需要在discovery.zen.committimeout配置的時間內獲取discovery.zen.minimummasternodes個Ack響應，才算是狀態成功的發布，否則這次發布就是失敗的，不會被應用。對於那些未收到確認的節點被稱為滯後，因為它們的群集狀態已落後於主伺服器的最新狀態. 主機等待滯後的節點再追趕一段時間，通過cluster.followerlag.timeout ，默認為90s . 如果節點在此時間內仍未成功應用集群狀態更新，則認為該節點已失敗並從集群中刪除。
Master確認Ack數量滿足後，才會繼續發送確認消息給所有節點，此時節點才會真正的應用這個集群的狀態信息，這第二個過程是通過discovery.zen.publish_timeout配置的，默認是30s，這個超時等待時長是從第二次發布時開始計算的。
由上述可以，在發布集群狀態時，獲取Master候選節點的Ack是很重要的，節點數量由discovery.zen.minimummasternodes配置。而沒有主節點時，也有相關配置需要了解，它就是：discovery.zen.nomasterblock。discovery.zen.nomasterblock設置了沒有主節點時，集群的限制操作。all。代表所有操作均不可用，包括讀寫等所有api的調用。write。這是默認值，只有寫操作會被拒絕，同時需要注意，這個屬性對Node level相關的api是無效的。
集群故障檢查
當選的主節點會定期檢查群集中的每個節點，以確保它們仍處於連接狀態並且運行狀況良好. 群集中的每個節點還定期檢查當選的主機的運行狀況. 這些檢查分別稱為 follower checks 和 leader checks。相關配置cluster.fault開頭，更改默認設置可能會導致群集變得不穩定，不建議修改。
發現和形成集群的配置
這裡列舉幾個必要重要的配置，發現模塊的其他配置，已經整理成思維導圖，【俠夢的開發筆記】公眾號回復，【發現】獲取完整圖片。
discovery.seed_hosts提供集群中符合主機要求的節點的列表. 每個值的格式為host:port或host ，其中port默認為設置transport.profiles.default.port。discovery.seed_providers以文件的方式提供主機列表，可以動態修改，而不用重啟節點（容器化環境適用）cluster.initialmasternodes設置全新群集中符合主機要求的節點的初始集合. 默認情況下，該列表為空，這意味著該節點希望加入已經被引導的集群discovery.findpeersinterval選定主節點發現時間間隔,默認1S