Zookeeper与Eureka区别

Zookeeper与Eureka区别【待完善】

CAP原则

• C（Consistency） 强一致性

• A（Availablility） 可用性

• P（Partition tolerance） 分区容错性

CAP的三进二，不可能同时满足三个原则

ACID原则

• A（Atomicity） 原子性
• C（Consistency） 一致性
• I（Isolation） 隔离性
• D（Durability） 持久性

RDBMS（Mysq，Oracle，sqlServer） ===> ACID

NoSql（redis，mongdb） ===> CAP

CAP理论核心

• 在一个分布式系统中，不可能同时很好的满足一致性，可用性和分区容错性这三个需求

• 根据CAP理论，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类

  ​ CA：单点集群。满足一致性和可用性的系统，通常可拓展性较差

  ​ CP：满足一致性，分区容错性的系统，通常性能不是特别高

  ​ AP：满足可用性，分区容错性的系统，通常可能对一致性要求低一些

作为服务注册中心Eureka比Zookeeper好在哪里

CAP理论指出，一个分布式不可能同时满足C（一致性）、A（可用性）、P（容错性）。

由于分区容错性 P 在分布式系统中是必须要保证的，因此我们在A、C之间进行权衡。

• Zookeeper 保证的是CP
• Eureka 保证的是AP

Zookeeper 保证的是CP

当向注册中心查询服务列表时，可以容忍注册中心返回的是几分钟之前的注册信息，但不能接受服务之间down掉。（可用性高于一致性）

当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举；但由于选举时间过长，在30-120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。

在云部署的环境下，因网络原因出现的整个zk集群失去 master 是较大概率发生的事件。

Eureka 保证的是AP

Eureka在设计中 各个节点是平等的，单独节点down掉，不影响其他节点正常工作。

Eureka的 客户端 在向Eure注册时，如果发现连接失败，则会自动切换到其他节点，只要有一台Eureka节点还在，就可以保证注册服务的可用性，但查到的信息可能不是最新的。（可用性高于一致性）

除此之外，Eureka的自我保护机制 在15分钟之内有15% 的服务无法正常心跳，Eurekarenwe客户端与注册中心出现网络故障，此时：

1、不在从注册列表中移除因长时间没收到心跳的而过期的服务

2、仍然能收到新的服务注册和查询请求，但不会同步到其他节点上（即保证当前节点可用）

3、当网络稳定时，当前实例新的注册信息会被同步到其他节点

因此，Eureka可以很好的应对因为网络故障导致的部分节点失去联系的情况，不是像Zookeeper那样使得整个注册服务瘫痪