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

CAP理论 CAP即：

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

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

文章图片

为什么 Nacos 会在单个集群中同时运行 CP 协议以及 AP 协议呢？这其实要从 Nacos 的场景出
发的：Nacos 是?个集服务注册发现以及配置管理于?体的组件，因此对于集群下，各个节点之间
的数据?致性保障问题，需要拆分成两个方面：
从服务注册发现来看服务发现注册中心，在当前微服务体系下，是十分重要的组件，服务之间感知对方服务的当前可正
常提供服务的实例信息，必须从服务发现注册中心进行获取，因此对于服务注册发现中心组件的可
用性，提出了很高的要求，需要在任何场景下，尽最大可能保证服务注册发现能力可以对外提供服
务；同时 Nacos 的服务注册发现设计，采取了心跳可自动完成服务数据补偿的机制。如果数据丢
失的话，是可以通过该机制快速弥补数据丢失。
因此，为了满足服务发现注册中心的可用性，强?致性的共识算法这里就不太合适了，因为强?致
性共识算法能否对外提供服务是有要求的，如果当前集群可用的节点数没有过半的话，整个算法直
接“罢工”，而最终?致共识算法的话，更多保障服务的可用性，并且能够保证在?定的时间内各
个节点之间的数据能够达成?致。
上述的都是针对于 Nacos 服务发现注册中的非持久化服务而言（即需要客户端上报心跳进行服务实
例续约）。而对于 Nacos 服务发现注册中的持久化服务，因为所有的数据都是直接使用调用 Nacos
服务端直接创建，因此需要由 Nacos 保障数据在各个节点之间的强?致性，故而针对此类型的服务
数据，选择了强?致性共识算法来保障数据的?致性。
从配置管理来看配置数据，是直接在 Nacos 服务端进行创建并进行管理的，必须保证大部分的节点都保存了此配
置数据才能认为配置被成功保存了，否则就会丢失配置的变更，如果出现这种情况，问题是很严重
的，如果是发布重要配置变更出现了丢失变更动作的情况，那多半就要引起严重的现网故障了，因
此对于配置数据的管理，是必须要求集群中大部分的节点是强?致的，而这里的话只能使用强?致
性共识算法。
参考：
【为什么 Nacos 会在单个集群中同时运行 CP 协议以及 AP 协议呢（）】1.《Nacos 架构与原理》