传统关系型数据库 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 那样使整个祖册服务瘫痪