Eureka比Zookeeper好在哪里？

 

Eureka遵照AP，Zookeeper遵照CP

RDBMS（oracle/mysql、sqlServer） ====> ACID， 关系型数据库遵循ACID原则；

NoSQL（redis/mongodb）====> CAP

 1、ACID的介绍

ACID分别为：

原子性（Automicity）：事务里面的全部操做，要么所有作完，要么全不作；事务成功的条件是事务里面的全部操做都成功，只要有一个操做失败，整个事务就失败，须要回滚；

一致性（Consistency）：数据库要一直处于一致的状态，事务的运行不会改变数据库本来的一致性约束；也就是说：若是事务是并发多个，系统也必须如同串行事务同样操做。其主要特征是保护性和不变性(Preserving an Invariant)，以转帐案例为例，假设有五个帐户，每一个帐户余额是100元，那么五个帐户总额是500元，若是在这个5个帐户之间同时发生多个转帐，不管并发多少个，好比在A与B帐户之间转帐5元，在C与D帐户之间转帐10元，在B与E之间转帐15元，五个帐户总额也应该仍是500元，这就是保护性和不变性。

隔离性（Isolation）： 并发的事务之间不会互相影响；

持久性（Durability）：在事务完成之后，该事务对数据库所做的更改便持久的保存在数据库之中，并不会被回滚。

 

2、CAP的介绍

CAP分别为：强制一致性（Consistency），可用性（Availability），分区容错性（Partition tolerance）：

CAP的3进2：任何一个分布式系统中，没法同时知足CAP3个原则，最多只能知足其中的2个；

CAP的理论核心：任何一个分布式系统中，没法同时知足强制一致性、可用性、分区容错性这3个需求；所以，根据CAP原则将NoSQL 数据库分红知足CA原则、CP原则、AP原则三大类：

CA原则：单点集群，知足一致性、可用性的原则，一般在扩展上不太强；

CP原则：知足一致性、分区容错的系统，一般性能不是特别高；

AP原则：知足可用、分区容错的系统，一般对一致性要求低一点；

因为当前的网络硬件确定会出现延迟丢包的问题，因此分区容错性是咱们必须实现的，因此分布式系统只能在强制一致性和可用性中权衡；

所以：Zookeeper保证的是CP，Eureka保证的是AP；

当向注册中心查询服务列表时，咱们能够容忍服务返回的是几分钟以前的数据，可是咱们不能容忍服务之间Down掉不可用。也就是说服务的注册功能对可用性的要求高于一致性。

可是Zookeeper中会出现一种状况，当master节点由于网络故障和其余节点失去联系了时，剩余的节点会从新选举leader。可是选举leader的时间太长，30~120s，并且选举期间整个Zookeeper集群是不可用的，这就致使选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得Zookeeper的master失去联系可能性是很大的，虽然最后服务可以恢复，可是较长时间的选举致使注册的长期不可用是不能容忍的；

Eureka的各个节点是平等的，几个节点挂掉不会影响正常节点的工做，剩余的节点依然能够提供注册和查询的服务。Eureka的客户端在向某个Eureka注册的时候，若发现链接失败，则会自动切换至其余节点，只要一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查询到的信息可能不是最新的（不保证强一致性）。除此以外，Eureka还有一种自我保护机制，若是在15分钟内，超过85%的节点都没有正常的心跳，那么Eureka就认为客户端和注册中心之间出现了网络故障，此时会出现如下状况：

（1）Eureka再也不从注册中心表中移除由于长时间没有收到心跳而应该过时的服务；

（2）Eureka仍然可以接收新的服务注册和查询的请求，可是不会被同步到其余节点上去（即保证当前节点依然可用）；

（3）当网络稳定时，当前实例新的注册信息会被同步到其余节点上去；

所以，Eureka能够很好的应对因网络故障致使部分节点失去联系的状况，而不会向Zookeeper那样使整个注册服务瘫痪；