服务发现以及选主 ZenDiscovery

节点启动后先 ping （这里的 ping 是 Elasticsearch 的一个 RPC 命令。如果 discovery.zen.ping.unicast.hosts 有设置，则 ping 设置中的 host ，否则尝试 ping localhost 的几个端口， Elasticsearch 支持同一个主机启动多个节点） Ping 的 response 会包含该节点的基本信息以及该节点认为的 master 节点。选举开始，先从各节点认为的 master 中选，规则很简单，按照 id 的字典序排序，取第一个。如果各节点都没有认为的 master ，则从所有节点中选择，规则同上。这里有个限制条件就是 discovery.zen.minimum_master_nodes ，如果节点数达不到最小值的限制，则循环上述过程，直到节点数足够可以开始选举。最后选举结果是肯定能选举出一个 master ，如果只有一个 local 节点那就选出的是自己。如果当前节点是 master ，则开始等待节点数达到 minimum_master_nodes ，然后提供服务。如果当前节点不是 master ，则尝试加入 master 。 Elasticsearch 将以上服务发现以及选主的流程叫做 ZenDiscovery 。由于它支持任意数目的集群（ 1-N ）,所以不能像 Zookeeper/Etcd 那样限制节点必须是奇数，也就无法用投票的机制来选主，而是通过一个规则，只要所有的节点都遵循同样的规则，得到的信息都是对等的，选出来的主节点肯定是一致的。但分布式系统的问题就出在信息不对等的情况，这时候很容易出现脑裂（ Split-Brain ）的问题，大多数解决方案就是设置一个 quorum 值，要求可用节点必须大于 quorum （一般是超过半数节点），才能对外提供服务。而 Elasticsearch 中，这个 quorum 的配置就是 discovery.zen.minimum_master_nodes 。说到这里要吐槽下 Elasticsearch 的方法和变量命名，它的方法和配置中的 master 指的是 master 的候选节点，也就是说可能成为 master 的节点，并不是表示当前的 master ，我就被它的一个 isMasterNode 方法坑了，开始一直没能理解它的选举规则。