CAP理论/AP架构/CP架构

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

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

Eureka 支持健康检查，自我保护等。
Zookeeper为CP设计，Eureka为AP设计。作为服务发现产品，可用性优先级较高，一致性的特点并不重要，宁可返回错误的数据，也比不返回结果要好的多。
服务列表变更Zookeeper服务端会有通知，Eureka则通过长轮询来实现。

CAP理论：

1. 一致性（Consistency）
2. 可用性（Availability）
3. 分区容错性（Partition tolerance）
   分区容忍性：分布式系统在遇到任何网络分区故障的时候，仍然能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

CAP理论提出就是针对分布式数据库环境的，所以，P这个属性是必须具备的。
P就是在分布式环境中，由于网络的问题可能导致某个节点和其他节点失去联系，这时就形成了P(partition），也就是由于网络问题，将系统的成员隔离成了2个区域，互相无法知道对方的状态，这在分布式环境下是非常常见的。

在分布式环境下，为了保证系统可用性，通常都采用了复制的方式，避免一个节点损坏，导致系统的不可用。（例如数据库的读写，通常对数据库的大部分操作都是读，所以会布置较多的读的服务器，数据库的读写是分离的。为了保证数据的一致性，写数据库经过操作，就要对每个读数据库进行同步。）当出现网络问题，导致读写节点之间的连接异常时，我们就要面临两个选择：
① 选择可用性A （availability），此时，那个失去联系的节点依然可以向系统提供服务，不过他的数据就不能保证是同步的了（失去了 C属性）。
② 选择一致性C（Consistency），为了保证数据库的一致性，我们必须等待失去联系的节点恢复过来，在这个过程中，那个节点是不允许对外提供服务的，这时候系统处于不可用状态（失去了A属性）。

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