请简述 CAP 原理。

在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点(切记：分布式系统最终是达到所有状态的，也就是最终一致性。随着时间的延长，和其它条件的证实，可以去掉错误的状态。)：

一致性（Consistency） （等同于所有节点访问同一份最新的数据副本）
可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）
分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择[3]。）

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。

维恩图或三角形通常用于形象化CAP定理。系统分为使用相交圆描绘的三个类别。

CAP定理将系统分为三类：

CP（一致性和分区容忍度）—乍一看，CP类别令人困惑，即，一个一致且分区容忍但从不可用的系统。CP是指仅在网络分区的情况下牺牲可用性的系统类别。
CA（一致和可用）—在没有任何网络分区的情况下，CA系统是一致且可用的系统。通常，单个节点的数据库服务器被归类为CA系统。单节点DB服务器不需要处理分区容限，因此被视为CA系统。该理论唯一的漏洞是单节点DB系统不是共享数据系统的网络，因此不属于CAP的范畴。[^ 11]
AP（可用和分区容忍）—这些系统可用且分区容忍但不能保证一致性。

这三个部分相交的部分是白色的，因为在网络共享数据系统中不可能具有所有三个属性。Ven n图或三角形是CAP 的不正确可视化。任何CAP定理的可视化，例如三角形或维恩图，都具有误导性。考虑CAP的正确方法是，在网络分区的情况下（极少数情况），需要在可用性和一致性之间进行选择。

在任何联网的共享数据系统中，分区容限都是必须的。网络分区和丢弃的消息已成事实，必须进行适当的处理。因此，系统设计人员必须在一致性和可用性之间进行选择。简单地说，网络分区迫使设计人员选择完美的一致性或完美的可用性。选择一致性意味着无法回答客户的查询，因为系统不能保证返回最近的写入。这牺牲了可用性。

网络分区会强制非故障节点拒绝客户端的请求，因为这些节点无法保证数据的一致性。在频谱的另一端，可用意味着能够响应客户的请求，但是系统不能保证一致性，即写入的最新值。在给定情况下，可用的系统会提供最佳的答案。

在正常操作（缺少网络分区）期间，CAP定理不会对可用性或一致性施加任何约束。

CAP定理负责引发关于分布式共享数据系统中各种折衷的讨论。它在增进我们对共享数据系统的理解方面发挥了关键作用。但是，CAP定理因过于简单和经常误导而受到批评。在CAP定理发布后的十多年中，Brewer承认CAP定理过分简化了在发生网络分区时可用的选择。

根据Brewer的说法，CAP定理仅禁止“设计空间的一小部分：在存在分区的情况下实现完美的可用性和一致性，这是很少见的。”系统设计人员具有处理网络分区和从网络分区中恢复的多种选择。每个系统的目标都必须是“最大化对特定应用有意义的一致性和可用性的组合。”

历史

这个定理起源于加州大学柏克莱分校（University of California, Berkeley）的计算机科学家埃里克·布鲁尔在2000年的分布式计算原理研讨会（PODC）上提出的一个猜想。[5] 在2002年，麻省理工学院（MIT）的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明，使之成为一个定理。[1]

吉尔伯特和林奇证明的CAP定理比布鲁尔设想的某种程度上更加狭义。定理讨论了在两个互相矛盾的请求到达彼此连接不通的两个不同的分布式节点的时候的处理方案。

针对 Doris 案例，请用 UML 时序图描述 Doris 临时失效的处理过程（包括判断系统进入临时失效状态，临时失效中的读写过程，失效恢复过程）。

关键技术点 - 临时失效的 fail over

物理节点2临时失效，并在可接受时间内恢复。
物理节点X：备用节点，临时存放失效的物理节点2的数据，物理节点2恢复后迁移回物理节点2
物理节点2临时失效及恢复期间物理节点1承担所有read操作。

时序图

参考

https://dzone.com/articles/understanding-the-cap-theorem

https://zh.wikipedia.org/zh-hans/CAP%E5%AE%9A%E7%90%86

极客大学架构师训练营系统架构 CAP原理分布式系统脑裂第六次作业相关推荐

什么是系统架构师，系统架构师应具备哪些能力？
目录什么是系统架构师? 系统架构师应具备哪些能力? 什么是系统架构师? 系统架构师是一个既需要掌控整体,又需要洞悉局部瓶颈,并依据具体的业务场景给出解决方案的团队领导型人物.一个架构师需要有足够的想 ...
极客大学产品经理训练营产品文档和原型作业4
作业 [本周作业]写一个用例,挑一个:你自己的产品 / 你喜欢的产品 / [拍东西]发起拍卖/ [知识星球]加入星球/ [极客时间]购买课程: 1. 标题作者修改历史标题:[极客时间]购买课程作者 ...
极客大学产品经理训练营：业务流程与产品文档第11课总结
讲师:邱岳 1. 原型图 1.1 手绘图 + Scanner Pro 1.2 线框图 1.3 高保真产品图 1.4 做原型图的目的坍缩:规划时梦到自己成了乔布斯,赶紧画个图让自己冷静冷静: 具体:具 ...
极客大学产品经理训练营：产品文档和原型咋弄 - 流程图第9课总结
讲师:邱岳 1. 图的意义流程图.活动图.时序图.状态图,本次聚焦于过程和行为描述. 提效.宏观.点睛. 梳理思路用例:做什么? 流程图:怎么做? 2. 流程图.活动图.时序图 3. 动手画 – ...
极客大学产品经理训练营极客时间购买课程-大作业
1. 标题作者修改历史标题:[极客时间]购买课程作者历史时间易筋创建 2021-01-09 易筋添加购买流程图6 2021-03-02 易筋添加购买时序图7 2021-03-16 2. ...
极客大学产品经理训练营：数据分析与商业分析，商业分析到业务分析第18课总结
讲师:邱岳 1. 产品经理眼中的利润.成本.收入利润 = 收入 - 成本奶茶利润率极高,达到60%左右.但是奶茶盈利比较难. 所有买水的产品利润率都极高,比如可口可乐,咖啡,奶茶等. 案例:有个面 ...
极客大学产品经理训练营：业务架构与概念模型第10课总结
讲师:邱岳 1. 什么是状态图系统中的概念或对象随着一些事件的发生,改变了状态,通常这个状态比较多.比较复杂时,我们需要用状态图来表示他们的边界,以及触发状态转换的活动. 2. 动手画 – 员工状态 ...
极客大学产品经理训练营解决方案的设计与积累第6课总结
说明讲师:邱岳(二爷) 1. 解决方案解决方案的前提是明确了利益相关者和待解决的问题出解决方案是产品经理的天职,不要直接转发注意 X-Y Problem,核心关注 X 大量的练习/模仿/ ...
极客大学产品经理训练营认识产品经理下第2课总结
说明讲师:邱岳(二爷) 分享提纲互联网产品经理的能力模型互联网产品经理的个人素质产品经理的特质与气场互联网产品经理的职业发展阶段与晋级之路互联网产品经理的若干真相 1. 产品经理的能力模型 ...
极客大学产品经理训练营：产品经理的职业规划第20课总结
讲师:邱岳 1. 简历(你)作为产品简历可能是你向你未来同事展示的第一个作品,关于你自己的经历.特点.审美,所以要像设计和研发一个产品那样设计好你的简历. 当谈论产品的时候,我们的思路应该依然是:用 ...

极客大学架构师训练营系统架构 CAP原理分布式系统脑裂第六次作业

请简述 CAP 原理。

历史

针对 Doris 案例，请用 UML 时序图描述 Doris 临时失效的处理过程（包括判断系统进入临时失效状态，临时失效中的读写过程，失效恢复过程）。

关键技术点 - 临时失效的 fail over

时序图

参考

极客大学架构师训练营系统架构 CAP原理分布式系统脑裂第六次作业相关推荐

最新文章

热门文章

极客大学架构师训练营 系统架构 CAP原理 分布式系统脑裂 第六次作业

请简述 CAP 原理。

历史

针对 Doris 案例，请用 UML 时序图描述 Doris 临时失效的处理过程（包括判断系统进入临时失效状态，临时失效中的读写过程，失效恢复过程）。

关键技术点 - 临时失效的 fail over

时序图

参考

极客大学架构师训练营 系统架构 CAP原理 分布式系统脑裂 第六次作业相关推荐

最新文章

热门文章

极客大学架构师训练营系统架构 CAP原理分布式系统脑裂第六次作业

极客大学架构师训练营系统架构 CAP原理分布式系统脑裂第六次作业相关推荐