nacos集群选举问题

nacos集群选举问题

Nacos支持集群模式

nacos的集群类似于zookeeper， 它分为leader角色和follower角色， 那么从这个角色的名字可以看出来，这个集群存在选举的机制。 因为如果自己不具备选举功能，角色的命名可能就是master/slave了。

选举算法

Nacos集群采用raft算法来实现，它是相对zookeeper的选举算法较为简单的一种。

选举算法的核心在 RaftCore 中，包括数据的处理和数据同步

raft算法演示地址

在Raft中，节点有三种角色：

Leader：负责接收客户端的请求

Candidate：用于选举Leader的一种角色

Follower：负责响应来自Leader或者Candidate的请求

选举分为两个情况：

服务启动的时候

leader挂了的时候

所有节点启动的时候，都是follower状态。 如果在一段时间内如果没有收到leader的心跳（可能是没有leader，也可能是leader挂了），那么follower会变成Candidate。然后发起选举，选举之前，会增加term，这个term和zookeeper中的epoch的道理是一样的。

1）follower会投自己一票，并且给其他节点发送票据vote，等到其他节点回复

2）在这个过程中，可能出现几种情况：

收到过半的票数通过，则成为leader

被告知其他节点已经成为leader，则自己切换为follower

一段时间内没有收到过半的投票，则重新发起选举

约束条件在任一term中，单个节点最多只能投一票

3）选举的几种情况

第一种情况，赢得选举之后，leader会给所有节点发送消息，避免其他节点触发新的选举

第二种情况，比如有三个节点A B C。A B同时发起选举，而A的选举消息先到达C，C给A投了一票，当B的消息到达C时，已经不能满足上面提到的第一个约束，即C不会给B投票，而A和B显然都不会给对方投票。A胜出之后，会给B,C发心跳消息，节点B发现节点A的term不低于自己的term，知道有已经有Leader了，于是转换成follower

第三种情况， 没有任何节点获得majority投票，可能是平票的情况。加入总共有四个节点（A/B/C/D），Node C、Node D同时成为了candidate，但Node A投了NodeD一票，NodeB投了Node C一票，这就出现了平票 split vote的情况。这个时候大家都在等啊等，直到超时后重新发起选举。如果出现平票的情况，那么就延长了系统不可用的时间,因此raft引入了randomizedelection timeouts来尽量避免平票情况

数据的处理

对于事务操作，请求会转发给leader

非事务操作上，可以任意一个节点来处理

RaftCore ， 在发布内容的时候，做了两个事情

如果当前的节点不是leader，则转发给leader节点处理

如果是，则向所有节点发送onPublish