• luop
    2018-08-24
    结合这两期对 CAP 的学习和思考,谈下个人的理解。

    设计分布式系统的两大初衷:横向扩展(scalability)和高可用性(availability)。“横向扩展”是为了解决单点瓶颈问题,进而保证高并发量下的「可用性」;“高可用性”是为了解决单点故障(SPOF)问题,进而保证部分节点故障时的「可用性」。由此可以看出,分布式系统的核心诉求就是「可用性」。这个「可用性」正是 CAP 中的 A:用户访问系统时,可以在合理的时间内得到合理的响应。

    为了保证「可用性」,一个分布式系统通常由多个节点组成。这些节点各自维护一份数据,但是不管用户访问到哪个节点,原则上都应该读取到相同的数据。为了达到这个效果,一个节点收到写入请求更新自己的数据后,必须将数据同步到其他节点,以保证各个节点的数据「一致性」。这个「一致性」正是 CAP 中的 C:用户访问系统时,可以读取到最近写入的数据。

    需要注意的是:CAP 并没有考虑数据同步的耗时,所以现实中的分布式系统,理论上无法保证任何时刻的绝对「一致性」;不同业务系统对上述耗时的敏感度不同。

    分布式系统中,节点之间的数据同步是基于网络的。由于网络本身固有的不可靠属性,极端情况下会出现网络不可用的情况,进而将网络两端的节点孤立开来,这就是所谓的“网络分区”现象。“网络分区”理论上是无法避免的,虽然实际发生的概率较低、时长较短。没有发生“网络分区”时,系统可以做到同时保证「一致性」和「可用性」。

    发生“网络分区”时,系统中多个节点的数据一定是不一致的,但是可以选择对用户表现出「一致性」,代价是牺牲「可用性」:将未能同步得到新数据的部分节点置为“不可用状态”,访问到这些节点的用户显然感知到系统是不可用的。发生“网络分区”时,系统也可以选择「可用性」,此时系统中各个节点都是可用的,只是返回给用户的数据是不一致的。这里的选择,就是 CAP 中的 P。

    分布式系统理论上一定会存在 P,所以理论上只能做到 CP 或 AP。如果套用 CAP 中离散的 C/A/P 的概念,理论上没有 P 的只可能是单点(子)系统,所以理论上可以做到 CA。但是单点(子)系统并不是分布式系统,所以其实并不在 CAP 理论的描述范围内。
    展开

    作者回复: 写的非常好👍👍

     1
     140
  • 空档滑行
    2018-06-20
    一个电商网站核心模块有会员,订单,商品,支付,促销管理等。
    对于会员模块,包括登录,个人设置,个人订单,购物车,收藏夹等,这些模块保证AP,数据短时间不一致不影响使用。
    订单模块的下单付款扣减库存操作是整个系统的核心,我觉得CA都需要保证,在极端情况下牺牲P是可以的。
    商品模块的商品上下架和库存管理保证CP,搜索功能因为本身就不是实时性非常高的模块,所以保证AP就可以了。
    促销是短时间的数据不一致,结果就是优惠信息看不到,但是已有的优惠要保证可用,而且优惠可以提前预计算,所以可以保证AP
    现在大部分的电商网站对于支付这一块是独立的系统,或者使用第三方的支付宝,微信。其实CAP是由第三方来保证的,支付系统是一个对CAP要求极高的系统,C是必须要保证的,AP中A相对更重要,不能因为分区,导致所有人都不能支付
    展开

    作者回复: 分析思路很清晰

    
     42
  • 飞
    2018-06-19
    独家解读啊,赞
    
     16
  • 乘风
    2018-11-30
    老师 你上面说redis集群是互联且数据共享,但按官网上说redis集群后,每个主节点的数据是不一致的,也不存在共享数据,现在对cap中指的分布式系统(互联且数据共享)还是不太明白,谢谢老师

    作者回复: 这里的共享是指同一份数据在多个节点都有,但并不一定在所有节点都有,简单理解有数据复制的系统就是CAP应用的场景。

    一份数据在多个节点有但不是所有节点都有,这是非对称集群;例如ES
    所有数据在所有节点都有,这是对称集群,例如zookeeper

     1
     7
  • 文竹
    2018-08-21
    电商网站核心功能有用户、产品、订单、支付、库存,相应的数据有用户、产品、订单、支付、库存。

    对于用户数据,选择CP。因为用户注册后,可能几分钟后重新登录,所以需要满足一致性;在网络出现分区时,因为需要满足一致性而暂时不能提供写服务,所以无法满足可用性;对于分区容错性,只要能返回一个合理的响应就能满足,这一点能很好满足。

    对于产品数据,无需满足一致性,所以选择AP。
    对于订单数据,业务需要满足一致性,所以选择CP。
    对于支付数据,业务需要满足一致性,所以选择CP。
    对于库存数据,业务需要满足一致性,所以选择CP。
    展开

    作者回复: 思路很清晰👍👍

    
     5
  • feifei
    2018-06-20
    电商网站要做高可用架构,就必须先确定业务模块,我没有过电商的经验,就说说我的理解,电商主要有商品,用户,交易,这3快核心

    商品,商户发布某商品或者修改商品,用户查看商品,不需要非常强的一致性,即可以一部分用户先看到,可以使用最终一致性,满足可用性和容错性,可以使用发布队列,进行发布

    用户,有普通的用户,商户这2种用户,用户模块的功能都是注册和登录,需要保证一致性,不能出现用户注册成功了,却不能登录。为了将宕机影响控制在最小,以用户进行分布,针对单节点可以使用数据库的主从,从节点分担读压力

    交易,由于交易系统有强一致性要求,用户的交易要只能成功或者失败,有强事务的处理,考虑交易量大的问题,也按照用户进行分布,单节点采用数据库的集群,数据的多分写入

    这是我的一个初步设计,还请老师指点,谢谢
    展开

    作者回复: 大概思路就是这样,按照业务分析

    
     5
  • 正是那朵玫瑰
    2018-08-25
    老师有个疑问,像电商这样的系统,有订单系统和库存系统,创建订单会调用库存系统,这两个系统是互联的,但是并没有数据共享,但超时的情况下,会造成订单数据和库存数据状态不一致,这种算不算cap讨论范畴呢?

    作者回复: 不算,CAP的应用范围已经明确了:互联,共享数据。
    这种情况下的不一致靠对账,人工修复等方式解决

    
     4
  • zhouwm
    2018-07-24
    CAP理论延时问题:因为延时无法避免意味着完美CP场景不存在。—— 这个说法有问题,一致性是从外部使用者的角度去看的(黑盒),只要在回复应答前保障数据已经同步到其他节点,后续请求能得到新数据就是一致的,etcd就是完美cp,zk其实也能算完美cp。延时问题是系统设计的时候要考虑的点

    作者回复: 不会的,zk是顺序一致性,保证不了完美cp,raft为了可理解而简化了异常处理,某些场景下会丢失数据

    
     4
  • Leon Wong
    2018-06-21
    我理解CA和CP不是系统的整体设计,而是具体业务点的设计权衡,一种tradeoff ,表现形式是分布式系统在检测到网络分区发生的时候,是倾向于一致性C或是可用性A。而CA对应到的场景是不考虑分区容错的场景,数据有可能在整个分布式系统里只存一份(如果引入多副本相当于引入分区问题),那么就会有单点故障的风险,只能通过将数据分散存储在不同服务器的做法来降低风险的影响面。

    可见每一个设计都有优势,也有弊端,我们需要根据具体场景去做tradeoff……

    作者回复: 架构设计就是判断和选择😀

    
     4
  • 王磊
    2018-06-19
    系统架构中考虑p和不考虑p,对外表现是什么?例如对于考虑p的系统,当p发生时,它还是functon的?发生分区意味着节点间不再联通,数据不再共享,要么为了c回复错误,此时丢了a; 要么为了a,但可能会返回过期数据,丢了c。所以考虑了p比没考虑p的系统到底带来额外什么好处?

    作者回复: 考虑P的系统在分区场景下还能提供部分业务

    
     4
  • xiao皮孩。。
    2019-04-02
    理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致,即丧失了C性质。如果为了保证数据一致性,将分区一侧的节点设置为不可用,那么又丧失了A性质。除非两个节点可以互相通信,才能既保证C又保证A,这又会导致丧失P性质。

    作者回复: 是的👍👍

     1
     3
  • zhouwm
    2018-07-31
    cap的c指的是线性一致性还是顺序一致性?如果把zk改成读写请求都通过master的话,是否就算完美CP了?因为延时对外不可见。raft在什么情况下丢数据,我理解的丢数据指的是给了请求者正确应答后,写入的数据没保存好,理论上不应该出现的(如果是磁盘缓存导致的,有可能),k8s之类的用etcd也是基于raft的,如果会丢数据都无法保证的话,坑有点大,应该不会有人用吧

    作者回复: CAP的C是严格意义上的绝对一致性,因为不考虑复制延时。

    zk全部走master就不符合CAP的CP定义了,因为CAP是要求各个节点都可以提供读写操作,而不是只做备份复制

    Raft论文中对于leader切换时可能覆盖日志给了一个详细的案例,这个案例不常见,发生概率非常小,而且只覆盖一条数据

    
     3
  • 肖一林
    2018-06-20
    在开源的分布式系统中,通常可以让用户配置,选择是CP还是AP,比如kafka,每种消息都可以选择配置。这就是CAP理论对数据粒度的控制。老师归纳的非常好。

    作者回复: 掌握了理论,看具体各种系统实现就比较容易理解了

    
     3
  • 我的名字叫浩仔丶
    2018-06-28
    老师,请教下P是什么时机才会触发分区呢?

    作者回复: 断网,网线断也可以,网卡坏也可以,交换机故障也可以

    
     2
  • 云辉
    2018-06-19
    对CAP和Base了解更清楚了,原来Base是说出现P的情况下一种合适的解决方案
    
     2
  • godtrue
    2019-08-30
    电商系统,首先回想一下,我觉得涉及的东西相当庞杂,如果以是否对用户可见来划分,对用户可见的部分有账户管理、商品搜索管理、订单管理等,主要涉及用户登录,商品搜索列表页,商品详情页,商品结算页,商品支付页,订单列表页,订单详情页,售后商品页等。用户不可见的主要是商品的采购管理,商品的仓储管理,订单的物流管理,订单的退换货,订单的备件管理等,当然,还有秒杀、夺宝岛、时效等。根据CAP理论P不可避免,我们只能根据业务情况去权衡是选择C还是A,我觉得只要和钱不直接挂钩的为了系统的高可用性都会选择A,保证系统的可用性,数据一致性采用最终一致性,而和钱直接挂钩比如:支付,我觉得就应该选择C啦!即使提示支付失败牺牲点用户的体验,也不要造成用户的误会。
    不过,这些情况发生的概率比较小,可能我们的系统相对用户感知度小,经过几次大促都没有出现什么特别大的问题。如果有问题,我们也会保A的,系统都不可用了,那比出现可弥补的错误要严重的多。
    展开

    作者回复: 分析思路很好

    
     1
  • 金蝉子
    2019-05-16
    CAP细节:
    1,CAP关注的粒度是数据,而不是系统,系统中往往需要根据模块业务特性来选择是AP还是CP
    2,CAP是忽略网络延迟的,在存在延迟的情况下,没有绝对的CP,都是某种意义上的最终一致性
    3,在没有分区出现的情况下,是可以同时满足CA的,并不是说在分区出现的情况下,可以牺牲掉C或者A,而是要在分区恢复的时候能够自愈
    4,BASE理论是对AP的延伸,达到最终一致性
    
     1
  • 胖胖的程序猿
    2019-04-03
    怎么理解共享数据,假如A,B两个不同服务相连,并且公用同一个数据库表,这个是否算共享,是否算CAP范围。看上篇是要节点间发生数据复制情况才在cap范围,那一般是中间件系统才会有节点数据复制,web应用一般都不会有数据复制吧

    作者回复: 你说的这个不算,分布式节点通过复制来共享数据才算

    
     1
  • 姜华梁taric
    2018-11-19
    老师,互联与共享数据,怎么理解,可以举一个实例嘛

    作者回复: memcache集群不互联不共享数据,redis集群互联且共享数据

    
     1
  • 阿巍-豆夫
    2018-09-19
    老师,我一直很困惑,在cp的架构中,如果一旦发生分区,怎么保证c呢? 连个节点网络都不可达了,怎么可能保证一致性呢? ap我能理解为很好实现。

    作者回复: 直接不允许写,或者分区节点不提供服务,参考Paxos或者Zookeeper

    
     1
我们在线,来聊聊吧