Eureka和Zookeeper

CAP原则

说区别之前，先回顾一下数据库的内容

数据库类型	代表性数据库	设计原则
RDBMS（关系型数据库）	mysql、Oracle、SQL server	ACID（强调事务）
NOSQL（非关系型数据库）	redis、mongdb	CAP（强调性能和扩展）

具体参见另一篇博文：
分布式数据库CAP原理与ACID,CAP+BASE

区别

Zookeeper遵循的就是CP原则
Zookeeper在master节点发生故障时，剩余节点会重新选举出Leader，但是时间会有点长，并且在此期间整个集群都是不可用的（服务注册不上）。虽然最终系统会恢复（保证一致性），但是等待时间过长这是用户所不能忍受的。
Eureka遵循的是AP原则
Eureka的每个节点都是平等的，几个节点出故障不会影响其它节点的服务注册与发现功能，只要有一个节点存活，系统就仍然可以工作（保证可用性）。
此外Eureka还具有自我保护机制。如果在15分钟内85%的服务都没有正常心跳，Eureka就会认为客户端与注册中心出了故障，就会出现一下几种情况：

1. Eureka不再从服务注册列表中移除长时间不发送心跳的服务信息，而是会保留。
2. Eureka仍然能提供服务注册与发现功能，但是不会同步到其他节点上，保证当前节点的可用性。
3. 当网络恢复正常后，当前Eureka会把新的注册信息同步到其它Eureka节点上。