全栈工程师修炼指南
熊燚(四火)
Oracle首席软件工程师
立即订阅
2286 人已学习
课程目录
已更新 43 讲 / 共 40 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 从成长角度看,为什么你应该成为全栈工程师?
免费
学习路径 | 怎样成为一名优秀的全栈工程师?
导读 | 如何学习这个专栏?
第一章 网络协议和 Web 接口 (6讲)
01 | 网络互联的昨天、今天和明天:HTTP 协议的演化
02 | 为HTTP穿上盔甲:HTTPS
03 | 换个角度解决问题:服务端推送技术
04 | 工整与自由的风格之争:SOAP和REST
05 | 权衡的艺术:漫谈Web API的设计
06 | 特别放送:北美大厂如何招聘全栈工程师?
第二章 欢迎来到 MVC 的世界 (7讲)
07 | 解耦是永恒的主题:MVC框架的发展
08 | MVC架构解析:模型(Model)篇
09 | MVC架构解析:视图(View)篇
10 | MVC架构解析:控制器(Controller)篇
11 | 剑走偏锋:面向切面编程
12 | 唯有套路得人心:谈谈Java EE的那些模式
13 | 特别放送:选择比努力更重要
第三章 从后端到前端 (7讲)
14 | 别有洞天:从后端到前端
15 | 重剑无锋,大巧不工:JavaScript面向对象
16 | 百花齐放,百家争鸣:前端MVC框架
17 | 不一样的体验:交互设计和页面布局
18 | 千言万语不及一幅画:谈谈数据可视化
19 | 打开潘多拉盒子:JavaScript异步编程
20 | 特别放送:全栈团队的角色构成
第四章 数据持久化 (7讲)
21 | 赫赫有名的双刃剑:缓存(上)
22 | 赫赫有名的双刃剑:缓存(下)
23 | 知其然,知其所以然:数据的持久化和一致性
24 | 尺有所短,寸有所长:CAP和数据存储技术选择
25 | 设计数据持久层(上):理论分析
26 | 设计数据持久层(下):案例介绍
27 | 特别放送:聊一聊代码审查
第五章 寻找最佳实践 (6讲)
28 | Ops三部曲之一:配置管理
29 | Ops三部曲之二:集群部署
30 | Ops三部曲之三:测试和发布
31 | 防人之心不可无:网站安全问题窥视
32 | 和搜索引擎的对话:SEO的原理和基础
33 | 特别放送:聊一聊程序员学英语
第六章 专题 (7讲)
34 | 网站性能优化(上)
35 | 网站性能优化(下)
36 | 全栈开发中的算法(上)
37 | 全栈开发中的算法(下)
38 | 分页的那些事儿
39 | XML、JSON、YAML比较
40 | 全栈衍化:让全栈意味着更多
全栈工程师修炼指南
登录|注册

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

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

理解概念

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

1. CAP 的概念

CAP 理论,又叫做布鲁尔理论(Brewer’s Theorem),指的是在一个共享数据的分布式存储系统中,下面三者最多只能同时保证二者,对这三者简单描述如下:
一致性(Consistency):读操作得到最近一次写入的数据(其实就是上一讲我们讲的强一致性);
可用性(Availability):请求在限定时间内从非失败的节点得到非失败的响应;
分区容忍性(Partition Tolerance):系统允许节点间网络消息的丢失或延迟(出现分区)。
下面,请让我进一步说明,从而帮助你理解。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《全栈工程师修炼指南》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(3)

  • tt
    我在某银行的省级分行工作。大体上,账务核心是全国集中的,标准银行业务从粗力度上看直接与核心发生交互,而对于分省的特色业务,是通过分行接入核心进行账务交易,分行系统与三方商户进行交互和资金清算。分行会记录金融交易的状态,商户也会记录状态。
    从记录金融交易状态这一点来看,总行核心、分行交易系统、商户IT系统算是构成了一个分布式的存储吧。

    其实这不是第一次听到CAP这个理论,但今天在听到老师的问题时,突然觉得日常交易配置中的种种风格都可以用CAP或者BASE理论来解释。(ACID在上述某个节点如分行系统内部运行,这里不讨论了)。

    比如,发生账务交易时,是先在总行账务核心进行还是先去商户进行业务处理等。

    分区容忍性对应到我的业务场景,就是交易未明,这时分行会进行冲正(先冲正核心或者先冲正商户系统)或者先查询再冲正,如果此时网络恢复,则强一致性得到了满足。但如果经过一定次数的重试后仍然未明,就只能依赖于第二天的对账来进行了,此时业务柜员会进行手工处理。

    所以,从这个角度上来说,上面三个节点系统保障的是最终一致性,适用于BASE。而银行核心的内部节点间适用于CAP的CP。

    作者回复: 说得很好 :) 感谢。

    即便如银行,在一些出现网络分区的场景下依然优先保证可用性,而可以牺牲一致性。

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