Eureka对比Zookeeper

Eureka对比Zookeeper

RDBMS(Mysql, sqlServer, Oracle) --------->ACID
NoSQL(redis, MongoDB)--------->CAP
.
ACID:
A（Atomicity）:原子性
C（Consistency）:一致性
I（Isolation）:隔离性
D（Durability）:持久性
.
CAP：
C（Consistency）:强一致性
A（Availability）:可用性
P（Partition tolerance）:分区容错性

CAP理论具有三进二原则，在分布式系统中分区容错性（P）必须满足

Eureka比Zookeeper好在哪里？

Zookeeper：保证的是CP

ZK遵循的是CP原则，即⼀致性和分区容错性，牺牲了可用性，具体牺牲在哪里呢？
         当Leader宕机以后，集群机器马上会进去到新的Leader选举中，但是选举时长在30s — 120s之间，这个选取Leader期间，是不提供服务的，不满⾜可⽤性，所以牺牲了可⽤性。

为什么选举时长会长达半分钟到2分钟呢？

当然是为了保证⼀致性，为了保证集群中各个节点数据的⼀致性，ZK做了两类数据同步，初始化同步和更新同步。
1：当新的Leader选举出来后，各个Follower需要将新的Leader的数据同步到⾃⼰的缓存中，这就是初始化同步。
2：当Leader数据被客户端修改后，其会向Follower发出⼴播，然后各个Follwer会⽵筒去同步更新的数据，这是更新同步。无论是初始化同步还是更新同步，ZK集群为了保证数据的⼀致性，若发现超过半数的Follower同步超时，则其会再次进行同步，而这个过程中ZK集群同样出去不可用状态。

Eureka：保证的是AP

Eureka看明⽩了这⼀点，因此在设计时就优先保证可⽤性。Eureka各个节点都是平等的，⼏个节点挂掉不会影响正常节点的⼯作，剩余的节点依然可以提供注册和查询服务。⽽Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会⾃动切换⾄其它节点，只要有⼀台Eureka还在，就能保证注册服务可⽤(保证可⽤性)，只不过查到的信息可能不是最新的(不保证强⼀致性)。除此之外，Eureka还有⼀种⾃我保护机制，如果在15分钟内超过85%的节点都没有正常的⼼跳，那么Eureka就认为客户端与注册中⼼出现了⽹络故障，此时会出现以下⼏种情况：

1. Eureka不再从注册列表中移除因为⻓时间没收到⼼跳⽽应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可⽤)
3. 当⽹络稳定时，当前实例新的注册信息会被同步到其它节点中。
   因此， Eureka可以很好的应对因⽹络故障导致部分节点失去联系的情况，⽽不会像zookeeper那样使整个注册服务瘫痪。