CAP原则 什么是CAP原则CP模型AP模型必须三者取其二吗？行业应用实例EurekaNacosRocketMQZookeeper
什么是CAP原则
CAP原则是分布式里很重要的原则，具体如下：
C（Consistency）一致性原则: 对于一个写操作，在任何一个节点都应当可以正确的读到该数据，各个节点都需要保证数据的一致性。A (Availability) 可用性：对数据更新具备高可用性，请求能够及时处理，不会一直等待，即使出现节点失效。P (Partition tolerance) 分区容错性 : 能容忍网络分区，在网络断开的情况下，被分隔的节点仍能正常对外提供服务,简而言之，部分服务宕机不会影响整体的正确性。例如一个服务有两个副本，如果两个副本中间网络出现问题导致不能通信，那么会出现如下情况：
如果一个副本更新成功就返回成功，那么就保证了服务的可用性（A）,但是牺牲了一致性(C)，因为另一个副本没有得到更新。如果必须等到两个副本都执行了更新命令，才会返回服务结果。这样可以保证一致性(C)，但是牺牲了可用性(A)如果一个副本更新成功返回成功，但是记录本次未同步的副本，等到副本直接通讯恢复，再执行数据同步，这样保证了可用性，保证了最终一致性,但存在了副本之间一段时间内的数据不一致（很多AP模型都是采用了这种方式保证最终一致性）。著名的一致性算法 Paxos ， ZAB ，Raft 等
CP模型常见的CP模型： zookeeper(ZAB算法)
例如：数据库含有主从节点。
客户端发起更新命令主数据库发起同步数据命令，然后等待从库更新。从数据库更新完成，告知主数据库数据同步完成。主数据库得到从数据库的更新结果，然后告知客户端数据库更新完成。以上流程是一个简单的CP模型，它保证了数据的一致性。但是如果从节点这时与主节点是不能通信的，也就是说数据第二步的同步请求是无法发送的，自然也无法得到从节点的返回，这样主数据库就会返回客户端失败，丢失了可用性。
AP模型常见的AP模型:Nacos(同时支持CP模型),Eureka
例如：同样一个更新操作
以上流程中如果从数据库与主数据库不能通信，依旧可以保证数据库可用，保证了可用性,但是丢失主从数据库之间的一致性.
必须三者取其二吗？其实并不是，自古忠孝难两全，但是那是指定特殊时期，和平时期是可以保证忠孝两全的。
副本不能通信造成分区的情况很好发生，在不存在分区问题时C和A都是可以保证的。即便发生了分区问题，服务治理算法也可以做部分分区可用，故障分区停用，保证可用分区的一致性和可用性。牺牲掉部分故障分区，但是依旧能保证整体的C和A。另外一致性和可用性并不是水火不容的关系，而是在故障时更倾向于保证什么而已。 行业应用实例以下是当前主流技术栈对CAP原则的支持。一下实例可以发现，CAP原则如何选择在于它们应对的场景，CP模型和AP模型本质并没有优劣的区别。只是它们在解决不同的问题，它们的解决方案绝对它们应该去使用那种模型。
EurekaEureka使用AP模型，保证可用性作为首要条件。Eureka是服务发现中心，中心存在宕机时间，对服务提供服务有很大影响。另外Eureka客户端会对一致性做一次筛选，因此在短时间内的数据不一致是不会出现问题的。
Nacos阿里巴巴用来替代Eureka的产品，它默认使用AP模型，但是支持CP模型。其原因并不是Nacos更强大，而是它们解决的问题不同。Nacos不只是发现中心，也是配置中心(配置中心一致性是数据库保证的)，以后可能也会有更远大的设计目标，需要保证数据的强一致性。
RocketMQrocketMQ自己实现了一个服务治理服务NameServer，它采用了AP模型，原因是它只是个服务治理服务，它的实现相对简陋，应该说相当简洁，所以效率也相当的高，具体可以参考 ： RocketMq总决式-NameServer源码1
Zookeeperzookeeper采用CP模型保证数据一致性。缺点存在服务拒绝服务间隔（选举），好处数据一致性。原因是：zookeeper还提供了分布式锁的功能，数据一致性是必须的。