2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后，CAP理论正式成为分布式计算领域的公认定理。
CAP认为：一个分布式系统最多同时满足一致性(Consistency，强一致性)，可用性(Availability)和分区容忍性(Partition Tolerance)这三项中的两项。在分布式系统中，分区容错性是必不可少的，所以需要取舍的是一致性和可用性
服务注册中心案例分析：
- Eureka：AP
- zookeeper：CP
服务注册中心的作用
微服务系统中，我们有很多服务，不同的服务的功能是不相同的，客户端访问的时候，怎么快速的找到想要访问的服务器？如何能够方便高效的管理目前系统中有哪些服务，服务的运行状态如何？服务注册中心就是干这些事情的。
换句话说，客户端想要访问服务，首先要经过服务注册中心，那么客户端的调用是否成功，除了保证我们底层的服务正常运行之外，服务注册中心的可用性是必须要保证的。不能出现这样的情况，我后台的服务是可用的，但是服务注册中心不可用了，导致我访问不到正常的服务了。
为什么AP更适合服务注册中心
Eureka作为专业的服务注册中心，选择保证AP，zookeeper作为分布式一致性中间件，虽然也能够作为服务注册中心，但是更多的是保证数据一致性，选择的的是CP。
eureka优先保证可用性。在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程；客户端请求会自动切换到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广的网络分割故障，并实现“0”宕机维护需求。当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务（注：ZooKeeper不会）：接收新的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中（same side of partition），新发布的服务仍然可以被发现与访问。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
- Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
- Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
- 当网络稳定时，当前实例新的注册信息会被同步到其它节点中
Eureka还有客户端缓存功能（注：Eureka分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接口）。所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器；Eureka服务的消费者仍然可以通过Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解决这种问题时；得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息。
BASE理论
eBay架构师Dan Pritchett基于对大规模分布式系统的实践总结，在ACM上发表文章提出了BASE理论，BASE理论是对于CAP理论的延伸，核心思想是即使无法做到强一致性(Strong Consistency，CAP中的一致性指强一致性)，但是可以采用适当的方式达到最终一致性(Eventual Consistency)。
BASE指基本可用(Basically Available)、软状态(Soft State)和最终一致性(Eventual Consistency)。
1. 基本可用(Basically Available)
基本可用是指分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。比如服务降级。
2. 软状态(Soft State)
软状态是指允许系统存在中间状态，而该中间状态不会影响系统的整体可用性。分布式存储中一般一份数据至少存三个副本，允许不同节点间副本同步的延迟就是软状态的体现。
3. 最终一致性(Eventual Consistency)
最终一致性是指系统中的所有数据副本经过一段时间后，最终能够达成一致状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。