CAP理论，我们通常只会在注册中心的偏向中去比较理解它。ACID(atomicity、consistency、isolation、durability、)呢？我们在传统数据库例如mysql、Oracle、SqlServer中才会探讨它。
其实CAP理论是针对非关系型数据库性能的一个比较维度：CAP:consistency 强一致性 availability 可用性 partition tolerance分区容错性
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性、可用性、分区容错性
分布式系统，我们一般肯定是不能舍弃P 分区容错的。所以一般常见的是CP、AP性
CP型的注册中心
当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求高于一致性。但是zk会出现这一种情况，当master节 点因为网络故障与其他节点失去联系时，剩余注册功能就会重新进行leader选举看。问题在于，选举leader的时间太长，30~ 120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部看的环境下，因网络问题使得z水集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是浸长的选举时间导致的注册长期不可用是不能容忍的。
AP型的注册中心
Eureka看明白了这点，因此在设计时就优先保证可用性。Eureka各个 节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余节点依然可以提供注册和查询服务。
而Eureka的客户端在向某个Eureka注册或者如果发现链接失败时，则会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用)，只不过查到的信息可能不是最新的(不保证一致性)。除此以外，Eureka还有种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现一下几种情况:
( 1 ) Eureka不在从注册列表中移除因为长时间没收到心跳而应该过期的服务
(2) Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上(保证当前节点依然可用)
(3)当网络稳定时，当前实例新的注册信息会被同步到其他节点中
因此，Erek可以很好的应对因网络故险导致部分节点失去联系的情况而不会像zk是整个注册服务瘫痪。
BASE是basically available soft state 、eventually consistent 三个短语的简写，该理论是对CAP中一致性和可用性权衡的结果，是由CAP演化而来的。
根据单词，大家应该能够理解其作用。我这里只写下 soft state的解释，软状态或者我们称为弱状态，指系统中的数据存在中间状态，并且该状态的存在不会影响整体的可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
这些理论的概念，大家还是需要知道的，宏观的一些东西，就像骨架，先有了一部分支撑，才后来有了肉，再后来才有了灵魂。
关于这些理论我推荐大家入门可以去看看一本书《从paxos到zookeeper分布式一致性原理与实践》这本书里面讲了很多分布式系统的问题，以及如何解决这些问题，与此同时还提炼了一些理论。