V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
jdz
V2EX  ›  程序员

cap 理论中,感觉没法牺牲分区容忍性,而保证可用性和一致性啊。牺牲分区容忍性的话,那么一旦分区,可用性就无法保证。是我理解的有偏差吗,求 v 友纠正

  •  
  •   jdz · 2020-03-06 21:51:49 +08:00 · 4389 次点击
    这是一个创建于 1748 天前的主题,其中的信息可能已经有所发展或是发生改变。
    26 条回复    2020-03-08 10:42:50 +08:00
    liprais
        1
    liprais  
       2020-03-06 21:59:26 +08:00 via iPhone
    为啥
    jdz
        2
    jdz  
    OP
       2020-03-06 22:02:13 +08:00 via Android
    @liprais 我理解无法容忍分区,那么分区后还能可用吗?
    hobochen
        3
    hobochen  
       2020-03-06 22:10:43 +08:00
    "cap 理论中,感觉没法牺牲分区容忍性,而保证可用性和一致性啊"

    对;这就是 CA 系统
    hobochen
        4
    hobochen  
       2020-03-06 22:12:44 +08:00
    hmmm 原谅我读了两遍你的问题

    不对

    简单的例子:有一个 service 是强一致 cache,只读不写;显然它们是一致的,并且分区不会影响可用性(只要读请求 hit 到任何一台机器都可以)
    ethego
        5
    ethego  
       2020-03-06 22:29:08 +08:00
    是的,对于分布式系统来说一般必须容忍出现分区,剩下的只能在 C 和 A 中权衡。
    neoblackcap
        6
    neoblackcap  
       2020-03-06 22:37:00 +08:00
    @hobochen 不行的,分区容忍性是必然存在的。你所说的只读不写。你想想存在这样的应用吗?整个集群就返回一个常量表?
    现实生活中必然有写的操作,一旦不将分区容忍性考虑进去。强一致性就无从谈起了。CAP 实际上只有 CA 可以选,P 是必然存在的,不存在 CA 系统
    lhx2008
        7
    lhx2008  
       2020-03-06 22:56:23 +08:00 via Android
    如果出现分区问题,保可用性的方法一般就是 cache,像 dns 这种,一个分区的数据可能都是旧的。
    如果要保一致性,那么就是小的那个分区不可用,大的分区还能用,像 zookeeper
    lhx2008
        8
    lhx2008  
       2020-03-06 23:00:34 +08:00 via Android
    像 zookeeper 的话,5 个节点,现在变成 3 2 两个分区,小的分区两个都是不能用,3 个的那个分区还能用
    lcdtyph
        9
    lcdtyph  
       2020-03-06 23:04:40 +08:00
    对,P 是默认的,可选的只有 C 和 A
    az467
        10
    az467  
       2020-03-06 23:45:35 +08:00
    你想的没错,一个 CA 的分布式系统,如果没有分区容错性,那么一旦出现分区,这个系统就会崩溃,一个崩溃的系统当然什么都无法提供。
    不过,还是有办法保证 CA 的,只要想办法让分区不发生就好。

    至于分区能不能避免,这个就不是 CAP 理论的内容了。
    现实生活中我们一般都是认为不能。

    个人觉得 CAP 理论的描述挺烂的,给人一种硬往「不可能三角」上凑的感觉。
    littlefatpaper
        11
    littlefatpaper  
       2020-03-07 01:43:04 +08:00   ❤️ 1
    本人刚学的时候也是各种翻资料,下面说下我的理解,希望对你有帮助:
    先把每个拆分得概念理解清楚,然后依赖一些生活场景加以联想

    C 一致性:保证同一时间访问所有节点的数据都是一致的
    A 可用性:在系统中一部分节点故障后,系统是否还能响应客户端的读写请求。
    P 分区容错:系统不能在时限内达成数据一致性,就是发生了分区(以上是 Wiki 的解释)。由于计算机中没有百分百可靠的通信协议(通信原理、计算机网络的内容),所以系统内肯定会存在部分节点在时限内无法通信,而造成数据不一致的问题。所以 P 是肯定是满足的。

    一致性其实细分还可分为:强一致性(一个节点更新,其他节点也要更新),最终一致性(只要保证后续某一时刻访问,系统)
    假设分布式系统中,由于 P 的客观存在,一个节点挂了(短时间内无法和系统内其他节点同步数据),而其他节点数据有更新。要满足一致性,必须等其他数据必须要同步数据到该节点,才允许客户端访问。要是满足可用性,系统在向客户端提供服务的时候,已经无法保证系统内的数据一致了。
    综上,分布式系统 CAP 最多只能满足两个条件,其中 P 是必须有的,无法同时满足 CAP。

    剩下有种情况 CA 也是讨论很多的,既然排除了 P,那系统需在时限内保证数据一致,那单体架构单节点是最稳的了。那还要保证一致性,单节点就一份数据,完全一致。而可用性,要么继续服务,要么整个挂。
    mcfog
        12
    mcfog  
       2020-03-07 05:06:04 +08:00 via Android   ❤️ 1
    “牺牲分区容忍性”的意思是不支持分区,而不是分区后会怎样

    cap 是三个互相独立的维度,可用性和是否分区无关,一个系统不分区也不一定默认就是可用的,例如磁带机只能顺序读取且寻道时间很长,那么在业务是十个消费者一起随机读写数据,单台磁带机就是不具备分区容忍性的同时没有可用性
    inwar
        13
    inwar  
       2020-03-07 07:58:07 +08:00 via Android
    理论的完整在于它包含所有可能情况的假设
    q447643445
        14
    q447643445  
       2020-03-07 08:51:53 +08:00
    这个要看从什么角度来看吧. 分两个情况, 数据是否可用 和 服务是否可用
    1.如果从数据可用的角度来看.丢掉分区容错 p 即可满足 数据一致性 c 可用性 a
    2.如果从服务可用的角度来看.丢掉分区容错 p 可用性 a 也没有了 只能满足 数据一致性 c.

    如果描述的是数据是否可用 也分两种情况:
    1.如果描述的分布式系统 分区容错 p 就注定存在 只能 数据一致性 c 和数据可用性 a 二选一
    2.如果描述的是系统架构 分区容错 p 就可以丢掉 成为数据可用数据一致的单点系统, 数据无法保证可用的 cp 分布式系统 ,数据无法保证一致的 ap 分布式系统,


    在讨论这个 cap 的时候 我觉得很容易谈混淆
    hobochen
        15
    hobochen  
       2020-03-07 10:26:04 +08:00 via iPhone
    @neoblackcap 所以 zookeeper 这样的系统只有 C ?居然不是 AC ?
    clrss
        16
    clrss  
       2020-03-07 10:28:23 +08:00 via iPhone
    只要保证不分区就可以了,但显然一般都不能保证
    hobochen
        17
    hobochen  
       2020-03-07 10:34:01 +08:00 via iPhone
    @neoblackcap 看起来是我对 AC 的理解有些问题...
    lewis89
        18
    lewis89  
       2020-03-07 10:41:15 +08:00   ❤️ 2
    @hobochen #15 他表述有问题,实际上就 CP AP 两个可以选,没有 CA CA 是单体不能严格算作分布式系统

    AP 高可用就是 redis 集群模式,每次写副本都是异步同步,通常在副本实例里面读到历史版本也是可以容忍的,但是最终会读到最新的版本

    CP 不高可用就是 zookeeper 每次写完,要所有的副本同步完此次写才算是成功写完,此时其它的请求想读这条数据没门,因为数据压根没同步完,在请求方看来 这就是一个强一致性的系统,虽然系统内部可能节点状态不一定统一,但是对外,会看到一个一致性的集群。

    要理解 CAP 首先要理解强一致性,CP AP 其实本质上就是 系统内部节点的数据同步的两种形式,AP 系统可以容忍读取到历史版本数据(在互联网行业通常如此,C 端用户并没有太高的数据一致性需求),CP 不能容忍读取到历史版本数据 就这么简单,不要搞复杂了。
    neoblackcap
        19
    neoblackcap  
       2020-03-07 11:17:51 +08:00
    @hobochen CA 的选择不是整个系统要选,你大可这一次操作选择 CP,另外的一个操作选择 AP。所以选择一致性还是可用性是这样选。不是一定说你这个系统就是强一致性就不能有高可用性。这个权衡不是一次性的,可以多次的。
    至于 zk 是不是 AC, @lewis89 已经说明了。
    高可用跟一致性不是两个极端,我大可放松一些求最终一致性,然后同时获得更高的高可用性。但是这就不是什么 CA 系统。因为你在满足强一致性的情况下,做不到高可用。要不你就搞单机系统
    mtrec
        20
    mtrec  
       2020-03-07 11:36:03 +08:00 via Android
    cap 的粒度可以很小 不是说一个 cp 系统就所有操作都是 cp 大部分时间系统都可以保持 cap 只是某些异常时刻要做出抉择牺牲一个
    hantsy
        21
    hantsy  
       2020-03-07 12:41:07 +08:00
    Microservices 理论设计中常常选择 A 优先,保持 [最终] 一致性( C 允许某个时刻不一致,这种情况很应用中很常见,电商中状态更新并不是及时的等)。
    Aresxue
        22
    Aresxue  
       2020-03-07 14:09:28 +08:00
    P 不能保证的话那这个分布式还有什么意义,想想一台机器坏了所有服务都不可用,还不如单机呢
    mreasonyang
        23
    mreasonyang  
       2020-03-07 15:00:51 +08:00 via iPhone
    现实中只要是分布式系统,分区问题必然存在,那么为了保证系统可用就必须保证分区一致性
    xuanbg
        24
    xuanbg  
       2020-03-07 15:54:03 +08:00
    一致性其实是和分区可用性相关且互斥的。可用性其实和其他两者没啥关系,而且你必须选择它。可用性都不存在了,还要什么自行车……
    所以,如果你要分布式,就必须牺牲一致性。要搞一致性,就不能搞分布式。
    xuanbg
        25
    xuanbg  
       2020-03-07 16:01:20 +08:00
    @xuanbg 补充一下,所以可以推断出所谓的「分布式事务」就是扯淡。CAP 你都要,可能吗?
    ujued
        26
    ujued  
       2020-03-08 10:42:50 +08:00 via iPhone
    分布式即为多台计算机一起运算对外提供服务。

    CA 系统,
    1. 可以满足 C。各计算机节点不进行网络通信交换数据,只使用自己的数据。各节点数据是一致的。
    2. 可以满足 A。某特节点故障,我们还可以使用其他节点的服务。

    AP 系统,
    1. 可以满足 P。系统可能在一段时间出现了网络分区,这时系统会有一定机制持续保持数据一致性,到最终一致。即我们不容忍分区错误,可以用手段消除分区。(有限时间内一定可以消除分区)
    2. 可以满足 A。系统依然可以提供服务,但可能是在数据不一致的情况下提供的,即在服务数据最终一致性前提供的是含错误数据的服务。

    CP 系统,
    1. 可以满足 P。系统可能在一段时间出现了网络分区,这时系统会有一定机制持续保持数据一致性,到最终一致。即我们不容忍分区错误,可以用手段消除分区。(有限时间内一定可以消除分区)
    2. 可以满足 C。在消除分区前牺牲可用性,即系统要么不提供服务,要么就是在数据一致后提供服务。


    以我的经验看,分布式系统中,最多用的还是 AP 系统,在一些特殊服务中需要 CP 系统,不会使用 CA 系统。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5875 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 39ms · UTC 01:51 · PVG 09:51 · LAX 17:51 · JFK 20:51
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.