精华内容
下载资源
问答
  • CAP理论/AP架构/CP架构

    万次阅读 多人点赞 2018-10-30 14:55:21
    最近有时间研究分布式架构,因为公司使用的Zookeeper,并没有使用Spring Cloud Eureka,所以想探究一下他们之间的区别,于是看到简书里的文章:Spring Cloud Eureka简介及与Zookeeper对比,明显的区别可能就是...

    最近有时间研究分布式架构,因为公司使用的Zookeeper,并没有使用Spring Cloud Eureka,所以想探究一下他们之间的区别,于是看到简书里的文章:Spring Cloud Eureka简介及与Zookeeper对比,明显的区别可能就是Zookeeper为CP设计,而Eureka为AP设计,但是对CAP/AP/CP很不理解,于是查阅资料,做一个简单的了解。

    Eureka服务治理机制与Dubbo服务治理机制的比较

    Feature Eureka Zookeeper
    服务健康检查 可配支持 (弱)长连接,keepalive
    CAP AP CP
    watch支持(客户端观察到服务提供者变化) 支持 long polling/大部分增量 支持
    自我保护 支持 -
    客户端缓存 支持 -
    自身集群的监控 metrics -

    Eureka支持健康检查,自我保护等

    Zookeeper为CP设计,Eureka为AP设计。作为服务发现产品,可用性优先级较高,一致性的特点并不重要,宁可返回错误的数据,也比不反回结果要好得多。

    服务列表变更Zookeeper服务端会有通知,Eureka则通过长轮询来实现,Eureka未来会实现watch机制

    CAP理论提出就是针对分布式数据库环境的,所以,P这个属性是必须具备的。
    P就是在分布式环境中,由于网络的问题可能导致某个节点和其它节点失去联系,这时候就形成了P(partition),也就是由于网络问题,将系统的成员隔离成了2个区域,互相无法知道对方的状态,这在分布式环境下是非常常见的。
    因为P是必须的,那么我们需要选择的就是A和C。
    大家知道,在分布式环境下,为了保证系统可用性,通常都采取了复制的方式,避免一个节点损坏,导致系统不可用。那么就出现了每个节点上的数据出现了很多个副本的情况,而数据从一个节点复制到另外的节点时需要时间和要求网络畅通的,所以,当P发生时,也就是无法向某个节点复制数据时,这时候你有两个选择:
    选择可用性 A(Availability),此时,那个失去联系的节点依然可以向系统提供服务,不过它的数据就不能保证是同步的了(失去了C属性)。
    选择一致性C(Consistency),为了保证数据库的一致性,我们必须等待失去联系的节点恢复过来,在这个过程中,那个节点是不允许对外提供服务的,这时候系统处于不可用状态(失去了A属性)。

    最常见的例子是读写分离,某个节点负责写入数据,然后将数据同步到其它节点,其它节点提供读取的服务,当两个节点出现通信问题时,你就面临着选择A(继续提供服务,但是数据不保证准确),C(用户处于等待状态,一直等到数据同步完成)。

    展开全文
  • 分布式架构之CAP理论/AP架构/CP架构

    万次阅读 2019-07-22 00:45:43
    著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性)、A(可用性)、和P(分区容错性)。由于分区容错性P在分布式系统中必须要保证的,因此我们只能在A...Zookeeper保证的是CP, Eureka则是AP。 但是对C...

    上一篇梳理一下 CAP定理:https://blog.csdn.net/Soinice/article/details/96782876

    著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性)、A(可用性)、和P(分区容错性)。由于分区容错性P在分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡。

    因此: 
    Zookeeper保证的是CP, 
    Eureka则是AP。

    但是对CAP/AP/CP很不理解,于是查阅资料,做一个简单的了解。

    Zoopkeeper保证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那样使整个注册服务瘫痪。

    Eureka服务治理机制与Dubbo服务治理机制的比较

    Eureka支持健康检查,自我保护等。

    Zookeeper为CP设计,Eureka为AP设计。

    作为服务发现产品,可用性优先级较高,一致性的特点并不重要,宁可返回错误的数据,也比不反回结果要好得多。

    服务列表变更Zookeeper服务端会有通知,Eureka则通过长轮询来实现,Eureka未来会实现watch机制。

    取与舍

    CAP理论提出就是针对分布式数据库环境的,所以,P这个属性是必须具备的。
    P就是在分布式环境中,由于网络的问题可能导致某个节点和其它节点失去联系,这时候就形成了P(partition),也就是由于网络问题,将系统的成员隔离成了2个区域,互相无法知道对方的状态,这在分布式环境下是非常常见的。
    因为P是必须的,那么我们需要选择的就是A和C。
    大家知道,在分布式环境下,为了保证系统可用性,通常都采取了复制的方式,避免一个节点损坏,导致系统不可用。那么就出现了每个节点上的数据出现了很多个副本的情况,而数据从一个节点复制到另外的节点时需要时间和要求网络畅通的,所以,当P发生时,也就是无法向某个节点复制数据时,这时候你有两个选择:
    选择可用性 A(Availability),此时,那个失去联系的节点依然可以向系统提供服务,不过它的数据就不能保证是同步的了(失去了C属性)。
    选择一致性C(Consistency),为了保证数据库的一致性,我们必须等待失去联系的节点恢复过来,在这个过程中,那个节点是不允许对外提供服务的,这时候系统处于不可用状态(失去了A属性)。

    最常见的例子是读写分离,某个节点负责写入数据,然后将数据同步到其它节点,其它节点提供读取的服务,当两个节点出现通信问题时,你就面临着选择A(继续提供服务,但是数据不保证准确),C(用户处于等待状态,一直等到数据同步完成)。

    文章参考:

    https://blog.csdn.net/zhumengguang/article/details/80156792 
    https://blog.csdn.net/u013058742/article/details/83541905 

    展开全文
  • CAP理论: CAP原则又称CAP定理,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance),但是CAP 原则指示3个要素最多只能同时实现...AP架构: 明显AP结构...

    CAP理论

    CAP原则又称CAP定理,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance),但是CAP 原则指示3个要素最多只能同时实现两点,不可能三者兼顾,由于网络硬件肯定会出现延迟丢包等问题,但是在分布式系统中,我们必须保证部分网络通信问题不会导致整个服务器集群瘫痪,另外即使分成了多个区,当网络故障消除的时候,我们依然可以保证数据一致性,所以我们必须保证分区容错性;

    至于剩下的一致性和可用性,我们需要二选一,但是鱼和熊掌不可兼得,假设我们选择一致性,那我们就不能让用户访问无法进行数据同步的机器,毕竟该机器上的数据和其他正常机器上的不一致,但是这样我们就丢弃了可用性;假设我们选择可用性,那我们就可以让用户访问无法进行数据同步的服务器,虽然保证了可用性,但是我们无法保证数据一致性。

    具体解释如下:

    在这里插入图片描述
    上面的图少了一部分,这里补上:
    在这里插入图片描述
    动画演示:

    可以通过分布式系统中实现一致性的raft算法来了解一下,该算法用动画演示了领导选举、日志复制等过程,这些过程保证在分区错误的情况下依然保证整个集群的数据一致性,其中有一个自旋时间决定节点变成选举人,还有一个心跳时间来发送日志,现在来说一下具体过程,假设当前集群初始启动,之后等到一个自旋时间经过之后,所有人都变成了候选人,之后进行投票,票数最高会成为领导,当然可以会经过多轮选举领导人,领导人在自旋心跳时间之后就会给跟随者发送心跳,然后获得他们的心跳,了解他们是否还活着,如果领导挂掉,那么将再次进行选举,知道选出领导人,当然跟随者死了是不会进行选举的,即使之前挂掉的老领导再回来,它也只能当跟随者了,那些活过来的跟随者会从领导者那里复制日志数据,从而保证集群的数据一致性;如果由于网络原因导致多个节点变成了多个区域,比如之前是5个节点,由于网络原因分成了2个区,那么这两个区独自选择领导,当网络恢复之后,网络故障之前的领导将成为新的领导(如果这个另外还是分区领导的话),它将删除自己还没有使用的日志信息,之后从另外一个分区前领导那里复制日志数据,用来保证集群的数据一致性,这些知识点在上面那个网站中都有演示到,最后再说一点领导选举需要大多数人同意,也就是所有节点的一半以上,比如6个要有一个节点得到4个节点的赞同才能成为领导,即使由于网络故障被分区了也是这样,看的是全部的节点,而不是由于网络故障造成的分区节点,所以在网络故障造成的分区中由于一个分区只有2个节点,而全部有6个节点,所以2个节点的不能选出领导,但是那2个节点之前有一个是老领导,那我们使用的还是是老的领导,如果这2个节点之前没有一个节点是领导,那就不会有领导;

    以上是分步演示,还有一个网站可以自己去控制过程,它就是raft算法动画演示,我们可以通过该网站来模拟leader宕机后的领导选举、领导如何保存数据等等过程

    在这里插入图片描述

    AP架构

    明显AP结构选择了高可用和分区容错性,此时,那个失去联系的节点依然可以向系统提供服务,不过它的数据就不能保证是同步的了(失去了C属性)。Eureka就是一个AP架构的例子,当Eureka客户端心跳消失的时候,那Eureka服务端就会启动自我保护机制,不会剔除该EurekaClient客户端的服务,依然可以提供需求;
    在这里插入图片描述

    CP结构

    CP结构选择的是一致性和分区容错性,如果选择一致性C(Consistency),为了保证数据库的一致性,我们必须等待失去联系的节点恢复过来,在这个过程中,那个节点是不允许对外提供服务的,这时候系统处于不可用状态(失去了A属性)。最好的例子就是zookeeper,如果客户端心跳消失的时候,zookeeper会很快剔除该服务,之后就无法提供需求;
    在这里插入图片描述

    展开全文
  • CPCA:复杂虚拟仪器系统架构的云平台
  • 非结构化数据和结构化数据的技术选型对比: 保证K8S的有状态持久化数据不丢失(K8S...方案2优缺点:CP模型,1基础上+log-pilot增加可靠性。 方案3优缺点:不持久化直接kafka-udp,网络情况不稳定丢失。AP场景。 ...

    非结构化数据和结构化数据的技术选型对比:

    保证K8S的有状态持久化数据不丢失(K8S的卷存储不丢失):

    log-pilot打通宿主机和容器之间的卷存储,他天然支持断点续传。

     

    方案1优缺点:nfs卷存储持久化,flume存在单点可能丢失。AP场景。

    方案2优缺点:CP模型,1基础上+log-pilot增加可靠性。

    方案3优缺点:不持久化直接kafka-udp,网络情况不稳定丢失。AP场景。

    展开全文
  • 各种分布式中间件使用的架构如下: mysql单机:CA架构 eureka集群:AP架构 zookeeper集群:CP架构 nacos集群:AP或CP架构,可根据实例的(临时、持久)类型,来选择AP或CP redis集群:主要是AP架构,也可通过配置...
  • 介绍 CAR代表关联资产/风险。 它具有资产的实体以及它们之间的关系,以及与之相关的风险。 CAR服务用于共享和使用资产和风险信息,以更好地了解客户的环境和风险状况。 CAR服务由以下两个部分组成: ...
  • x86架构与ARM架构

    2018-03-21 21:45:44
    #x86##名称演变+ X86架构是微处理器执行的计算机语言指令集,指一个intel通用计算机系列的标准编号缩写,也标识一套通用的计算机指令集合。...该架构的第一款CPU为Intel 80386,它完全取代了16位x86架构CP...
  • arm架构, python3.6 torch-1.4.0-cp36-cp36m-linux_aarch64.whl

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,003
精华内容 401
关键字:

架构cpcp