上篇文章我们介绍了Nacos集群的搭建方法及步骤,下面我们来看一下Nacos集群的工作原理,一共有两部分:Leader节点选举及各节点数据同步。
1、Nacos集群中Leader节点是如何产生的
Nacos集群采用了Raft算法实现。它是一种比较简单的选举算法,用于选举出Nacos集群中最重要的Leader(领导)节点。
在Nacos集群中,每个节点都有以下三种角色中的一种:
- Leader:领导者(主节点),集群中最重要的角色,用于向其他节点下达指令。(一把手,请求接收并转发给其他节点处理,对能力的要求很高)
- Candidate:参选者,参与竞选Leader的节点。(相当于岗位中的副职,等一把手GG的时候可以接替)
- Follower:跟随者,用于接收来自Leader和Candidate的请求并进行处理。(相当于干活的大头兵,负责站队和干活)
可以看出,这里的Leader选举在集群中是有很重要的地位,毕竟蛇无头不行。那在什么情况下要开始选举Leader呢?有三个时机:
1、当Nacos节点启动后,还没有产生Leader时启动选举工作。
2、集群成员总量发生变化时重新选举。
3、当Leader停止服务后重新选举。
在介绍选举过程前,先来看一下任期的含义:
Raft算法将时间划分成任意不同长度的任期(Term),任期用连续的数字表示。每个任期的开始都是一次选举,一个或多个候选人会试图成为Leader。
下面来看一下选举过程:
(1)选举过程
1、当没有节点启动时
当所有Nacos节点都没有启动时,角色默认是Follower(跟随者),任期都是0。
节点 | 角色 | 任期 | 状态 |
---|---|---|---|
192.168.3.1:8848 | Follower | 0 | DOWN |
192.168.3.2:8848 | Follower | 0 | DOWN |
192.168.3.3:8848 | Follower | 0 | DOWN |
2、当一个节点启动时
当第一个节点(192.168.3.1)启动后,节点角色会自动变为Candidate(参选者),192.168.3.1节点在每个任期开始时便会尝试向其他节点发出投票请求,征求其他节点选为 Leader(领导者)节点。只有算上自己获得超过半数的选票,这个 Candidate 才能转正为 Leader。
在当前案例,因为192.168.3.1发起选举投票,但 192.168.3.2和192.168.3.3 两个节点不在线,尽管 131 会投自己一票,但在总 3 票中未过半数,因此无法成为 Leader。因为第一次选举没有产生 Leader,过段时间在下一个任期开始时,192.168.3.1任期自增加 1,同时会再次向其他节点发起投票请求争取其他节点同意,直到同意票过半。
节点 | 角色 | 任期 | 状态 |
---|---|---|---|
192.168.3.1:8848 | Candidate | 16 | UP |
192.168.3.2:8848 | Follower | 0 | DOWN |
192.168.3.3:8848 | Follower | 0 | DOWN |
3、当三个节点启动时
在 Raft 算法中,成为 Leader 的必要条件是某个 Candidate 获得过半选票,如果 192.168.3.2节点上线,遇到192.168.3.1节点 再次发起投票。192.168.3.2 投票给 192.168.3.1 节点,192.168.3.1 获得两票超过半数就会成为 Leader,192.168.3.2 节点自动成为 Follower(跟随者)。之后 192.168.3.3 节点上线,因为集群中已有 Leader,因此自动成为 Follower。
节点 | 角色 | 任期 | 状态 |
---|---|---|---|
192.168.3.1:8848 | Leader | 13 | UP |
192.168.3.2:8848 | Follower | 13 | UP |
192.168.3.3:8848 | Follower | 0 | UP |
4、当Leader宕机时
当Leader节点无法提供服务(宕机)时,会在剩余的两个节点中产生新的Leader,现在192.168.3.1节点下线了,192.168.3.3获得了两票成为了新的Leader,192.168.3.2成为了Follower,但192.168.3.1节点已经下线但角色暂时仍为Leader。
节点 | 角色 | 任期 | 状态 |
---|---|---|---|
192.168.3.1:8848 | Leader | 13 | DOWN |
192.168.3.2:8848 | Follower | 14 | UP |
192.168.3.3:8848 | Leader | 14 | UP |
新Leader产生后,192.168.3.1节点恢复上线了,但此时Nacos集群中已经有Leader了,192.168.3.1节点则自动变为Follower,且任期归0.
节点 | 角色 | 任期 | 状态 |
---|---|---|---|
192.168.3.1:8848 | Follower | 0 | UP |
192.168.3.2:8848 | Follower | 14 | UP |
192.168.3.3:8848 | Leader | 14 | UP |
对于Nacos集群来说,只要“UP”状态节点数不少于“1+N/2”,集群就能正常运行。但少于“1+N/2”,集群仍然可以提供服务,但已无法保证Nacos各节点数据一致性。
以上就是Nacos基于Raft算法的Leader选举过程,确定Leader是维持Nacos集群数据一致的最重要前提。那下面再来看一下Nacos集群是如何通过Leader达成数据一致性的
2、Nacos节点间数据同步过程
关于Nacos节点间的数据同步过程,我们先看一下下面的图:
在Raft算法中,只有Leader才拥有数据处理和信息分发的权利。因此当服务启动时,如果注册中心指定为Follower节点,则步骤如下:
- 1、Follower 会自动将注册心跳包转给 Leader 节点;
- 2、Leader 节点完成实质的注册登记工作;
- 3、完成注册后向其他 Follower 节点发起“同步注册日志”的指令;
- 4、所有可用的 Follower 在收到指令后进行“ack应答”,通知 Leader 消息已收到;
- 5、当 Leader 接收过半数 Follower 节点的 “ack 应答”后,返回给微服务“注册成功”的响应信息。
此外,如果某个Follower节点无ack反馈,Leader也会不断重复发送,直到所有Follower节点的状态与Leader同步为止。
以上便是Nacos集群中Leader选举算法及Nacos节点间数据同步的主体流程。通过文字表述可能有些绕口,建议多看几遍,按照服务器的IP来区分会更好理解。
Nacos集群相关的内容就介绍到这里,下篇开始,我们来看一下如何高效实现服务间的消息通信。欢迎有兴趣的小伙伴继续关注。