• 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)当网络稳定时,当前实例新的注册信息会被同步到其他节点中,因

  • 相关阅读:
    推荐系统和业务系统对比:
    认识事物的过程是:
    思考:面向对象源码的解析和阅读需要注意和把握的点
    推荐系统中ES使用过程中遇到的问题:
    使用缓存功能要掌握住(心里有数)的点:
    思考:延迟决策是非常重要的
    压力测试中tps上不去的原因
    mysql 高级查询二
    mysql 高级查询
    fiddler设置https抓包
  • 原文地址:https://www.cnblogs.com/guangxiang/p/13491675.html
Copyright © 2020-2023  润新知