CAP理论被应用在何方

对于开发或设计分布式系统的架构师工程师来说，CAP是必须要掌握的理论。

（but：这个文章的重点并不是讨论CAP理论和细节，重点是说说CAP在微服务中的开发怎么起到一个指引作用，会通过几个微服务开发的例子说说明，尽量的去贴近开发）

CAP定理又被成为布鲁尔定理，是加州大学计算机科学家埃里克·布鲁尔提出来的猜想，后来被证明成为分布式计算领域公认的定理。不过布鲁尔在出来CAP的时候并没有对CAP三者（Consistency，Availability，Partition tolerance）进行详细的定义，所以在网上也出现了不少对CAP不同解读的声音。
CAP 定理
CAP定理在发展中存在过两个版本，我们以第二个版本为准

在一个分布式系统中（指互相连接并共享数据的节点集合）中，当涉及到读写操作时，只能保证一致性（Consistence）、可用性(Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。

这个版本的CAP理论在探讨分布式系统，更加强调两点是互联和共享数据，其实也是理清楚了第一个版本中三选二的一些缺陷，分布式系统不一定都存在互联和共享数据，例如memcached集群相互间就没有存在连接和共享数据，所以memcached集群这类的分布式系统并不在CAP理论讨论的范围，而想Mysql集群就是互联和数据共享复制，因此mysql集群式属于CAP理论讨论的对象。
一致性（Consistency）
一致性意思就是写操作之后进行读操作无论在哪个节点都需要返回写操作的值
可用性(Availability）
非故障的节点在合理的时间内返回合理的响应
分区容错性(Partition Tolerance)
当网络出现分区后，系统依然能够继续旅行社职责
在分布式的环境下，网络无法做到100%可靠，有可能出现故障，因此分区是一个必须的选项，如果选择了CA而放弃了P，若发生分区现象，为了保证C，系统需要禁止写入，此时就与A发生冲突，如果是为了保证A，则会出现正常的分区可以写入数据，有故障的分区不能写入数据，则与C就冲突了。因此分布式系统理论上不可能选择CA架构，而必须选择CP或AP架构。
分布式事务BASE理论
BASE理论是对CAP的延伸和补充，是对CAP中的AP方案的一个补充，即使在选择AP方案的情况下，如何更好的最终达到C。
BASE是基本可用，柔性状态，最终一致性三个短语的缩写，核心的思想是即使无法做到强一致性，但应用可以采用适合的方式达到最终一致性。
CAP在服务中实际的应用例子

理解貌似讲多了，项目的CAP可以参考下李运华的《从零开始学架构》的书，里面的21，22章比较详细的描绘了CAP的理论细节和CAP的版本演化过程。
这里着重的讲解的是神一样的CAP在我们的微服务中怎么去指导和应用起来，大概会举几个平时常见的例子

服务注册中心，是选择AP还是选择CP ？

服务注册中心解决的问题
在讨论CAP之前先明确下服务注册中心主要是解决什么问题：一个是服务注册，一个是服务发现。
服务注册：实例将自身服务信息注册到注册中心，这部分信息包括服务的主机IP和服务的Port，以及暴露服务自身状态和访问协议信息等。
服务发现：实例请求注册中心所依赖的服务信息，服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。

目前作为注册中心的一些组件大致有：dubbo的zookeeper，springcloud的eureka，consul，rocketMq的nameServer，hdfs的nameNode。目前微服务主流是dubbo和springcloud，使用最多是zookeeper和eureka，我们就来看看应该根据CAP理论应该怎么去选择注册中心。（springcloud也可以用zk，不过不是主流不讨论）。
zookeeper选择CP
zookeep保证CP，即任何时刻对zookeeper的访问请求能得到一致性的数据结果，同时系统对网络分割具备容错性，但是它不能保证每次服务的可用性。从实际情况来分析，在使用zookeeper获取服务列表时，如果zk正在选举或者zk集群中半数以上的机器不可用，那么将无法获取数据。所以说，zk不能保证服务可用性。
eureka选择AP
eureka保证AP&#x