Nacos和其他注册中心的比较

CAP定律

这个定理的内容是指的是在一个分布式系统中、Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性)，三者不可得兼。

一致性(C)： 在分布式系统中，如果服务器集群，每个节点在同时刻访问必须要保持数据的一致性。可用性(A)： 集群节点中，部分节点出现故障后任然可以使用 (高可用)分区容错性(P)： 在分布式系统中网络会存在脑裂的问题，部分Server与整个集群失去节点联系，无法组成一个群体。

只有在CP和AP选择一个平衡点

两种情况：

• CP情况下，虽然我们服务不能用，但是必须要保证数据的一致性
• AP情况下，可以短暂保证数据不一致，但是最终可以一致性，不管怎么样，要保证我的服务可用。
  注册中心大多数采用AP 模式

Nacos、Eureka、Zookeeper比较

相同点

都可以实现分布式服务注册中心

不同点

1.Zookeeper

Zookeeper采用CP保证数据一致性的问题，原理采用Zab原子广播协议，当我们的zk领导因为某种原因宕机的情况下，会自动触发重新选一个新的领导角色，整个选举的过程为了保证数据的一致性的问题，在选举的过程中整个zk环境是不可以使用的，可能短暂无法使用到zk，意味着微服务采用该模式的情况下可能无法实现通讯(本地有缓存除外)。ZK可以运行的节点必须满足过半机制，整个zk才可以使用。

2.Eureka

Eureka采用AP的设计理念架构注册中心，完全去中心化思想，也就是说没有主从之分。每个节点都是均等的，采用相互注册原理，你中有我我中有你，只要有最后有一个节点存在就可以保证整个微服务可以实现通讯。

中心化：必须要围绕一个领导角色为核心，选举为领导和跟随者角色
去中心化：每个角色都是均等的

3.Eureka

Nacos从1.0版本支持CP和AP混合模式集群，默认是采用AP保证服务可用性，CP的形式底层集群通过raft协议保证数据的一致性问题。如果我们采用AP模式，注册服务的实例仅支持临时注册形式，在网络分区产生抖动的情况下，仍然可以继续注册我们的服务列表。如果选择CP模式，必须保证数据的强一致性问题，如果网络分区产生抖动的情况下，是无法注册我们的服务列表，但是选择CP模式可以支持注册实例持久。

什么情况下选择AP和CP呢？
必须要求读取接口的地质保证强一致性的问题，可以采用CP模式，一般AP的情况是可以的。

如何实现切换模式？

1	$nacos_server:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP

注意： 必须是发送PUT请求！！！

我们在使用注册中心时，可以允许读取的数据短暂不一致，但是要保证注册中心能够使用，可用性优先级最高。