Nacos 集群中 Leader 节点是如何产生的

Nacos 集群采用 Raft 算法实现。它是一种比较简单的选举算法，用于选举出 Nacos 集群中最重要的 Leader（领导）节点。
在 Nacos 集群中，每个节点都拥有以下三种角色中的一种。

  1. Leader：领导者，集群中最重要的角色，用于向其他节点下达指令。
  2. Candidate：参选者，参与竞选 Leader 的节点。
  3. Follower：跟随者，用于接收来自 Leader 或者 Candidate 的请求并进行处理。

在集群中选举出 Leader 是最重要的工作，产生选举的时机有三个：

  1. 在 Nacos 节点启动后，还没有产生Leader时选举；
  2. 集群成员总量变更时重新选举；
  3. 当 Leader 停止服务后重新选举。

在开始介绍选举过程前，先理解任期（Term）的含义:
Raft 算法将时间划分成为任意不同长度的任期（Term）。任期用连续的数字进行表示。每一个任期的开始都是一次选举（Election），一个或多个候选人会试图成为 Leader。
为了便于理解，我们使用文字+表格的形式说明选举过程。
1. 当最开始的时候，所有 Nacos 节点都没有启动。角色默认为 Follower（跟随者），任期都是 0。
image.png
2. 当第一个节点（192.168.163.131）启动后，节点角色会变为 Candidate（参选者），131 节点在每一个任期开始时便会尝试向其他节点发出投票请求，征求自己能否成为 Leader（领导者）节点。只有算上自己获得超过半数的选票，这个 Candidate 才能转正为 Leader。在当前案例，因为 131 发起选举投票，但 132/133 两个节点不在线，尽管 131 会投自己一票，但在总 3 票中未过半数，因此无法成为 Leader。因为第一次选举没有产生 Leader，过段时间在下一个任期开始时，131 任期自增加 1，同时会再次向其他节点发起投票请求争取其他节点同意，直到同意票过半。
image.png
3. 在 Raft 算法中，成为 Leader 的必要条件是某个 Candidate 获得过半选票，如果 132 节点上线，遇到 131 再次发起投票。132 投票给 131 节点，131 获得两票超过半数就会成为 Leader，132 节点自动成为 Follower（跟随者）。之后 133 节点上线，因为集群中已有 Leader，因此自动成为 Follower。
image.png
4. 当 Leader 节点宕机或停止服务，会在剩余 2 个 Nacos 节点中产生新的 Leader。如下所示133获得两票成为 Leader，132 成为 Follower，131已经下线但角色暂时仍为 Leader。
image.png
之后 131 恢复上线，但此时 Nacos 集群已有 Leader 存在，131 自动变为 Follower，且任期归0。
image.png
对于 Nacos 集群来说，只要 UP 状态节点不少于”1+N/2”，集群就能正常运行。但少于“1+N/2”，集群仍然可以提供基本服务，但已无法保证 Nacos 各节点数据一致性。
以上就是 Nacos 基于 Raft 算法的 Leader 选举过程，确定 Leader 是维持 Nacos 集群数据一致的最重要前提，下面咱们来讲解在微服务注册时 Nacos 集群节点信息同步的过程。

Nacos 节点间的数据同步过程

image.png
Nacos 节点间的数据同步过程
在 Raft 算法中，只有 Leader 才拥有数据处理与信息分发的权利。因此当微服务启动时，假如注册中心指定为 Follower 节点，则步骤如下：
第一步，Follower 会自动将注册心跳包转给 Leader 节点；
第二步，Leader 节点完成实质的注册登记工作；
第三步，完成注册后向其他 Follower 节点发起“同步注册日志”的指令；
第四步，所有可用的 Follower 在收到指令后进行“ack应答”，通知 Leader 消息已收到；
第五步，当 Leader 接收过半数 Follower 节点的 “ack 应答”后，返回给微服务“注册成功”的响应信息。
此外，对于其他无效的 Follower 节点，Leader 仍会不断重新发送，直到所有 Follower 的状态与 Leader 保持同步。
以上便是 Nacos 节点间的数据同步主体流程，如果你对 Nacos 底层的细节感兴趣，不妨翻阅 Nacos 的源码了解更详细的过程。