面试-服务注册中心Eureka与zookeeper比较

继续接着我上一篇说。Eureka是SpringCloud的核心组件之一。用于支持服务的注册。

一、先简单说一个Eureka:

Eureka是一个服务管理组件。是基于Rest的服务。用来定位服务。进行中间层服务器的负载均衡和故障转移。Eureka采用C-S的设计架构。也就是Eureka客户端和Eureka Service服务端。通过Eureka的客户端连接到EUreka的服务端，并维持心跳。

二、Eureka与zookeeper的比较

在分布式系统中一直都有一个理论 叫做CAP理论。这个理论指出在一个分布式系统中不可能同时满足 C（一致性）、A（可用性） 、P（分区容错性）。那么其中分布式系统又必须要保证分区容错性，那么Eureka与zookeeper在这一点上就有区别了。zookeeper保证的是CP，而Eureka保证的是AP。

1、zookeeper 保证CP

zookeeper在设计中考虑的是满足数据的一致性和分区容错性 ，举个例子 zookeeper实现服务的集群时。我们现在有一个master节点因为网络故障与其他节点失去联系时，剩余节点就会进行leader选举。但是问题leader选举需要一定的时间。并且在选举期间整个zookeeper集群时不可用的，这就导致选举期间注册服务瘫痪。例如淘宝双11。马爸爸肯定不能允许这种事件发生啊。并且在云部署的条件下。发生网络延迟或者故障的大概率的事件，虽然最终服务能够恢复但是终究不适合我们淘宝 京东 当当这种亿级平台了。

2、Eureka 保证AP

Eureka在设计上其实是充分考虑了zookeeper的一些问题，结合现实的需要优先保障服务的可用性 和分区容错性，在Eureka集群的时候，各个节点是相互平等的。没有我们说的master节点。某几个节点的宕机是不会影响其他正常节点工作的，剩余节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或者发现连接失败，则会自动切换至其他节点。只要有一台Eureka还在。就可以保证注册服务的可用。但是由于分布式CAP理论的大环境下。我们Eureka在实现上也是很难保证数据的一致性。因此有些时候查询到的信息可能不是最新的。所以Eureka在网络故障导致部分节点失去联系的情况下，只要有一个节点可用，那么注册和查询服务就可以正常使用。而不会像zookeeper那样发生整个注册服务瘫痪