Nacos2.3.2中的CAP定理

CAP定理

一致性（Consistency）。所有节点访问的都是最新和相同的数据。当一个节点进行写操作后，其他节点在执行读操作时应该能够读取到最新的数据。
可用性（Availability）。系统能够在任何时候处理请求并给出响应。即使系统中的某些节点发生故障或延迟，系统仍需保证请求能够得到响应。需要注意的是，这里的“最新数据”可能不是最准确的，因为系统需要权衡响应时间和数据一致性。
分区容忍性（Partition Tolerance）。指的是系统能够在网络分区的情况下继续运行并提供服务。网络分区意味着系统中的某些节点或整个部分与系统断开连接，这时系统仍需保持运行状态并对外提供服务。

Nacos 服务注册

Nacos 的服务注册发现设计，采取了心跳可自动完成服务数据补偿的机制。如果数据丢失的话，是可以通过该机制快速弥补数据丢失。

配置管理

对于配置数据的管理，是必须要求集群中大部分的节点是强一致的，而这里的话只能使用强一致性共识算法。

共识算法（Raft 和 Distro）

Raft（CP)是基于日志复制的强一致性算法
Raft 使用一种心跳机制来触发 Leader 的选举。当服务器启动时，它们会初始化为 Follower。一台服务器会一直保持 Follower 的状态，只要它们能够收到来自 Leader 或者 Candidate 的有效 RPC。Leader 会向所有 Follower 周期性发送心跳（不带有任何日志条目的 AppendEntries RPC）来保证它们的 Leader 地位。如果一个 Follower 在一个周期内没有收到心跳信息，就叫做选举超时，然后它就会认为没有可用的 Leader，并且开始一次选举以选出一个新的 Leader。

Distro (AP)算法每个节点负责一部分数据以及将自己的数据同步给其他节点，有效的降低了消息冗余的问题。
nacos启动首先从其他远程节点同步全部数据
nacos每个节点是平等的都可以处理写入请求，同时把新数据同步到其他节点
每个节点只负责部分数据，定时发送自己负责数据校验值到其他节点来保持数据一致性

nacos推拉模型

在Nacos2.0版本之前，Nacos主要采用长轮询的方式在客户端拉取服务端的配置信息。
而在Nacos2.0版本中，引入了基于gRPC的长连接模型来提升配置监听的性能，客户端和服务端会建立长连接来监听配置的变更，一旦服务端有配置变更，就会将配置信息推送到客户端中。

https://nacos.io/docs/ebook/agxdnq.mdx/
https://www.51cto.com/article/679454.html