Eureka和Zookeeper的区别总结

1、CAP原则

在分布式领域中，有一个CAP原则（数据库系统中也有一个ACID原则）

C（Consistency）：数据一致性

A（Availability）：可用性

P（Partition tolerance）：分区容错性

CAP原则的特点就是，这三种特点只能同时满足两个，三者不可兼得。同时，而由于网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。也就是说我们只能选择CP或者AP。

2、Zookeeper保证CP

zookeeper选择优先保证一致性。zookeeper保证访问请求都能保持一致的结果，同时具有容错性，但是不保证每次访问请求都是可用的。为什么不保证对请求可用呢？当zookeeper的master节点如果因为网络故障导致与其它节点失去联系时，剩余的节点会进行选举产生新的master节点，但是在这过程需要一定的时间，并且在选举这段时间内，整个zookeeper集群是不可用的。并且由于网络问题，这种情况发生的概率是比较大的。

3、Eureka保证AP

Eureka选择优先保证可用性。Eureka的节点之间是平等的。如果某个节点服务器宕机了，Eureka不会像zookeeper那样进行停止服务进行选举，而是让请求自动切换到另外的可用Eureka节点上，等到宕机的节点恢复后，再将其纳入集群中，只是不保证查询到的信息可能不是最新的。同时，如果15分钟内超过85%的节点都没有心跳，那么Eureka就认为客户端和注册中心出现了网络故障，就执行一下策略：

1. Eureka不在从注册列表中移除因为长时间没收到心跳而应该过期的服务

2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上 (即保证当前节点依然可用)

3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点中

3、总结

说白了，就说再CAP原则中，zookeeper优先选择了一致性（CP），Eureka优先选择了可用性（AP）。当出现请求高峰时，我们应该选择可用性优先（因为zookeeper一旦出现一个节点宕机，服务就不可用了，高峰时出现这种情况貌似挺正常的），至于一致性，是闲暇时再考虑的事情。