想要了解eureka和zookeeper的区别?首先得明白几个概念；本文面向新手，有基础的可以跳着看。
数据库的概念：
RDBMS (Relational Database Management System) 关系型数据库管理系统，就是我们所说的关系型数据库 MySql,Oracle,SqlServer。
遵循ACID原则：A原子性，C一致性，I独立性，D持久性。
NoSQL 非关系型数据库，“Not Only SQL”仅是一个概念，数据之间无关系，易于扩展，大数据量，高性能，具有非常高的读写性能，灵活的数据模型，高可用。
遵循CAP原则：C强一致性，A可用性，P分区容错性。
CAP原则：
CAP定理指在一个分布式系统中，一致性Consistency，可用性Availability，分区容错性Partition tolerance这三个要素最多只能同时实现两点，不可能三者兼顾。
可用的抉择：CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。
也就是说对于非关系型数据库只能在AP一致性和CP可用性中二选一
举例,在处理双十一这种业务时,选择AP原则,保证各个节点服务器一致性服务器不能瘫痪;
划重点: Eureka和Zookeeper是CAP定理的实现,Eureka保证AP,Zookeeper保证CP;
Eureka保证AP:
Eureka在设计时就优先保证可用性 Eureka各个节点都是平等的 几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务.而Eureka的客户端在向某个Eureka注册或如果发现连接失败,则会自动切换至其他节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性);
除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
1.Eureka不再从注册列表中移除因长时间没收到心跳而应该过期的服务;
2.Eureka仍然能够接受新的服务注册和查询请求,但是不会被同步到其他节点上(即保证当前节点依然可用);
3.当网络稳定时,当前实例新的注册信息会被同步到其他节点中;
因此,Eureka能很好的应对因网络故障导致部分节点失去联系的情况,而不会像Zookeeper那样使整个注册服务瘫痪;
Zookeeper保证CP:
当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接不可用.也就是说,服务注册功能对可用性的要求要高于一致性,但是zookeeper会出现当master节点因为网络故障与其他节点失去联系时,剩余节点会重新继续leader选择.但问题在于leader选举时间太长,在30~120S直接,且选举期间整个zookeeper集群都是不可用的,这就导致在选举期间注册服务瘫痪.
在云部署的环境下,因网络问题使得zookeeper集群失去master节点是较大概率会发生的问题,虽然服务能够最终恢复,但是漫长的选举时间导致注册长期不可用是不能够容忍的.
结论:
Zookeeper的设计理念就是分布式协调服务,保证数据(配置数据,状态数据)在多个服务系统之间保证一致性,Zookeeper是属于CP特性;(zookeeper的核心算法是Zab,保证分布式系统下,数据如何在多个服务之间保证数据同步). Eureka是先保证可用性;