CAP理论/AP架构/CP架构

 

 

原文地址：https://blog.csdn.net/u013058742/article/details/83541905 

简书里的文章：Spring Cloud Eureka简介及与Zookeeper对比，明显的区别可能就是Zookeeper为CP设计，而Eureka为AP设计，可是对CAP/AP/CP很不理解，因而查阅资料，作一个简单的了解。

Eureka服务治理机制与Dubbo服务治理机制的比较

Feature	Eureka	Zookeeper
服务健康检查	可配支持	(弱)长链接，keepalive
CAP	AP	CP
watch支持（客户端观察到服务提供者变化）	支持 long polling/大部分增量	支持
自我保护	支持	-
客户端缓存	支持	-
自身集群的监控	metrics	-

Eureka支持健康检查，自我保护等

Zookeeper为CP设计，Eureka为AP设计。做为服务发现产品，可用性优先级较高，一致性的特色并不重要，宁肯返回错误的数据，也比不反回结果要好得多。

服务列表变动Zookeeper服务端会有通知，Eureka则经过长轮询来实现，Eureka将来会实现watch机制

CAP理论提出就是针对分布式数据库环境的，因此，P这个属性是必须具有的。
P就是在分布式环境中，因为网络的问题可能致使某个节点和其它节点失去联系，这时候就造成了P(partition)，也就是因为网络问题，将系统的成员隔离成了2个区域，互相没法知道对方的状态，这在分布式环境下是很是常见的。
由于P是必须的，那么咱们须要选择的就是A和C。
你们知道，在分布式环境下，为了保证系统可用性，一般都采起了复制的方式，避免一个节点损坏，致使系统不可用。那么就出现了每一个节点上的数据出现了不少个副本的状况，而数据从一个节点复制到另外的节点时须要时间和要求网络畅通的，因此，当P发生时，也就是没法向某个节点复制数据时，这时候你有两个选择：
选择可用性 A(Availability)，此时，那个失去联系的节点依然能够向系统提供服务，不过它的数据就不能保证是同步的了（失去了C属性）。
选择一致性C(Consistency)，为了保证数据库的一致性，咱们必须等待失去联系的节点恢复过来，在这个过程当中，那个节点是不容许对外提供服务的，这时候系统处于不可用状态(失去了A属性)。

最多见的例子是读写分离，某个节点负责写入数据，而后将数据同步到其它节点，其它节点提供读取的服务，当两个节点出现通讯问题时，你就面临着选择A（继续提供服务，可是数据不保证准确），C（用户处于等待状态，一直等到数据同步完成）。