SpringCloud_Eureka与Zookeeper对比
关系型数据库与非关系型数据库及其特性:
RDBMS(Relational Database Management System 关系型数据库) :mysql/oracle/sqlServer等 ========》ACID特性
NOSQL(Not Only SQL 非关系型数据库):redis/mongdb等 ========》 CAP特性
ACID:A(Atomicity)原子性、C(Consistency)一致性、I(Isolation)独立性、D(Durability)持久性
CAP:C(Consistency)强一致性、A(Availability)可用性、P(Partition tolerance)分区容错性
CAP三进二原则:
在任何一个分布式系统中都无法同时满足CAP,只能三个里面选择两个
CAP介绍及其对应产品:
![](http://upload-images.jianshu.io/upload_images/7237969-1352dbb6ab2cbe61.jpg?imageMogr2/auto-orient/strip|imageView2/2/w/671/format/webp)
CA:单点集群,满足一致性,可用性的系统,通常在扩展性上不太强大(产品:RDBMS)
CP:满足一致性,分区容忍性的系统,通常性能不是特别高(产品:MongoDB/HBase/Redis)
AP:满足可用性,分区容忍性的系统,通常可能对一致性要求更低一些(产品:CouchDB/Cassandra/DvnamoDB)
CAP理论就是说在分布式系统中,最多只能实现上面两点;而由于当前的网络硬件肯定会出现延迟丢包问题,所以分区容忍必须要实现。所以分布式系统只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证CAP三点。
Zookeeper保证的是CP,Eureka保证的是AP:
Zookeeper保证CP:在集群中,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举,选举leader的时间太长,30~120秒,且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪,而在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率发生的事,虽然服务最终能够恢复,但是长时间选举时间导致的注册长期不可用是不能容忍的。
Eureka保证的是AP:Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果再15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
1、Eureka不再从注册列表中移除因为长时间没有收到心跳而应该过期的服务
2、Eureka任然能够提供服务注册和查询请求,但是占时不会将注册的服务同步到其他节点上(即保证当前节点依然可用)
3、当网络稳定时,当前实例新的注册信息才会被同步到其它节点上
结论:Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像Zookeeper那样使整个注册服务瘫痪。