共计 943 个字符，预计需要花费 3 分钟才能阅读完成。
CAP 实践
CAP 即：
- Consistency（一致性）
- Availability（可用性）
- Partition tolerance（分区容忍性）
这三个性质对应了分布式系统的三个指标：
而 CAP 实践说的就是：一个分布式系统，不可能同时做到这三点。如下图：
为什么 Nacos 会在单个集群中同时运行 CP 协定以及 AP 协定呢？这其实要从 Nacos 的场景出
发的：Nacos 是⼀个集服务注册发现以及配置管理于⼀体的组件，因而对于集群下，各个节点之间
的数据⼀致性保障问题，须要拆分成两个方面：
从服务注册发现来看
服务发现注册核心，在以后微服务体系下，是非常重要的组件，服务之间感知对方服务的以后可正
常提供服务的实例信息，必须从服务发现注册核心进行获取，因而对于服务注册发现核心组件的可
用性，提出了很高的要求，须要在任何场景下，尽最大可能保障服务注册发现能力能够对外提供服
务；同时 Nacos 的服务注册发现设计，采取了心跳可主动实现服务数据弥补的机制。如果数据丢
失的话，是能够通过该机制疾速补救数据失落。
因而，为了满足服务发现注册核心的可用性，强⼀致性的共识算法这里就不太适合了，因为强⼀致
性共识算法是否对外提供服务是有要求的，如果以后集群可用的节点数没有过半的话，整个算法直
接“罢工”，而最终⼀致共识算法的话，更多保障服务的可用性，并且可能保障在⼀定的工夫内各
个节点之间的数据可能达成⼀致。
上述的都是针对于 Nacos 服务发现注册中的非长久化服务而言（即须要客户端上报心跳进行服务实
例续约）。而对于 Nacos 服务发现注册中的长久化服务，因为所有的数据都是间接应用调用 Nacos
服务端间接创立，因而须要由 Nacos 保障数据在各个节点之间的强⼀致性，故而针对此类型的服务
数据，抉择了强⼀致性共识算法来保障数据的⼀致性。
从配置管理来看
配置数据，是间接在 Nacos 服务端进行创立并进行治理的，必须保障大部分的节点都保留了此配
置数据能力认为配置被胜利保留了，否则就会失落配置的变更，如果呈现这种状况，问题是很重大
的，如果是公布重要配置变更呈现了失落变更动作的状况，那多半就要引起重大的现网故障了，因
此对于配置数据的治理，是必须要求集群中大部分的节点是强⼀致的，而这里的话只能应用强⼀致
性共识算法。
参考：
1.《Nacos 架构与原理》