

首页  思维导图  详情



nocas

2021-01-12 22:17:18   4  举报





AI智能生成

nacos

nacos集群

模版推荐

作者其他创作

大纲/内容

基础

高可用

nacos-client 重试保证高可用

nacos-client 端发起请求时，成功立即返回，失败则逐个重试，直到成功

nacos-server 端一致性协议 distro 保证高可用

临时服务

临时服务健康检查失败后会从列表中删除，常用于服务注册发现场景。

服务注册发现场景，私有协议 distro，一致性模型为AP

持久化服务

持久化服务健康检查失败后会被标记成不健康，常用于 DNS ，配置中心场景。

raft 协议,一致性模型是 CP

与zk一致，转发给leader写然后同步给follwer和observer

raft算法实现

1.每个节点启动时RaftCore会创建两个定时任务，一个是选举，一个心跳

2.同时每个服务的leaderDueMs等待的时间是随机的0-15s

3.leaderDueMs小于0时，发起选举，term轮次自增，向其他节点发送投票请求

4.其他节点term<选举发起节点的term，投发起选举的节点

5.谁先发起谁当选leader

6.选举term每次加1，而发布内容term每次加100。 100其实就是允许重新发起投票的次数，这个数字越大越安全

7.只有leader可以向其他节点发起心跳，其他节点收到心跳会重置leaderDueMs，如果长时间没有心跳，leaderDueMs<0后发起选举

角色

LEADER

FOLLOWER 同步或上报信息给leader

CANDIDATE 领导候选者

distro协议流程

Nacos 启动时首先从其他远程节点同步全部数据。

Nacos 每个节点是平等的都可以处理写入请求，同时把新数据同步到其他节点。（临时节点）

与zk不同，zk leader写然后同步给follwer和observer

每个节点只负责部分数据，定时发送自己负责数据的校验值到其他节点来保持数据一致性。

写请求

当该节点接收到属于该节点负责的服务时，直接写入

当该节点接收到不属于该节点负责的服务时，将在集群内部路由，转发给对应的节点，从而完成写入。

读请求

集群中的各个节点会同步服务状态，每个节点都会有一份最新的服务数据。都能响应读请求

当该节点宕机后，原本该节点负责的一部分服务的写入任务会转移到其他节点，从而保证 Nacos 集群整体的可用性。

网络分区，客户端会表现为有时候服务存在有时候服务不存在

nacos-client 本地缓存文件 Failover 机制 保证高可用

整个 Server 端宕机

Dubbo 内存里面是存了一份地址，依然不影响RPC调用

为了性能，因为不可能每次 RPC 调用时都读取一次注册中心，缓存机制

注册中心宕机后内存会有一份数据，这也起到了可用性的保障

Nacos 注册中心宕机，Dubbo 应用发生重启

Failover 机制，依然不影响RPC调用

nacos-client 在接收到 nacos-server 的服务推送之后，会在内存中保存一份，随后会落盘存储一份快照。 snapshot 默认的存储路径为：{USER_HOME}/nacos/naming/ 中

用来排查服务端是否正常推送了服务

当客户端加载服务时，如果无法从服务端拉取到数据，会默认从本地文件中加载。

开启该参数的方式：dubbo.registry.address=nacos://127.0.0.1:8848?namingLoadCacheAtStart=true

心跳同步服务 提升了可用性

一个心跳报文包含了全部的服务信息

nacos-server 节点全部宕机，服务数据全部丢失。nacos-server 即使恢复运作，也无法恢复出服务， 而心跳包含全部内容可以在心跳期间就恢复出服务，保证可用性。

nacos-server 出现网络分区。由于心跳可以创建服务，从而在极端网络故障下，依旧保证基础的可用性。

推+拉客户配置信息实时更新

注册中心的区别

eurka和nacos

1.eureka是需要通过maven加载依赖后，搭建server服务部署； nacos是通过下载alibaba打好的jar进行部署

2.eureka控制台粗糙，不能区分namespace； nacos有更人性化的控制

3.eureka本身没有配置中心，才有git或svn的地址配置文件； nacos有动态配置中心，类似apollo

4.高可用，eureka比较简单，在调用方配置注册中心地址； nacos需要配置虚拟ip实现高可用

5.eureka注册基于服务； nacos注册基于接口

6.eureka 客户端注册服务上报所有信息，节点多的情况下，网络，服务端压力过大，且浪费内存， 同时集群伸缩性不强，服务端集群通过广播式的复制，增加服务器压力； nacos 服务注册发现，distro协议每个服务负责部分节点，容易扩容且单个服务压力不大

7.eureka客户端更新服务信息通过简单的轮询机制，当服务数量巨大时，服务器压力过大； nacos 客户端长轮询30s超时（有更细立即返回）+ 服务端延时队列29.5s左右（变更事件通知立即返回响应）

8.Eureka2.0 闭源； nacos 阿里开源

 Collect

Get Started

Nacos 数据模型

 Collect

Get Started

nacos原理

 Collect

Get Started

nacos server注册流程

 Collect

Get Started

分布式nacos





0 条评论

下一页