Nacos集群部署-高可用保证

Nacos集群部署-高可用保证

config* ：所有 config 开头的表都是 Nacos 配置中心使用时保存应用配置的表。 users：系统用户表，在集群环境下用户信息保存在 users 表中，而非在配置文件中。 roles：系统角色表，Nacos 的权限基于 RBAC（基于角色的访问控制）模型设计，此表保存角色数据。 permissions: 系统权限表，说明角色与系统使用权限的对应关系。

第四步，配置 Nacos 数据源。依次打开 3 台 Nacos 服务器中的核心配置文件 application.properties，文件路径如下：

/usr/data/nacos/conf/application.properties

定位到 36 行 Count of DB “数据源”配置附近，默认数据源配置都被#号注释，删除注释按下方示例配置数据源即可。

### 设置数据库平台为mysql spring.datasource.platform=mysql ### Count of DB: 数据库总数 db.num=1 ### Connect URL of DB: 数据库连接,根据你的实际情况调整 db.url.0=jdbc:mysql://xxx:3306/nacos_config?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC db.user=root db.password=root

cp cluster.conf.example cluster.conf

之后打开 cluster.conf，添加所有 Nacos 集群节点 IP 及端口。

ip1:8848 ip2:8848 ip3:8848

每个nacos服务器上都需要设置cluster.conf文件，Nacos 通过 cluster.conf 了解集群节点的分布情况。第六步，启动 Nacos 服务器。在 3 台 Nacos 节点上分别执行下面的启动命令。

sh /usr/local/nacos/bin/startup.sh

注意，集群模式下并不需要增加“-m”参数，默认就是以集群方式启动。启动时可以通过 tail 命令观察启动过程。

tail -f /usr/local/nacos/logs/start.out

启动日志关键内容如下：

#-Xms2g -Xmx2g 默认运行时 JVM 要求 2G 可用内存 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.275.b01-0.el7_9.x86_64/bin/java -server -Xms2g -Xmx2g ... ... #列出 Nacos 所有集群节点 INFO The server IP list of Nacos is [xxx1:8848, xxx2:8848, xxx3:8848] ... #Nacos 正在启动 INFO Nacos is starting... ... #集群模式启动成功，采用外置存储 MySQL 数据库 INFO Nacos started successfully in cluster mode. use external storage

当确保所有节点均启动成功，打开浏览器访问任意节点地址：

应用名称，默认也是在微服务中注册的微服务 ID spring.application.name=sample-service # 配置 ip1/ip2/ip3 都可以接入 Nacos spring.cloud.nacos.discovery.server-addr=ip1:8848,ip2:8848,ip3:8848 #连接 Nacos 服务器使用的用户名、密码，默认为 nacos spring.cloud.nacos.discovery.username=nacos spring.cloud.nacos.discvery.password=nacos #微服务提供 Web 服务的端口号 server.port=9000

启动微服务后，访问下面三个 URL，会发现服务列表的结果是一致的，这也证明集群模式下 Nacos 能够保证各节点的数据同步。

Nacos 集群的主体配置工作已完成，但仅会部署是远不够的，我们还需了解集群的内部运行机制。

docker部署（参考待验证）

官方参考地址：集群的工作原理

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

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

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

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

在开始介绍选举过程前，先理解任期（Term）的含义:Raft 算法将时间划分成为任意不同长度的任期（Term）。任期用连续的数字进行表示。每一个任期的开始都是一次选举（Election），一个或多个候选人会试图成为 Leader。为了便于理解，我们使用文字+表格的形式说明选举过程。1. 当最开始的时候，所有 Nacos 节点都没有启动。角色默认为 Follower（跟随者），任期都是 0。

2. 当第一个节点（ip1）启动后，节点角色会变为 Candidate（参选者），ip1 节点在每一个任期开始时便会尝试向其他节点发出投票请求，征求自己能否成为 Leader（领导者）节点。只有算上自己获得超过半数的选票，这个 Candidate 才能转正为 Leader。在当前案例，因为 ip1 发起选举投票，但 ip2/ip3 两个节点不在线，尽管 ip1 会投自己一票，但在总 3 票中未过半数，因此无法成为 Leader。因为第一次选举没有产生 Leader，过段时间在下一个任期开始时，ip1 任期自增加 1，同时会再次向其他节点发起投票请求争取其他节点同意，直到同意票过半。

3. 在 Raft 算法中，成为 Leader 的必要条件是某个 Candidate 获得过半选票，如果 ip2 节点上线，遇到 ip1 再次发起投票。ip2 投票给 ip1 节点，ip1 获得两票超过半数就会成为 Leader，ip2 节点自动成为 Follower（跟随者）。之后 ip3 节点上线，因为集群中已有 Leader，因此自动成为 Follower。

4. 当 Leader 节点宕机或停止服务，会在剩余 2 个 Nacos 节点中产生新的 Leader。如下所示ip3获得两票成为 Leader，ip2 成为 Follower，ip1已经下线但角色暂时仍为 Leader。

之后 ip1 恢复上线，但此时 Nacos 集群已有 Leader 存在，ip1 自动变为 Follower，且任期归0。

对于 Nacos 集群来说，只要 UP 状态节点不少于"1+N/2"，集群就能正常运行。但少于“1+N/2”，集群仍然可以提供基本服务，但已无法保证 Nacos 各节点数据一致性。以上就是 Nacos 基于 Raft 算法的 Leader 选举过程，确定 Leader 是维持 Nacos 集群数据一致的最重要前提，下面咱们来讲解在微服务注册时 Nacos 集群节点信息同步的过程。

Nacos 节点间的数据同步过程

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。