zookeeper 保证 CP

传统关系型数据库 ACID

　　A：原子性：事务里面的所有操作，要么全部做完，要么都不做，只要有一个失败，整个事务都失败，需要回滚

　　C：一致性：以转账案例为例，假设有五个账户，每个账户余额是100元，那么五个账户总额是500元，如果在这个5个账户之间同时发生多个转账，无论并发多少个，比如在A与B账户之间转账5元，在C与D账户之间转账10元，在B与E之间转账15元，五个账户总额也应该还是500元，这就是保护性和不变性

　　I：隔离性：并发的事务之间互不影响

　　D：持久性：事务一旦提交，数据将永久保存在数据库上　　

NoSQL 数据库 CAP

　　C：强一致性：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

　　A：可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

　　P：分区容错性：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。（在分布式环境下，这个 p ，一定要实现）

zookeeper 保证 CP

　　当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的信息，但不能就收服务直接 down 掉不可用。也就是说服务注册的可用性要高于一致性

　　当时 zk 会出现这么一个情况，当 mastr 节点因网络故障和其他节点失去联系时，剩余节点会重新进行选举。问题在于，选举时间比较长，30s~120s，且选举期间，整个 zk 是不可用的。这就导致了在选举期间，注册服务的瘫痪。在云部署的环境下，因网络问题使 zk 集群时区 master 节点是交大概率会发生的事情，虽然服务能够最终恢复，但是漫长的选举时间导致的注册服务长期不可用是不能容忍的。

Eureka 保证 AP

　　Eureka 明白这一点，因此在设计时，就优先保证可用性.Eureka 各个节点是平等的，几个节点挂掉不会影响正常工作，只要有一台 Eureka 存在，就可以保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka 还有一种自我保护机制，如果在 15 分钟内超过 85% 的节点没有正常的心跳，那么 Eureka 就会认为客户端与注册中心出现了故障，此时会出现以下几种情况：

　　1、Eureka 不再从注册列表中移出因长时间没收到心跳而应该过期的服务

　　2、Eureka 仍然能够接受新服务的注册和查询要求，但是不会被同步到其他节点上（即保证当前节点依然可用）

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

结论

　　Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像 zookeeper 那样使整个祖册服务瘫痪