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

CAP理论

CAP即：

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

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

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

从服务注册发现来看

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

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

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

从配置管理来看

配置数据，是直接在 Nacos 服务端进行创建并进行管理的，必须保证大部分的节点都保存了此配
置数据才能认为配置被成功保存了，否则就会丢失配置的变更，如果出现这种情况，问题是很严重
的，如果是发布重要配置变更出现了丢失变更动作的情况，那多半就要引起严重的现网故障了，因
此对于配置数据的管理，是必须要求集群中大部分的节点是强⼀致的，而这里的话只能使用强⼀致
性共识算法。

参考：

1.《Nacos 架构与原理》