EureKa与ZooKeeper的CAP原则分析

EureKa与ZooKeeper的CAP原则分析

回顾CAP原则

在关系型数据库系统中RDBMS (Mysql、Oracle、sqlServer)，一个事务往往具有ACID特性

在非关系型数据库中NoSQL(redis、mongdb)，往往遵循CAP原则

ACID是什么？

• A(Atomicity) 原子性
  • 一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。
• C(Consistency)一致性
  • 在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束、触发器、级联回滚等。
• I(Isolation)隔离性
  • 数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括未提交读（Read uncommitted）、提交读（read committed）、可重复读（repeatable read）和串行化（Serializable）
• D(Durability)持久性
  • 事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

CAP是什么？

• C(Consistency) 强一致性
  • 在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
• A(Availability)可用性
  • 在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
• P(Partition tolerance) 分区容错性
  • 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

CAP的三进二出：CA、AP、CP

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掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是ZK会出现这样一种情况，当master结点因为网络故障与其他结点失去联系时，剩余结点会重新进行leader选举，问题在于，选取leader的时间太长30~120s,且选举期间整个ZK集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zk集群失去master结点是较大概率会发生的事件，虽然最终能够回复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证的是AP

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个结点都是平等的。几个结点挂掉不会影响正常结点的工作，剩余的结点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他结点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查看到的信息可能不是最新的，除此之外，Eureka还是一种自我保护机制，如果在15分钟内超过85%的结点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

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

​ 2.Eureka仍然能够接收新服务注册和查询请求，但是不会被同步到其他结点（即保证当前结点依然可用）

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

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