为什么 Nacos 会在单个集群中同时运行 CP 协议以及 AP 协议呢？

最新推荐文章于 2025-06-08 12:33:06 发布

原创

最新推荐文章于 2025-06-08 12:33:06 发布 · 884 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#Java #架构 #nacos

Nacos作为一个服务注册发现和配置管理组件，遵循CAP理论。在服务发现场景中，为了保证高可用性，采用最终一致性算法。而对于持久化服务和配置管理，由于需要强一致性，所以采用强一致性共识算法。这样既确保了服务注册的可用性，又保证了关键配置数据的一致性。

CAP理论

CAP即：

Consistency（一致性）
Availability（可用性）
Partition tolerance（分区容忍性）

这三个性质对应了分布式系统的三个指标：而CAP理论说的就是：一个分布式系统，不可能同时做到这三点。如下图：

file

为什么 Nacos 会在单个集群中同时运行 CP 协议以及 AP 协议呢？这其实要从 Nacos 的场景出发的：Nacos 是⼀个集服务注册发现以及配置管理于⼀体的组件，因此对于集群下，各个节点之间的数据⼀致性保障问题，需要拆分成两个方面：

从服务注册发现来看

服务发现注册中心，在当前微服务体系下，是十分重要的组件，服务之间感知对方服务的当前可正常提供服务的实例信息，必须从服务发现注册中心进行获取，因此对于服务注册发现中心组件的可用性，提出了很高的要求，需要在任何场景下，尽最大可能保证服务注册发现能力可以对外提供服务；同时 Nacos 的服务注册发现设计，采取了心跳可自动完成服务数据补偿的机制。如果数据丢失的话，是可以通过该机制快速弥补数据丢失。

因此，为了满足服务发现注册中心的可用性，强⼀致性的共识算法这里就不太合适了，因为强⼀致性共识算法能否对外提供服务是有要求的，如果当前集群可用的节点数没有过半的话，整个算法直接“罢工”，而最终⼀致共识算法的话，更多保障服务的可用性，并且能够保证在⼀定的时间内各个节点之间的数据能够达成⼀致。

上述的都是针对于 Nacos 服务发现注册中的非持久化服务而言（即需要客户端上报心跳进行服务实例续约）。而对于 Nacos 服务发现注册中的持久化服务，因为所有的数据都是直接使用调用 Nacos 服务端直接创建，因此需要由 Nacos 保障数据在各个节点之间的强⼀致性，故而针对此类型的服务数据，