集群发现机制

Elasticsearch采用了master-slave模式， ES会在集群中选取一个节点成为主节点，只有Master节点有资格维护全局的集群状态，在有节点加入或者退出集群的时候，它会重新分配分片，并将集群最新状态发送给集群中其它节点，主节点会以周期性ping的方式以验证其它节点是否存活。

Elasticsearch的选举算法7.x之前基于Bully选举算法，7.x之后的ES，采用-种新的选主算法Raft ；

选举时机

集群初始化
集群的Master崩溃的时候
任何一个节点发现当前集群中的Master节点没有得到n/2 + 1节点认可的时候，触发选举；

选举的基本原则

ES针对当前集群中所有的Master Eligible Node进行选举得到master节点，为了避免出现Split-brain现象，ES选择了分布式系统常见的quorum（多数派）思想，也就是只有获得了超过半数选票的节点才能成为master。在ES中使用 discovery.zen.minimum_master_nodes 属性设置quorum，这个属性一般设置为 eligibleNodesNum / 2 + 1。

选举的流程说明如下

节点node向所有比自己大的节点发送选举消息(选举为election消息)
如果节点node得不到任何回复(回复为alive消息)，那么节点node成为master，并向所有的其它节点宣布自己是master(宣布为Victory消息)
如果node得到了任何回复，node节点就一定不是master，同时等待Victory消息，如果等待Victory超时那么重新发起选举；

Bully算法

Leader选举的基本算法之一。

在bully算法中，每个节点都有一个编号，只有编号最大的存活节点才能成为master节点。

Discovery模块：负责发现集群中的节点，以及选择主节点。ES支持多种不同Discovery类型选择，内置的实现称为Zen Discovery。

Zen Discovery封装了节点发现（Ping）、选主等实现过程。

算法假定所有节点都有一个惟一的ID，该ID对节点进行排序。任何时候的当前Leader都是参与集群的最高id节点。该算法的优点是易于实现,但是,当拥有最大 id 的节点处于不稳定状态的场景下会有问题,例如 Master 负载过重而假死,集群拥有第二大id 的节点被选为新主,这时原来的 Master 恢复,再次被选为新主,然后又假死…

elasticsearch 通过推迟选举直到当前的 Master 失效来解决上述问题；但是容易产生脑裂,再通过 法定得票人数过半 解决脑裂；

在 es 中,发送投票就是发送加入集群请求.在 handleJoinRequest 过程统计投票,收到的连接被存储到 pendingJoinRequests.
在 checkPendingJoinsAndElectIfNeeded 中检查投票是否足够,其中会过滤掉没有 Master 资格节点的投票；

代码实现逻辑：

1. 筛选activeMasters列表

Ping所有节点并获取PingResponse；

过滤有成为 Master 资格的节点
创建了三个列表；
其中,joinedOnceActiveNodes.size <= activeNodes.size,差别在于是否含有 localnode, 其他的内容都一样,都是来自ping 的结果

Es的master就是从activeMasters列表或者masterCandidates列表选举出来，所以选举之前es首先需要得到这两个列表。Elasticsearch节点成员首先向集群中的所有成员发送Ping请求，elasticsearch默认等待discovery.zen.ping_timeout时间，然后elasticsearch针对获取的全部response进行过滤，筛选出其中activeMasters列表，activeMaster列表是其它节点认为的当前集群的Master节点

2.筛选masterCandidates列表

masterCandidates列表是当前集群有资格成为Master的节点，如果我们在elasticsearch.yml中配置了如下参数，那么这个节点就没有资格成为Master节点，也就不会被筛选进入masterCandidates列表；

Elasticsearch的任意一个节点都可以设置node.master和node.data属性

配置某个节点没有成为master资格 node.master:false；

3. 从activeMasters列表选举Master节点

activeMaster列表是其它节点认为的当前集群的Master节点列表，如果activeMasters列表不为空，elasticsearch会优先从activeMasters列表中选举，也就是对应着流程图中的蓝色框，选举的算法是Bully算法，笔者在前文中详细介绍了Bully算法，Bully算法会涉及到优先级比较，在activeMasters列表优先级比较的时候，如果节点有成为master的资格，那么优先级比较高，如果activeMaster列表有多个节点具有master资格，那么选择id最小的节点

代码如下

private static int compareNodes(DiscoveryNode o1, DiscoveryNode o2) {
    if (o1.isMasterNode() && !o2.isMasterNode()) {
        return -1;
    }
    if (!o1.isMasterNode() && o2.isMasterNode()) {
        return 1;
    }
    return o1.getId().compareTo(o2.getId());
}

public DiscoveryNode tieBreakActiveMasters(Collection<DiscoveryNode> activeMasters) {
    return activeMasters.stream().min(ElectMasterService::compareNodes).get(); 
}

4. 从masterCandidates列表选举Master节点

这一节对应的是红色流程图中红色部分，如果activeMaster列表为空，那么会在masterCandidates中选举，masterCandidates选举也会涉及到优先级比较，masterCandidates选举的优先级比较和masterCandidates选举的优先级比较不同。它首先会判断masterCandidates列表成员数目是否达到了最小数目discovery.zen.minimum_master_nodes。如果达到的情况下比较优先级，优先级比较的时候首先比较节点拥有的集群状态版本编号，然后再比较id，这一流程的目的是让拥有最新集群状态的节点成为master

public static int compare(MasterCandidate c1, MasterCandidate c2) {
    int ret = Long.compare(c2.clusterStateVersion, c1.clusterStateVersion);
    if (ret == 0) {
        ret = compareNodes(c1.getNode(), c2.getNode());
    }
    return ret;
}

5. 本地节点是master

经过上述选举之后，会选举出一个准master节点，准master节点会等待其它节点的投票，如果有discovery.zen.minimum_master_nodes-1个节点投票认为当前节点是master，那么选举就成功，准master会等待discovery.zen.master_election.wait_for_joins_timeout时间，如果超时，那么就失败。在代码实现上准master通过注册一个回调来实现，同时借助了AtomicReference和CountDownLatch等并发构建实现

if (clusterService.localNode().equals(masterNode)) {
    final int requiredJoins = Math.max(0, electMaster.minimumMasterNodes() - 1); 
    nodeJoinController.waitToBeElectedAsMaster(requiredJoins, masterElectionWaitForJoinsTimeout,
            new NodeJoinController.ElectionCallback() {
                @Override
                public void onElectedAsMaster(ClusterState state) {
                    joinThreadControl.markThreadAsDone(currentThread);
                    nodesFD.updateNodesAndPing(state); // start the nodes FD
                }
                @Override
                public void onFailure(Throwable t) {
                    logger.trace("failed while waiting for nodes to join, rejoining", t);
                    joinThreadControl.markThreadAsDoneAndStartNew(currentThread);
                }
            }
    );

本地节点是Master的时候，Master节点会开启错误检测(NodeFaultDetection机制)，它节点会定期扫描集群所有的成员，将失活的成员移除集群，同时将最新的集群状态发布到集群中，集群成员收到最新的集群状态后会进行相应的调整，比如重新选择主分片，进行数据复制等操作

6. 本地节点不是master

当前节点判定在集群当前状态下如果自己不可能是master节点，首先会禁止其他节点加入自己，然后投票选举出准Master节点。同时监听master发布的集群状态(MasterFaultDetection机制)，如果集群状态显示的master节点和当前节点认为的master节点不是同一个节点，那么当前节点就重新发起选举。

非Master节点也会监听Master节点进行错误检测，如果成员节点发现master连接不上，重新加入新的Master节点，如果发现当前集群中有很多节点都连不上master节点，那么会重新发起选举。

Raft算法选主流程

Raft作为一种分布式一致性协议，其本身不止描述了选举过程，还提供了日志同步与安全性的相关行为的描述；

其设计原则如下：

容易理解
减少状态的数量，尽可能消除不确定性

在Raft中，节点可能的状态有三种，其转换关系如下：

正常情况下，集群中只有一个Leader，其他节点全是Follower。Follower 都是被动接收请求，从不主动发送任何请求。Candidate - 候选人，候补者；应试者是从Follower到Leader的中间状态。

Raft中引入任期(term) 的概念，每个term内最多只有一个Leader。term 在Raft算法中充当逻辑时钟的作用。服务器之间通信的时候会携带这个term，如果节点发现消息中的term小于自己的term，则拒绝这个消息；如果大于本节点的term，则更新自己的term。如果一个Candidate或者Leader发现自己的任期过期了，它会立即回到Follower状态。

Raft选举流程为：

增加当前节点本地的current term，切换到Candidate状态；
当前节点投自己一票，并且并行给其他节点发送RequestVote RPC (让大家投他) ；

然后等待其他节点的响应，会有如下三种结果：

如果接收到大多数服务器的选票，那么就变成Leader。成为Leader后，向其他节点发送心跳消息来确定自己的地位并阻止新的选举。
如果收到了别人的投票请求，且别人的term比自己的大，那么候选者退化为Follower；
如果选举过程超时，再次发起一轮选举；

ES实现Raft算法选主流程

ES实现中，候选人不先投自己，而是直接并行发起RequestVote，这相当于候选人有投票给其他候选人的机会。这样的好处是可以在一定程度上避免3个节点同时成为候选人时，都投自己，无法成功选主的情况。

ES不限制每个节点在某个term上只能投一票，节点可以投多票，这样会产生选出多个主的情况：

Node2被选为主，收到的投票为：Node2、 Node3；
Node3被选为主，收到的投票为：Node3、 Node1；

对于这种情况，ES的处理是让最后当选的Leader成功，作为Leader。如果收到RequestVote请求，他会无条件退出Leader状态。在本例中，Node2先被选为主，随后他收到Node3的RequestVote请求，那么他退出Leader状态，切换为CANDIDATE，并同意向发起RequestVote候选人投票。因此最终Node3成功当选为Leader。

动态维护参选节点列表

在此之前，我们讨论的前提是在集群节点数量不变的情况下，现在考虑下集群扩容、缩容、节点临时或永久离线时是如何处理的。在7.x之前的版本中，用户需要手工配置minimum_master_nodes, 来明确告诉集群过半节点数应该是多少，并在集群扩缩容时调整他。现在，集群可以自行维护。

在取消了discovery.zen.minimum_master_nodes 配置后，现在的做法不再记录“quorum”法定数量的具体数值，取而代之的是记录一个节点列表，这个列表中保存所有具备master资格的节点(有些情况下不是这样，例如集群原本只有1个节点，当增加到2个的时候，这个列表维持不变，因为如果变成2，当集群任意节点离线，都会导致无法选主。这时如果再增加一个节点，集群变成3个，这个列表中就会更新为3个节点)，称为VotingConfiguration，他会持久化到集群状态中。

在节点加入或离开集群之后，Elasticsearch 会自动对VotingConfiguration 做出相应的更改，以确保集群具有尽可能高的弹性。在从集群中删除更多节点之前，等待这个调整完成是很重要的。你不能一次性停止半数或更多的节点。(感觉大面积缩容时候这个操作就比较感人了，一部分一部分缩)。默认情况下，ES自动维护VotingConfiguration。有新节点加入的时候比较好办，但是当有节点离开的时候，他可能是暂时的重启，也可能是永久下线。你也可以人工维护VotingConfiguration，配置项为：cluster.auto_shrink_voting_configuration，当你选择人工维护时，有节点永久下线，需要通过voting exclusions API将节点排除出去。如果使用默认的自动维护VotingConfiguration，也可以使用voting exclusions API来排除节点，例如一次性下线半数以上的节点。

如果在维护VotingConfiguration时发现节点数量为偶数，ES会将其中一个排除在外，保证VotingConfiguration是奇数。因为当是偶数的情况下，网络分区将集群划分为大小相等的两部分，那么两个子集群都无法达到“多数”的条件。

更新中。。。