全栈工程师修炼指南
熊燚(四火)
Oracle 首席软件工程师
32206 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 46 讲
全栈回顾 (1讲)
加餐 (1讲)
全栈工程师修炼指南
15
15
1.0x
00:00/00:00
登录|注册

24 | 尺有所短,寸有所长:CAP和数据存储技术选择

网络分区
数据同步
BASE
ACID
例外情况
分布式系统
航空公司售票
门户网站
CAP 三角形
NoSQL
分区容忍性的必选性
图示
分区容忍性
可用性
一致性
扩展阅读
选修课堂:从 ACID 到 BASE
总结思考
实际场景
存储技术的选择:NoSQL 三角形
三选二?
进一步理解
CAP 理论
CAP和数据存储技术选择

该思维导图由 AI 生成,仅供参考

你好,我是四火。
在上一讲中我们着重讲了持久层的一致性,其实,它是分布式系统的一个基础理论。你可能会问,学习基于 Web 的全栈技能,也需要学习一些分布式系统的技术吗?是的!特别是我们在学习其持久层的时候,我们还真得学习一些分布式系统的基础理论,从而正确理解和使用我们熟悉的这些持久层技术。
CAP 理论就是分布式系统技术中一个必须要掌握的内容,也是在项目早期和设计阶段实实在在地影响我们技术选型、技术决策的内容。

理解概念

我想,你已经很熟悉一致性了。今天,在一致性之后,我们也要涉及到 CAP 的另外的两个方面——可用性和分区容忍性。

1. CAP 的概念

CAP 理论,又叫做布鲁尔理论(Brewer’s Theorem),指的是在一个共享数据的分布式存储系统中,下面三者最多只能同时保证二者,对这三者简单描述如下:
一致性(Consistency):读操作得到最近一次写入的数据(其实就是上一讲我们讲的强一致性);
可用性(Availability):请求在限定时间内从非失败的节点得到非失败的响应;
分区容忍性(Partition Tolerance):系统允许节点间网络消息的丢失或延迟(出现分区)。
下面,请让我进一步说明,从而帮助你理解。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

CAP理论是分布式系统中的重要概念,强调在共享数据的分布式存储系统中,一致性、可用性和分区容忍性三者最多只能同时保证二者。文章通过图示和案例解释了CAP理论的概念和应用,强调了P(分区容忍性)是必选项,而具体选择CP还是AP需要根据实际情况进行权衡。CAP理论关注节点间的数据交换和数据共享,对于不需要分区容忍性的系统,如单节点系统或节点间无数据共享的系统,CAP理论并不适用。此外,文章还介绍了NoSQL数据库的概念和应用,指出NoSQL数据库在Web 2.0时代对于关系数据库不擅长的场景具有较高的性能和横向扩展性优势。在实际业务中,可以利用CAP定理来权衡和帮助选择合适的存储技术。文章还通过实际应用场景举例,说明了在不同情况下选择CP或AP的合理性,并强调了选择是一个带有灰度的过程,需要具体问题具体分析。通过本文的学习,读者可以彻底掌握CAP理论的原理,并能够逐渐在设计中应用起来,特别是在技术选型做“权衡”的时候。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《全栈工程师修炼指南》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(4)

  • 最新
  • 精选
  • tt
    我在某银行的省级分行工作。大体上,账务核心是全国集中的,标准银行业务从粗力度上看直接与核心发生交互,而对于分省的特色业务,是通过分行接入核心进行账务交易,分行系统与三方商户进行交互和资金清算。分行会记录金融交易的状态,商户也会记录状态。 从记录金融交易状态这一点来看,总行核心、分行交易系统、商户IT系统算是构成了一个分布式的存储吧。 其实这不是第一次听到CAP这个理论,但今天在听到老师的问题时,突然觉得日常交易配置中的种种风格都可以用CAP或者BASE理论来解释。(ACID在上述某个节点如分行系统内部运行,这里不讨论了)。 比如,发生账务交易时,是先在总行账务核心进行还是先去商户进行业务处理等。 分区容忍性对应到我的业务场景,就是交易未明,这时分行会进行冲正(先冲正核心或者先冲正商户系统)或者先查询再冲正,如果此时网络恢复,则强一致性得到了满足。但如果经过一定次数的重试后仍然未明,就只能依赖于第二天的对账来进行了,此时业务柜员会进行手工处理。 所以,从这个角度上来说,上面三个节点系统保障的是最终一致性,适用于BASE。而银行核心的内部节点间适用于CAP的CP。

    作者回复: 说得很好 :) 感谢。 即便如银行,在一些出现网络分区的场景下依然优先保证可用性,而可以牺牲一致性。

    2019-11-04
    3
  • 💢 星星💢
    以前看过不少这类的文章。老师的话浅显易懂。让我加深了理解。
    2020-03-16
    1
  • leslie
    老师的BASE确实初次接触:分布式的课程其实同时在学包括相关的书籍同时在看;不过现在NOSQL中还是牵涉了大量的类SQL的东西,RMDB又对NOSQL的JSON做了很好的兼容,包括<分布式技术原理与算法解析>的老师其实也提到分布式的问题。 个人觉得现在其实绝对边界是没有的:不然不会真实的生产中都是用数据系统或者中间件存储整体去解决问题,现在已经没有或者极少单独的CS或BS;其实还是一个合理整合吧。就像老师说的全栈其实还是有核心的,通过中间去合理结合周边从而达到需要的效果。 RMDB-NOSQLDB-MQ:这是整个一条链,合理的结合业务场景去承担/分担相应的工作是需要摸索和探索的。
    2019-11-04
    1
  • 靠人品去赢
    有了解过,我觉得涉及到业务基本会考虑CP。 牺牲可用性也要保证数据一致性,肯定是平台类商家的库存商品类的订单,尤其是防止同一个商品被多人下单。
    2019-11-05
收起评论
显示
设置
留言
4
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部