从CAP到zookeeper和eureka对比

今天看了一篇eureka对比zookeeper的文章，对zookeeper满足CAP中的CP，eureka满足AP产生了一点疑问，故写此篇文章进行一些探讨。

首先我们来看看CAP的定义

Consistency

　　中文叫做"一致性"。意思是，写操作之后的读操作，必须返回该值。举例来说，某条记录是 v0，用户向 G1 发起一个写操作，将其改为 v1，接下来，用户的读操作就会得到 v1。这就叫一致性。

Availability

　　中文叫做"可用性"，意思是只要收到用户的请求，服务器就必须给出回应。用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器，只要收到请求，就必须告诉用户，到底是 v0 还是 v1，否则就不满足可用性。

Partition tolerance:

　　中文叫做"分区容错"，大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。

即在一个分布式系统中，只能满足其中的两个，且在一般情况下，都是要满足分区容错性的。

eureka的AP特性

eureka既然说满足AP特性，是否说明eureka是一个不满足一致性的注册中心呢，这样一来作为一个注册中心中间件肯定是无法接受的，所以我们来细究下。

Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)，其中说明了，eureka是不满足强一致性，但还是会保证最终一致性，所以可以得出一个结论，eureka不是不满足一致性，只是在同等情况下，eureka会首先保证可用性，在一定程度内再去进行一致性的同步。

zookeeper的CP特性

同样我们来看zookeeper，zookeeper在选举leader时，会停止服务，直到选举成功之后才会再次对外提供服务，这个时候就说明了服务不可用，但是在选举成功之后，因为一主多从的结构，zookeeper在这时还是一个高可用注册中心，只是在优先保证一致性的前提下，zookeeper才会顾及到可用性。

总结

所以这里从zk的CP和eureka的AP探讨得出一个结果，CAP其实在分布式系统中，是优先保证满足其中两个特性，而不是传统意义上的单纯只满足其中两个特性而舍弃另一个特性。