Eureka服务注册与发现

Posted on

1.CAP原则（与zookeeper对比）

回顾CAP原则

RDBMS(Mysql、Oracle、sqlServer) ===>ACID

NoSQL(redis、mongdb) ===>CAP

ACID是什么？

  • A (Atomicity) 原子性
  • C (Consistency) 一致性
  • I (IsoIation) 隔离性
  • D (Durability) 持久性

CAP是什么？

  • C (Consistency) 强一致性
  • A (Availabitlity) 可用性
  • P (Partition tolerance) 分区容错性

CAP的三进二：CA、AP、CP

CAP理论的核心

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

2.作为服务注册中心，Eureka比Zookeeper好在哪里？

著名的CAP理论指出，一个分布式系统不可能同时满足C（一致性）、A（可用性）、P（容错性）。

由于分区容错性在分布式系统中是必须要保证的，因此我们只能在A和C之间进行权衡。

  • Zookeeper保证的是CP
  • Eureka保证的事AP

Zookeeper：

当zk注册中心服务宕机，master节点就会与其他节点失去联系时，剩余的节点就会重新选举出一个leader当master节点，问题在于选举leader的时间太长30-120s，且选举期间zk集群都是不可用的，就导致了选举期间注册服务瘫痪。

Eureka：

Eureka看明白了这一点，因此设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂了都不会影响正常节点的工作。连接失败的时候会自动切换到其他节点。而且Eureka有自我保护机制，15分钟内超过85%的节点没有正常的心跳，就认为Eureka出现网络故障，会有以下措施：

  1. 不再从注册中心移除因时间长没收到心跳而过期的服务
  2. 仍然能够接收新服务的注册和查询请求，但是不会被同步到其他节点上
  3. 网络稳定时，当前实例新的注册信息会被同步到其他节点中

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