Nacos 集群的工作原理
Posted JAVA每天小记
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Nacos 集群的工作原理相关的知识,希望对你有一定的参考价值。
Nacos 集群的工作原理
Nacos 集群中 Leader 节点是如何产生的?
Nacos 集群采用 Raft 算法实现。它是一种比较简单的选举算法,用于选举出 Nacos 集群中最重要的 Leader(领导)节点。
在 Nacos 集群中,每个节点都拥有以下三种角色中的一种。
Leader:领导者,集群中最重要的角色,用于向其他节点下达指令。
Candidate:参选者,参与竞选 Leader 的节点。
Follower:跟随者,用于接收来自 Leader 或者 Candidate 的请求并进行处理。
在集群中选举出 Leader 是最重要的工作,产生选举的时机有三个:
在 Nacos 节点启动后,还没有产生Leader时选举;
集群成员总量变更时重新选举;
当 Leader 停止服务后重新选举;
在开始介绍选举过程前,先理解任期(Term)的含义:
Raft 算法将时间划分成为任意不同长度的任期(Term)。任期用连续的数字进行表示。每一个任期的开始都是一次选举(Election),一个或多个候选人会试图成为 Leader。
为了便于理解,我们使用文字+表格的形式说明选举过程。
当最开始的时候,所有 Nacos 节点都没有启动。角色默认为 Follower(跟随者),任期都是 0。
当第一个节点(192.168.163.131)启动后,节点角色会变为 Candidate(参选者),131 节点在每一个任期开始时便会尝试向其他节点发出投票请求,征求自己能否成为 Leader(领导者)节点。只有算上自己获得超过半数的选票,这个 Candidate 才能转正为 Leader。在当前案例,因为 131 发起选举投票,但 132/133 两个节点不在线,尽管 131 会投自己一票,但在总 3 票中未过半数,因此无法成为 Leader。因为第一次选举没有产生 Leader,过段时间在下一个任期开始时,131 任期自增加 1,同时会再次向其他节点发起投票请求争取其他节点同意,直到同意票过半。
在 Raft 算法中,成为 Leader 的必要条件是某个 Candidate 获得过半选票,如果 132 节点上线,遇到 131 再次发起投票。132 投票给 131 节点,131 获得两票超过半数就会成为 Leader,132 节点自动成为 Follower(跟随者)。之后 133 节点上线,因为集群中已有 Leader,因此自动成为 Follower。
当 Leader 节点宕机或停止服务,会在剩余 2 个 Nacos 节点中产生新的 Leader。如下所示133获得两票成为 Leader,132 成为 Follower,131已经下线但角色暂时仍为 Leader。
之后 131 恢复上线,但此时 Nacos 集群已有 Leader 存在,131 自动变为 Follower,且任期归0。
对于 Nacos 集群来说,只要 UP 状态节点不少于"1+N/2",集群就能正常运行。但少于“1+N/2”,集群仍然可以提供基本服务,但已无法保证 Nacos 各节点数据一致性。
以上就是 Nacos 基于 Raft 算法的 Leader 选举过程,确定 Leader 是维持 Nacos 集群数据一致的最重要前提,下面咱们来讲解在微服务注册时 Nacos 集群节点信息同步的过程。
Nacos 节点间的数据同步过程
Nacos 节点间的数据同步过程
在 Raft 算法中,只有 Leader 才拥有数据处理与信息分发的权利。因此当微服务启动时,假如注册中心指定为 Follower 节点,则步骤如下:
第一步,Follower 会自动将注册心跳包转给 Leader 节点;
第二步,Leader 节点完成实质的注册登记工作;
第三步,完成注册后向其他 Follower 节点发起“同步注册日志”的指令;
第四步,所有可用的 Follower 在收到指令后进行“ack应答”,通知 Leader 消息已收到;
第五步,当 Leader 接收过半数 Follower 节点的 “ack 应答”后,返回给微服务“注册成功”的响应信息。
此外,对于其他无效的 Follower 节点,Leader 仍会不断重新发送,直到所有 Follower 的状态与 Leader 保持同步。
以上是关于Nacos 集群的工作原理的主要内容,如果未能解决你的问题,请参考以下文章