首先我们明白CAP理论中每个字母的单独含义：
C: Consistency(强一致性)
eg:在分布式的数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
A: Availability(可用性)
eg:在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
P: Parttition tolerance(分区容错性)
eg：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，
必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。
CAP理论关注粒度是否是数据,而不是整体系统设计的策略。
AP 原则的Eureka，Nacos
Eureka保证了可用性，实现最终一致性。
Eureka采用的是集群方式，当多台服务器相互注册就形成了高可用，这样当其中的一台停止提供服务时，剩余的则会继续提供服务。
因为Eureka在集群部署时，多个实例相互注册和发现。Eureka架构有两个角色，即Eureka Server和Eureka Client。
Eureka Client通过向Eureka Server发送心跳（每30秒一次）来续约服务。如果某个客户端不能持续续约，那么Eureka Server断定该客户端不可用，该不可用的客户端将在大约90秒后从Eureka Server服务注册列表删除。服务注册列表信息和服务续约信息都会被复制到集群中的每个Eureka Server节点。来自任何区域的Eureka Client都可以获取整个系统的服务注册列表信息。
也就是Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)，其中说明了，eureka是不满足强一致性，但还是会保证最终一致性。
CP原则的Zookeeper,Consul
这二个都保证了强一致性，但是在集群模式下不保证数据的一致性。