zoukankan      html  css  js  c++  java
  • CAP(eureka与zookeeper对比)

    CAP原则又称CAP定理,指的是在一个分布式系统中,这三个要素最多只能同时实现两点,不可能三者兼顾。

    一致性(Consistency)[kənˈsɪstənsi]可用性(Availability)[əˌveɪlə'bɪləti]、分区容错性(Partition tolerance)[pɑːrˈtɪʃn ˈtɑːlərəns] 

         ZooKeeper中保证了CP。对可用性并没有保证。如下:

         不能保证每次服务请求的可用性。任何时刻对ZooKeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注:也就是在极端环境下,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果)。所以说,ZooKeeper不能保证服务可用性。

          进行leader选举时集群都是不可用。在使用ZooKeeper获取服务列表时,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说,ZooKeeper不能保证服务可用性。

            Eureka看明白了这一点,因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或者如果发现链接失败时,则会自动切换至其他节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用),只不过查到的信息可能不是最新的(不保证一致性)。除此以外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现一下几种情况:
          (1)Eureka不在从注册列表中移除因为长时间没收到心跳而应该过期的服务
          (2)Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点上(保证当前节点依然可用)
          (3)当网络稳定时,当前实例新的注册信息会被同步到其他节点中,因

  • 相关阅读:
    Spring Boot中的那些生命周期和其中的可扩展点(转)
    mongodb,redis,mysql的区别和具体应用场景(转)
    linux相关知识
    docker安装应用整理
    SpEL表达式总结(转)
    An association from the table user_ product refers to an unmapped class: com. hiber.pojo. User
    LoadRunner安装时提示缺少C++ 2005 SP1(x86)插件
    Web框架,Hibernate向数据库插入数据,数据库没有值怎么办?
    数据库忘记原来的密码
    在线手机验证码免费查验接收
  • 原文地址:https://www.cnblogs.com/guangxiang/p/13491675.html
Copyright © 2011-2022 走看看