阿里P9李运华:想成为架构师,你必须知道CAP理论

article/2025/9/1 11:09:36

CAP定理(CAP theorem)又被称作布鲁尔定理(Brewer's theorem),是加州大学伯克利分校的计算机科学家埃里克·布鲁尔(Eric Brewer)在2000年的ACM PODC上提出的一个猜想。2002年,麻省理工学院的赛斯·吉尔伯特(Seth Gilbert)和南希·林奇(Nancy Lynch)发表了布鲁尔猜想的证明,使之成为分布式计算领域公认的一个定理。对于设计分布式系统的架构师来说,CAP是必须掌握的理论。

布鲁尔在提出CAP猜想的时候,并没有详细定义Consistency、Availability、Partition Tolerance三个单词的明确定义,因此如果初学者去查询CAP定义的时候会感到比较困惑,因为不同的资料对CAP的详细定义有一些细微的差别,例如:

Consistency: where all nodes see the same data at the same time.

Availability: which guarantees that every request receives a response about whether it succeeded or failed.

Partition tolerance: where the system continues to operate even if any one part of the system is lost or fails.

(https://console.bluemix.net/docs/services/Cloudant/guides/cap_theorem.html#cap-)

Consistency: Every read receives the most recent write or an error.

Availability: Every request receives a (non-error) response – without guarantee that it contains the most recent write.

Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.

(https://en.wikipedia.org/wiki/CAP_theorem#cite_note-Brewer2012-6)

Consistency: all nodes have access to the same data simultaneously.

Availability: a promise that every request receives a response, at minimum whether the request succeeded or failed.

Partition tolerance: the system will continue to work even if some arbitrary node goes offline or can’t communicate.

(https://www.teamsilverback.com/understanding-the-cap-theorem/)

为了更好地解释CAP理论,我挑选了Robert Greiner(http://robertgreiner.com/about/)的文章作为参考基础。有趣的是,Robert Greiner对CAP的理解也经历了一个过程,他写了两篇文章来阐述CAP理论,第一篇被标记为“outdated”(有一些中文翻译文章正好参考了第一篇),我将对比前后两篇解释的差异点,通过对比帮助你更加深入地理解CAP理论。

CAP理论

第一版解释:

Any distributed system cannot guaranty C, A, and P simultaneously.

(http://robertgreiner.com/2014/06/cap-theorem-explained/)

简单翻译为:对于一个分布式计算系统,不可能同时满足一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)三个设计约束。

第二版解释:

In a distributed system (a collection of interconnected nodes that share data.), you can only have two out of the following three guarantees across a write/read pair: Consistency, Availability, and Partition Tolerance - one of them must be sacrificed.

(http://robertgreiner.com/2014/08/cap-theorem-revisited/)

简单翻译为:在一个分布式系统(指互相连接并共享数据的节点的集合)中,当涉及读写操作时,只能保证一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)三者中的两个,另外一个必须被牺牲。

对比两个版本的定义,有几个很关键的差异点:

  • 第二版定义了什么才是CAP理论探讨的分布式系统,强调了两点:interconnected和share data,为何要强调这两点呢? 因为分布式系统并不一定会互联和共享数据。最简单的例如Memcache的集群,相互之间就没有连接和共享数据,因此Memcache集群这类分布式系统就不符合CAP理论探讨的对象;而MySQL集群就是互联和进行数据复制的,因此是CAP理论探讨的对象。

  • 第二版强调了write/read pair,这点其实是和上一个差异点一脉相承的。也就是说,CAP关注的是对数据的读写操作,而不是分布式系统的所有功能。例如,ZooKeeper的选举机制就不是CAP探讨的对象。

相比来说,第二版的定义更加精确。

虽然第二版的定义和解释更加严谨,但内容相比第一版来说更加难记一些,所以现在大部分技术人员谈论CAP理论时,更多还是按照第一版的定义和解释来说的,因为第一版虽然不严谨,但非常简单和容易记住。

第二版除了基本概念,三个基本的设计约束也进行了重新阐述,我来详细分析一下。

1.一致性(Consistency)

第一版解释:

All nodes see the same data at the same time.

简单翻译为:所有节点在同一时刻都能看到相同的数据。

第二版解释:

A read is guaranteed to return the most recent write for a given client.

简单翻译为:对某个指定的客户端来说,读操作保证能够返回最新的写操作结果。

第一版解释和第二版解释的主要差异点表现在:

  • 第一版从节点node的角度描述,第二版从客户端client的角度描述。

相比来说,第二版更加符合我们观察和评估系统的方式,即站在客户端的角度来观察系统的行为和特征。

  • 第一版的关键词是see,第二版的关键词是read。

第一版解释中的see,其实并不确切,因为节点node是拥有数据,而不是看到数据,即使要描述也是用have;第二版从客户端client的读写角度来描述一致性,定义更加精确。

  • 第一版强调同一时刻拥有相同数据(same time + same data),第二版并没有强调这点。

这就意味着实际上对于节点来说,可能同一时刻拥有不同数据(same time + different data),这和我们通常理解的一致性是有差异的,为何做这样的改动呢?其实在第一版的详细解释中已经提到了,具体内容如下:

A system has consistency if a transaction starts with the system in a consistent state, and ends with the system in a consistent state. In this model, a system can (and does) shift into an inconsistent state during a transaction, but the entire transaction gets rolled back if there is an error during any stage in the process.

参考上述的解释,对于系统执行事务来说,在事务执行过程中,系统其实处于一个不一致的状态,不同的节点的数据并不完全一致,因此第一版的解释“All nodes see the same data at the same time”是不严谨的。而第二版强调client读操作能够获取最新的写结果就没有问题,因为事务在执行过程中,client是无法读取到未提交的数据的,只有等到事务提交后,client才能读取到事务写入的数据,而如果事务失败则会进行回滚,client也不会读取到事务中间写入的数据。

2.可用性(Availability)

第一版解释:

Every request gets a response on success/failure.

简单翻译为:每个请求都能得到成功或者失败的响应。

第二版解释:

A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).

简单翻译为:非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。

第一版解释和第二版解释主要差异点表现在:

  • 第一版是every request,第二版强调了A non-failing node。

第一版的every request是不严谨的,因为只有非故障节点才能满足可用性要求,如果节点本身就故障了,发给节点的请求不一定能得到一个响应。

  • 第一版的response分为success和failure,第二版用了两个reasonable:reasonable response 和reasonable time,而且特别强调了no error or timeout。

第一版的success/failure的定义太泛了,几乎任何情况,无论是否符合CAP理论,我们都可以说请求成功和失败,因为超时也算失败、错误也算失败、异常也算失败、结果不正确也算失败;即使是成功的响应,也不一定是正确的。例如,本来应该返回100,但实际上返回了90,这就是成功的响应,但并没有得到正确的结果。相比之下,第二版的解释明确了不能超时、不能出错,结果是合理的,注意没有说“正确”的结果。例如,应该返回100但实际上返回了90,肯定是不正确的结果,但可以是一个合理的结果。

3.分区容忍性(Partition Tolerance)

第一版解释:

System continues to work despite message loss or partial failure.

简单翻译为:出现消息丢失或者分区错误时系统能够继续运行。

第二版解释:

The system will continue to function when network partitions occur.

简单翻译为:当出现网络分区后,系统能够继续“履行职责”。

第一版解释和第二版解释主要差异点表现在:

  • 第一版用的是work,第二版用的是function。

work强调“运行”,只要系统不宕机,我们都可以说系统在work,返回错误也是work,拒绝服务也是work;而function强调“发挥作用”“履行职责”,这点和可用性是一脉相承的。也就是说,只有返回reasonable response才是function。相比之下,第二版解释更加明确。

  • 第一版描述分区用的是message loss or partial failure,第二版直接用network partitions。

对比两版解释,第一版是直接说原因,即message loss造成了分区,但message loss的定义有点狭隘,因为通常我们说的message loss(丢包),只是网络故障中的一种;第二版直接说现象,即发生了分区现象,不管是什么原因,可能是丢包,也可能是连接中断,还可能是拥塞,只要导致了网络分区,就通通算在里面。

CAP应用

虽然CAP理论定义是三个要素中只能取两个,但放到分布式环境下来思考,我们会发现必须选择P(分区容忍)要素,因为网络本身无法做到100%可靠,有可能出故障,所以分区是一个必然的现象。如果我们选择了CA而放弃了P,那么当发生分区现象时,为了保证C,系统需要禁止写入,当有写入请求时,系统返回error(例如,当前系统不允许写入),这又和A冲突了,因为A要求返回no error和no timeout。因此,分布式系统理论上不可能选择CA架构,只能选择CP或者AP架构。

1.CP - Consistency/Partition Tolerance

如下图所示,为了保证一致性,当发生分区现象后,N1节点上的数据已经更新到y,但由于N1和N2之间的复制通道中断,数据y无法同步到N2,N2节点上的数据还是x。这时客户端C访问N2时,N2需要返回Error,提示客户端C“系统现在发生了错误”,这种处理方式违背了可用性(Availability)的要求,因此CAP三者只能满足CP。



2.AP - Availability/Partition Tolerance

如下图所示,为了保证可用性,当发生分区现象后,N1节点上的数据已经更新到y,但由于N1和N2之间的复制通道中断,数据y无法同步到N2,N2节点上的数据还是x。这时客户端C访问N2时,N2将当前自己拥有的数据x返回给客户端C了,而实际上当前最新的数据已经是y了,这就不满足一致性(Consistency)的要求了,因此CAP三者只能满足AP。注意:这里N2节点返回x,虽然不是一个“正确”的结果,但是一个“合理”的结果,因为x是旧的数据,并不是一个错乱的值,只是不是最新的数据而已。



小结

今天我为你讲了CAP理论,通过对比两个不同版本的CAP理论解释,详细地分析了CAP理论的准确定义,希望对你有所帮助。

这就是今天的全部内容,留一道思考题给你吧,基于Paxos算法构建的分布式系统,属于CAP架构中的哪一种?谈谈你的分析和理解。


http://chatgpt.dhexx.cn/article/utpgtLHq.shtml

相关文章

笔记——专访李运华:程序员如何在技术上提升自己

原文链接:http://www.csdn.net/article/2014-10-20/2822190 摘要: 专访李运华:程序员如何在技术上提升自己 方法: 1 写博客 2 链式学习:从一个点不断学习相关的知识 3 闭环学习:了解整个功能或业务的全流…

【从零开始学架构-李运华】09|架构设计原则案例

【淘宝】 个人网站 > Oracle/支付宝/旺旺 > Java时代1.0 > Java时代2.0 > Java时代3.0 > 分布式时代 买一个快速可用、快速开发的系统。 MySQL升级Oracle,买性能 3. PHP切换Java,重构网站 4. 增加各种组件框架优化性能控制成本 5. 去I…

【从零开始学架构-李运华】05|复杂度来源:高可用

高可用的定义 系统无中断地执行其功能的能力,代表系统的可用性成都,是进行系统设计时的准则之一。 虽然方案五花八门但本质就是“冗余”! 与高性能的区别 高性能增加机器在于扩展处理性能,高可用在于增加冗余单元防止中断。 计算…

【从零开始学架构-李运华】04|复杂度来源:高性能

复杂度的六个来源之一:高性能 运算性能迅猛发展、软件复杂度发展、硬件存储发展。 用来代替旧技术的新技术才会给软件系统带来复杂度,而用来淘汰旧技术的新技术则不用担心。 1.单台计算机 手工操作->批处理->进程->分时多进程->进程通信-&…

【从零开始学架构-李运华】03|架构设计的目的

架构设计的误区 系统不一定需要架构设计; 架构设计不一定能提升开发效率; 好的架构设计能促进业务发展; 不是所有系统都需要架构设计; 等等…… 架构设计的真正目的 为了解决软件复杂度带来的问题 如何下手架构设计?…

李运华《从零开始学架构》——架构设计三原则

课程链接 https://time.geekbang.org/column/intro/100006601?utm_sourcetime_web&utm_mediummenu&utm_termtimewebmenu 分割线 前面几期专栏,我跟你系统的聊了架构设计的主要目的是为了解决软件系统复杂度带来的问题,并分析了复杂度的来源…

专访李运华:程序员如何在技术上提升自己

摘要:社区之星第56期采访了UC的软件工程师李运华,他先后经历了电信行业和互联网行业。在本次采访中,李老师分享了他的职场经历、团队管理经验、程序员提升自己的方法和应具备的素养,以及谈了对面向对象和编程语言看法。 李运华&a…

阿里P9李运华:架构到底是指什么?

你好,我是李运华。 2018 年,我发布了《从 0 开始学架构》这门课程,分享了我之前在电信业务和移动互联网业务方面的经验和感悟。 后来,我转岗去了蚂蚁国际,从事更加复杂的支付业务。为什么说支付业务更加复杂&#xf…

Rust之fluid用法(fltk ui 设计器)

fl2rust 用法 $ cargo install fl2rust然后运行&#xff1a; $ fl2rust <fl file>.fl > <output file>.rs 要通过 cargo 实现自动化&#xff0c;我们可以通过将 fl2rust 添加到构建依赖项中来将其用作库&#xff1a; # Cargo.toml [dependencies] fltk &q…

FLTK学习笔记2-回调函数

FLTK学习笔记2-回调函数 回调函数为控件添加回调函数程序示例 回调函数 回调函数&#xff08;Callback&#xff09;简单说来就是一个以函数指针的方式被调用的函数。 考虑如下情况&#xff0c;我们编写了一个整数排序算法函数mySort&#xff1a; void mySort(std::vector<…

rust 使用fltk 的小问题

rust 使用fltk 的小问题 windowns下进行编译使用cargo build --release 打包出现以下问题 最近有需求写一个简单的桌面应用程序&#xff0c;正好使用rust来练练手&#xff0c;中间碰到一些问题&#xff0c;尤其fltk 打包有个cmd黑框就很恶心。只记录一些国内网络上资料较少的问…

gmsh+fltk配置过程

本文主要讲解如何利用cmake进行配置带图形界面的gmsh,因为gmsh给出的qt范例只有简单的显示功能&#xff0c;而对 fltk中编写了较完整的功能&#xff0c;所以利用fltk进行说明&#xff0c;如需qt可参考链接。本文使用的编译器是vs2019 首先为了编译成功gmsh软件&#xff0c;我们…

FLTK学习笔记1-绘制基本控件(按钮、文本输入、容器)

FLTK学习笔记1-绘制基本控件&#xff08;按钮、文本输入、容器&#xff09; FLTK中的坐标FLTK常用控件按钮控件文本控件容器控件 绘制基本控件 FLTK中的坐标 在FLTK中坐标均为正整数&#xff0c;其单位是像素&#xff08;pixel&#xff09;&#xff0c;原点&#xff08;x0, y0…

FLTK中的字体

FLTK中的字体 字体在FLTK中的表示获取系统的字体编号表程序示例 字体在FLTK中的表示 在FLTK中&#xff0c;系统中的每一种字体都对应着一个整数类型(严格来讲是Fl_Font类型&#xff0c;但Fl_Font本身就是int的别名)的字体编号。例如&#xff0c;在本人的系统中“楷体”所对应的…

FLTK学习笔记4-在FLTK中显示图片(上)

FLTK学习笔记4-在FLTK中显示图片&#xff08;上&#xff09; Fl_JPEG_Image和Fl_PNG_ImageFl_Shared_Image程序示例 在FLTK中&#xff0c;并不是任何时候都可以绘图的&#xff08;当然也包括绘制图片&#xff09;&#xff0c;一般来讲我们只能在控件类中的 draw()方法中绘制所…

C++轻量级跨平台桌面GUI库FLTK的简单使用

C的跨平台桌面GUI库有很多&#xff0c;大体上分成两种流派&#xff1a;retained mode和immediate mode。 其中前者是主流的桌面GUI机制框架&#xff0c;包括&#xff1a;Qt、wxwidgets、gtk、juce等后者是一些游戏引擎编辑器常用的GUI机制框架&#xff0c;包括&#xff1a;img…

开源跨平台GUI库Fltk在Deepin Linux下的使用

开源跨平台GUI库Fltk在Deepin Linux下的使用 前言一、下载安装二、样例使用三、自编代码四、后记 前言 在互联网应用漫天的现在&#xff0c;实体企业、工厂却绕不开大量的桌面应用&#xff0c;开发工具有恐龙C#&#xff0c;有难用的MFC&#xff0c;也有没落的Delphi&#xff0…

Ubuntu安装FLTK详细过程

1.官网下载源码压缩包。版本建议最新&#xff0c;我这里的版本是1.3.8 2. 终端输入&#xff1a;sudo apt-get install build-essential xorg-dev libx11-dev libcairo2-dev //此步骤必要&#xff01;&#xff01;&#xff01;安装依赖库&#xff0c;不然后面安装总会出错&#…

[Rust GUI]fltk-rs的helloworld

1、安装VSCode 下载安装VSCode 安装VSCode扩展 rust-analyzer或rust-analyzer(CN) 2、安装Microsoft C 生成工具 访问微软官网下载生成工具&#xff0c;勾选使用 C 的桌面开发之后会自动勾选5个项目 取消勾选以下项目 用于 Windows 的 C CMake 工具 测试工具核心功能 - 生成…

使用CLion配置第一个FLTK界面

文章目录 写在前面安装与配置安装helloworld配置命令行配置CLion 运行结果 写在前面 假期抽时间学习一下跨平台GUI界面的开发, 正好也当做C的练手小项目了. C标准库中没有对于GUI的支持, 需要依赖三方库, 这里我先想到的是老牌跨平台GUI——Qt, 但是作为一个小项目感觉使用Qt有…