Zen Discovery
zen discovery是elasticsearch默認的內置的發現模塊。它提供單播發現的方式，但是可以擴展爲雲環境或者其他形式的發現模式。zendiscovery是和其他模塊集成的，例如，所有節點間正常的單播通信都是通過transport模塊。
zendiccovery還有幾個子模塊，介紹如下：
Ping
ping是節點間互相發現的機制
unicast(單播)
單播發現需要一個主機列表充作路由列表。這些主機可以是主機名稱也可以是IP地址，在每次pinging的時候主機名稱會相應地被解析爲對應的ip地址。注意：如果您的DNS協議處在隨時變化的環境，也許需要調整您的JVM安全設置。
建議設置單播host列表爲所有的master-eligible node (master=true的節點即備選主節點)。
單播發現依賴前綴爲（elasticsearch.yml文件中的）discovery.zen.ping.unicast的配置:
| 配置 | 描述 |
|---|---|
| discovery.zen.ping.unicast.hosts | 格式爲數組或以逗號分隔的字符串，每個值的格式都應該爲host或host:port(port的默認值爲transport.profiles.default.port後的參數，如果未設置transport.profiles.default.port，則使用transport.tcp.port)，如果是ipv6的(除了用逗號分隔)主機還必須用方括號括起來，例如：127.0.0.1,[::1] |
| discovery.zen.ping.unicast.hosts.resolve_timeout | DNS解析時間，需要指定單位，默認5s |
單播發現(unicast discovery)應用transport 模塊實現發現(discovery)。
Mater Election主節點選舉
作爲ping過程的一部分，一個集羣的主節點需要是被選舉或者加入進來的(即選舉主節點也會執行ping，其他的操作也會執行ping)。這個過程是自動執行的。通過配置discovery.zen.ping_timeout來控制節點加入集羣或者選舉的響應時間(默認3s)。在這段時間內有3個ping會發出。如果超時,重新啓動ping程序。在網絡緩慢是，3秒時間可能不夠，這種情況下，可以慎重增加超時時間，增加超時時間會減慢選舉進程。一旦節點決定加入一個存在的集羣，它會發出一個加入請求給主節點，這個請求的超時時間由discovery.zen.join_time控制，默認是ping超時時間(discovery.zen.ping_timeout)的20倍。
當主節點停止或者出現問題，集羣中的節點會重新ping並選舉一個新節點。有時一個節點也許會錯誤的認爲主節點已死，所以這種ping操作也可以作爲部分網絡故障的保護性措施。這種情況下，節點可以簡單的從其他節點監聽當前活動的住節點信息。
如果discovery.zen.master_election.ignore_non_master_pings設置爲true時,node.master爲false的節點不參加主節點的選舉，同時選票也不包含這種節點。
通過設置node.master爲false,可以將節點設置爲非備選主節點，永遠沒有機會成爲主節點。
discovery.zen.minimum_master_nodes設置了最少有多少個備選主節點參加選舉，同時也設置了一個主節點需要控制最少多少個備選主節點才能繼續保持主節點身份。如果控制的備選主節點少於discovery.zen.minimum_master_nodes個，那麼當前主節點下臺，重新開始選舉。
discovery.zen.minimum_master_nodes必須設置一個恰當的備選主節點值(quonum，一般設置 爲備選主節點數/2+1),儘量避免只有兩個備選主節點，因爲兩個備選主節點quonum應該爲2，那麼如果一個節點出現問題，另一個節點的同意人數最多隻能爲1，永遠也不能選舉出新的主節點(知識鏈接：腦裂)
Fault Detectionedit故障檢測
有兩個故障檢測線程在集羣的生命週期中一直運行。一個是主節點的，ping集羣中所有的其他節點，檢查他們是否活着。另一種是每個節點都ping主節點，確認主節點是否仍在運行或者是否需要重新啓動選舉程序。
使用discovery.zen.fd前綴設置來控制故障檢測過程，配置如下
| 配置 | 描述 |
|---|---|
| ping_interval | 節點多久ping一次 默認1s |
| ping_timeout | 等待響應時間 默認30s |
| ping_retries | 失敗或超時後重試的次數 默認3 |
Cluster state updates 集羣狀態更新
主節點是唯一一個能夠更新集羣狀態的節點。一個時間段內住節點只能更新一個集羣狀態(cluster state),應用所需更改，並將更改的集羣狀態發送給其他節點，當其他節點接收到狀態時，先確認收到消息，但是不應用最新狀態。如過主節點在規定時間（discovery.zen.commit_timeout 默認30s）內沒有收到大多數節點(discovery.zen.minimum_master_nodes)的確認，集羣狀態更新不被通過。
一旦足夠的節點響應了更新的消息，新的集羣狀態(cluster state)被提交併且會發送一條消息給所有的節點。這些節點開始在內部應用新的集羣狀態.在處理更新隊列中的下一個更新之前，主節點會從發佈那一次開始等待所有的節點響應，直到超時(discovery.zen.publish_timeout默認設置爲30秒)。上述兩個超時設置都可以通過集羣更新api動態設置更改。
No master block沒有主節點時的操作
對於一個可以正常充分運作的集羣來說，必須擁有一個活着的主節點和正常數量(discovery.zen.minimum_master_nodes個)活躍的備選主節點。discovery.zen.no_master_block設置了沒有主節點時限制的操作。它又兩個可選參數
all：所有操作均不可做，讀寫、包括集羣狀態的讀寫api，例如獲得索引配置(index settings)，putMapping，和集羣狀態(cluster state)api
write：默認爲write，寫操作被拒絕執行，基於最後一次已知的正常的集羣狀態可讀，這也許會讀取到已過時的數據。
discovery.zen.no_master_block對於節點相關的基本api這個參數是無效的，如集羣屬性，節點信息，節點屬性，（cluster stats、 node info、 node stats apis）這些請求不會被拒絕。
-------------完-----------------------
後記：
還需讀源碼，看書，瀏覽打牛的博客，希望我的每一天都有進步。