从0开始学架构
李运华
资深技术专家
立即订阅
38968 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

23 | 想成为架构师,你必须掌握的CAP细节

李运华 2018-06-19
理论的优点在于清晰简洁、易于理解,但缺点就是高度抽象化,省略了很多细节,导致在将理论应用到实践时,由于各种复杂情况,可能出现误解和偏差,CAP 理论也不例外。如果我们没有意识到这些关键的细节点,那么在实践中应用 CAP 理论时,就可能发现方案很难落地。
而且当谈到数据一致性时,CAP、ACID、BASE 难免会被我们拿出来讨论,原因在于这三者都是和数据一致性相关的理论,如果不仔细理解三者之间的差别,则可能会陷入一头雾水的状态,不知道应该用哪个才好。
今天,我来讲讲CAP 的具体细节,简单对比一下 ACID、BASE 几个概念的关键区别点。

CAP 关键细节点

埃里克·布鲁尔(Eric Brewer)在《CAP 理论十二年回顾:“规则”变了》(http://www.infoq.com/cn/articles/cap-twelve-years-later-how-the-rules-have-changed)一文中详细地阐述了理解和应用 CAP 的一些细节点,可能是由于作者写作风格的原因,对于一些非常关键的细节点一句话就带过了,这里我特别提炼出来重点阐述。
CAP 关注的粒度是数据,而不是整个系统。
原文就只有一句话:
C 与 A 之间的取舍可以在同一系统内以非常细小的粒度反复发生,而每一次的决策可能因为具体的操作,乃至因为牵涉到特定的数据或用户而有所不同。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(44)

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

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

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

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

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

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

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

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

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

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

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

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

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

    2018-11-30
    6
  • 文竹
    电商网站核心功能有用户、产品、订单、支付、库存,相应的数据有用户、产品、订单、支付、库存。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    作者回复: 是的👍👍

    2019-04-02
    1
    2
  • 我的名字叫浩仔丶
    老师,请教下P是什么时机才会触发分区呢?

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

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

    作者回复: 分析思路很好

    2019-08-30
    1
  • 胖胖的程序猿
    怎么理解共享数据,假如A,B两个不同服务相连,并且公用同一个数据库表,这个是否算共享,是否算CAP范围。看上篇是要节点间发生数据复制情况才在cap范围,那一般是中间件系统才会有节点数据复制,web应用一般都不会有数据复制吧

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

    2019-04-03
    1
  • 姜华梁taric
    老师,互联与共享数据,怎么理解,可以举一个实例嘛

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

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

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

    2018-09-19
    1
  • 海军上校
    选择ap后,节点2如何感知到分区存在,然后返回错误的~不太懂

    作者回复: 心跳也可以,别人通知它也可以,取决于不同的架构方式,你看看高可用集群的架构模式

    2018-07-25
    1
  • jacy
    只从电商网站的核心业务分析,不考虑登录注册等业务,商品信息显示可细分为关键商品信息(如价格,库存)和非关键信息(商品介绍,用户评论),可按以前提到的分表分库的方法进行信息切割,对关键信息采用ca,非关键信息采用ap,最终达到base即可。

    作者回复: 思路正确,区分不同数据

    2018-06-27
    1
收起评论
44
返回
顶部