CAP理论告诉我们，一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项，如下图所示。
● 一致性：指所有节点在同一时刻的数据完全一致。
● 可用性：指服务一直可用，而且响应时间正常。例如，不管什么时候访问X节点和Y节点都可以正常获取数据值，而不会出现问题。
● 分区容错性：指在遇到某节点或网络分区故障时，仍然能够对外提供满足一致性和可用性的服务。例如X节点和Y节点出现故障，但是依然可以很好地对外提供服务。
CAP的取舍
● 满足CA舍弃P，也就是满足一致性和可用性，舍弃分区容错性。这也就意味着你的系统不是分布式的了，因为分布式就是把功能分开部署到不同的机器上。
● 满足CP舍弃A，也就是满足一致性和分区容错性，舍弃可用性。这也就意味着你的系统允许有一段时间访问失效等，不会出现数据不一致的情况。
● 满足AP舍弃C，也就是满足可用性和分区容错性，舍弃一致性。这也就意味着你的系统在并发访问的时候可能会出现数据不一致的情况。
在分布式系统中，为了避免单点故障，分区容错是不可避免的，所以对于注册中心来说只能从CP（优先保证数据一致性）、AP（优先保证数据可用性）中根据你的业务场景选择一种。
于服务注册与发现场景来说，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也不会造成灾难性的后果。对于服务的消费者来说，能消费才是最重要的，拿到可能不正确的服务实例信息可以通过重试的方法再次获取，总比因为无法获取实例信息而无法消费好。所以，对于服务发现而言，可用性比数据一致性更加重要，即AP胜过CP。Spring Cloud Netflix在设计Eureka时遵守的就是AP原则。
● Eureka：使用AP原则、无Master/Slave（主/备）节点之分，一个节点挂了，自动切换到其他节点，实现了去中心化，它优先保证了服务的可用性。Eureka使用P2P（Pear to Pear，点对点）的对等通信原则，每一个Peer都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的URL指向其他节点。每个节点都可被视为其他节点的副本。
● Consul：使用CP原则，采用分布式一致性协议实现健康检查、链值对存储。为了维护数据的一致性，通常需要选举出一个Leader（领导者）来进行协调，Consul的Raft协议要求必须过半数的节点都写入成功才认为注册成功。在Leader“挂掉”之后、重新选举出Leader之前Consul服务不可用。
● ZooKeeper：使用CP原则，它可以保证服务的一致性。搭建集群的时候，如果某个节点失效，则会进行Leader选举，或者半数以上节点不可用则无法提供服务，因此可用性没法满足。ZooKeeper使用Paxos算法保证数据的一致性。