CAP原则--Eureka对比Zookeeper

关系型数据库RDBMS（MySQL、Oracle、sqlServer）：遵循ACID
非关系型数据库NoSQL（Redis、mongdb）：遵循CAP

ACID

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

CAP

• C（Consistency）：强一致性
• A（Availablity）：可用性
• P（Partition tolerance）：分区容错性

在分布式系统中，这三个原则最多满足两个

CAP的核心

• 一个分布式系统不可能同时很好的满足CAP这三个需求
• 所以根据CAP原理，将NoSQL数据库分为了满足CA原则，满足CP原则和满足AP原则三大类
  • CA：单点集群，满足一致性 ，可用性的系统，可扩展性较差
  • CP：满足一致性、分区容错性的系统，性能不高
  • AP：满足可用性，分区容错性的系统，对一致性要求较低

Eureka和Zookeeper的区别

因为分区容错性P在分布式系统中是必须要保证的，所以只能在CP、AP之中权衡

• Eureka满足的是AP
• Zookeeper满足的是CP

Zookeeper满足CP原则

• 当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接收服务直接宕掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是Zookeeper会出现一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会进行leader选举。但是由于leader选举时间太长（30s~120s），而且整个选举期间Zookeeper集群处于不可用状态，这就导致在选举期间注册服务是瘫痪的，在云部署情况下，因为网络问题使得Zookeeper集群失去master节点是较大概率发生的时间，虽然最终服务能全部恢复，但是过长的选举时间导致注册服务长时间不可用是难以容忍的。

Eureka满足AP原则：

• Eureka在设计时就优先保证可用性。Eureka的每个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点仍然可以提供注册和服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要一台Eureka还在，就能保证注册服务的可用性，只不过查到的可能不是最新消息，而且Eureka还有自我保护机制，如果15分钟内超过85%节点没有传递正常心跳。那么Eureka就认为客户端与注册中心出现网络故障，此时：

  • Eureke不再从注册列表中移除因为长时间没收到心跳而应该移除的服务
  • Eureka仍然能接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点依然可用）
  • 当网络稳定时，其他节点恢复，当前实例新的注册信息会被同步到其他节点中

• Eureka可以很好的应对因为网络故障导致部分节点失去联系的情况