CAP
C（Consistency）：强一致性
A（Availability）：可用性
P（Parition tolerance）：分区容错性
这三个基本需求，最多只能同时满足其中的两项，在分布式环境下因为P是必须的，因此往往选择就在 CP 或者 AP 中。
各种组合的场景
CA - 这个比较特殊，在分布式场景下这个不可能被实现。一般在 单点 或 单点集群上来实现，满足一致性 和 可用性，通常扩展性上不太友好。
CP - 满足一致性 和 分区容错性 的系统，通常性能不是特别高。
AP - 满足可用性 和 分区容错性 的系统，通常可能对一致性要求比较低。
Nacos/Eureka 和 Zookeeper 的区别
结论：
nacos/eureka 遵循 AP 原则
zookeeper 遵循 CP 原则
zookeeper 保证 CP 原则：
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟之前的注册信息，但不能接受服务直接 down 掉不可用。也就是说，服务注册功能对可用性的要求高于一致性。
但是 zk 会出现这一种情况，当 master 节点因为网络原因与其他节点失去联系时，剩余注册功能就会重新进行 leader 选举。
问题就在于 zk 选择 leader 的时间太长，30~120s，且选举期间整个 zk 集群都是不可用的，这就导致在选举期间注册服务瘫痪。
nacos/eureka 保证 AP 原则：
nacos/eureka 看明白了这一点，因此在设计时就优先保证可用性。nacos/eureka 各个节点都是平等的，几个节点挂掉不影响其他节点的正常工作，剩余节点仍然可以提供注册和查询服务。
而如果 nacos 客户端向某个 nacos 注册 或 查询 发现链接失败时，会自动切换至其他节点，只要有一台 nacos 存在，就能保证服务的可用，只不过可能查到的信息不是最新的。
除此以外，nacos 还有一种自我保护机制，如果在 15min 之内超过 85% 的节点都没有正常的心跳，那么 nacos 就认为客户端 与 注册中心 出现了网络故障。
出现网络故障后，nacos 会做以下几件事情：
1. nacos 不会从注册列表中 移除 因为长时间没收到心跳而过期的服务
2. nacos 仍然能够接受新服务的 注册 和 查询 请求，但是不会被同步到其他节点上（保证当前节点仍然可用）
3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点上
因此，nacos 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像 zookeeper 那样导致整个注册服务瘫痪。