文章目录 一、CAP 理论概述 1、一致性 (Consistency) 强一致性 弱一致性 最终一致性⚡ 2、可用性 (Availability)️ 3、分区容错性 (Partition tolerance) 什么是分区 二、核心证明CAP 为什么只能满足其中两项⚖️ 三、如何在工程中权衡 CAP 1. CA without P理论模型 2. CP without A一致性优先 3. AP without C可用性优先 适合的才是最好的 CP 与 AP 的典型应用对比 四、总结当下分布式系统正变得越来越重要大型网站几乎都是分布式的。分布式系统的最大难点在于各个节点的状态如何同步。CAP 定理作为这方面的核心定理是理解分布式系统架构的起点。凡是有分布式系统开发经验的同学都应该对 CAP 理论有深刻的掌握。今天让我们再次深入探讨什么是 CAP 理论Fighting 引言CAP 是分布式系统特别是分布式存储领域中被讨论最多的理论“什么是 CAP 定理”在 Quora 分布式系统分类下长期排名 FAQ 的 No.1。CAP 在程序员群体中有着广泛的普及它绝不仅仅是简单的“C、A、P 不能同时满足最多只能 3 选 2”。以下我们将综合各方观点从发展历史、理论证明与工程实践等维度重新审视 CAP 理论希望带给你全新的启发与认知。 一、CAP 理论概述CAP 理论常被戏称为“帽子理论”它由加州理工大学伯克利分校的 Eric Brewer 教授在 2000 年 7 月的 ACM PODC 会议上首次提出。这是他在 Inktomi 期间研发搜索引擎和分布式 Web 缓存时总结出的关于数据一致性Consistency、服务可用性Availability和分区容错性Partition tolerance的著名猜想It is impossible for a web service to provide the three following guarantees : Consistency, Availability and Partition-tolerance.两年后的 2002 年麻省理工学院的 Seth Gilbert 和 Nancy Lynch 通过反证法从理论上严格证明了该猜想“如果三者可同时满足则由于允许 P 的存在网络间必然存在丢包从而无法保证 C。” 在此证明中CAP 的定义得到了进一步的规范化。自此CAP 理论正式成为分布式计算领域的公认定理又被称为布鲁尔定理Brewer’s theorem。⚠️注意需要区分的是CAP 理论中的 CA 与数据库事务 ACID 中的 CA 并非同一概念。两者的 C 都指一致性Consistency但 CAP 中的 A 指可用性Availability而 ACID 中的 A 指原子性Atomicity切勿混为一谈。那么为什么分布式系统只能在三者中选择其二呢让我们逐一拆解这三个核心要素 1、一致性 (Consistency)一致性Consistency指“all nodes see the same data at the same time”即所有节点在同一时间的数据完全一致对应多副本Replications问题中的强一致性Strong Consistency。根据对数据同步的要求程度一致性通常可分为以下三类 强一致性当更新操作完成后在任何时刻、任何用户或进程查询到的都是最近一次成功更新的数据。这是要求最高、最难实现的一致性级别传统关系型数据库的单机更新即为此类。 弱一致性数据更新后后续对该数据的读取操作可能得到更新后的值也可能是更改前的值不保证立即同步。 最终一致性在某一时刻不同节点上的数据可能存在差异但经过一段时间的同步后所有副本最终会达到一致状态。⚡ 2、可用性 (Availability)可用性Availability指“Reads and writes always succeed”即服务在正常响应时间内持续可用对于用户的每一个操作请求系统总能在有限时间内返回结果。业界通常用“N 个 9”来衡量系统的可用性。例如淘宝系统常宣称达到 5 个 9 的可用性99.999%意味着全年停机时间不超过( 1 − 0.99999 ) × 365 × 24 × 60 5.256 min (1 - 0.99999) \times 365 \times 24 \times 60 5.256\text{ min}(1−0.99999)×365×24×605.256min这是一个极高的技术挑战。高可用意味着系统在面对复杂的上下游环境如负载均衡、网关、应用服务、数据库等时不应出现用户操作失败或访问超时的不良体验。当发生生产事故时通常会通过“不可用时间占总时间的比例”来计算可用性指标并进行故障定级。降低故障发生频率与缩短故障持续时间是实现高可用的关键。️ 3、分区容错性 (Partition tolerance)分区容错性Partition tolerance指“the system continues to operate despite arbitrary message loss or failure of part of the system”即分布式系统在遭遇部分节点或网络分区故障时仍然能够对外提供满足一致性或可用性的服务。 什么是分区在分布式系统中不同节点分布在不同的子网络中。由于网络抖动、链路中断等原因部分子节点之间可能出现无法通信的状态但其各自内部的网络保持正常。这种将整个集群环境切分为若干个孤立区域的现象就被称为网络分区。 二、核心证明CAP 为什么只能满足其中两项如上图所示这是证明 CAP 的经典场景。网络中有两个节点N 1 N_1N1​和N 2 N_2N2​可理解为两台服务器彼此通过网络连通。N 1 N_1N1​包含应用程序 A 和数据库V 1 V_1V1​N 2 N_2N2​包含应用程序 B 和数据库V 2 V_2V2​。在满足一致性时V 1 V_1V1​与V 2 V_2V2​的数据始终保持一致V 0 V 0 V_0 V_0V0​V0​。在满足可用性时用户无论请求N 1 N_1N1​还是N 2 N_2N2​都能得到即时响应。在满足分区容错性时若N 1 N_1N1​与N 2 N_2N2​之间网络不通或某一方宕机不应影响彼此的基础运作。在系统正常运转时如上图用户向N 1 N_1N1​发起数据更新请求程序 A 将数据库中的V 0 V_0V0​更新为V 1 V_1V1​并通过同步机制 M 将V 1 V_1V1​同步到N 2 N_2N2​的数据库中使得N 2 N_2N2​的数据也更新为V 1 V_1V1​随后完成响应。然而分布式系统与单机系统的最大区别就在于网络的不确定性。假设发生极端情况——N 1 N_1N1​与N 2 N_2N2​之间的网络断开了即触发了分区 P此时若有用户向N 1 N_1N1​发送更新请求N 1 N_1N1​中的数据由V 0 V_0V0​变为V 1 V_1V1​。但由于网络断开同步操作 M 无法执行N 2 N_2N2​中的数据依然停留在V 0 V_0V0​。紧接着若有用户向N 2 N_2N2​发送读取请求由于数据尚未同步系统面临艰难抉择第一牺牲数据一致性保证可用性N 2 N_2N2​直接返回本地旧数据V 0 V_0V0​给用户保证响应速度但牺牲了强一致性。第二牺牲可用性保证数据一致性N 2 N_2N2​选择阻塞等待直到网络恢复、数据同步 M 完成后才向用户返回最新数据V 1 V_1V1​。这一推演过程直观地证明了在必须具备分区容错性P的分布式系统中系统无法同时兼顾一致性C与可用性A只能在二者中进行权衡取舍。⚖️ 三、如何在工程中权衡 CAP通过 CAP 理论可知系统无法同时满足 C、A、P 三个特性。在实际架构设计中我们通常面临以下三种取舍方向 1. CA without P理论模型如果不要求 P即假设网络永远稳定、绝不发生分区则 C 和 A 可以同时满足。传统单机或局域网下的关系型数据库如单机部署的 MySQL、Oracle即属此类。但在现代分布式环境下网络分区是一个客观存在的物理事实。如果盲目舍弃 P就等于放弃了分布式系统的多节点扩展能力这违背了分布式架构设计的初衷。正如 CAP 之父 Eric Brewer 在后来的文章《CAP Twelve Years Later》中所指出网络分区是不可避免的P 是分布式系统的基本前提我们无法通过削减 CA 来提升 PP 只能通过优化底层硬件与基础设施的稳定性来保障。因此在真实的分布式系统中我们本质上是在CP与AP之间做权衡。 2. CP without A一致性优先如果一个分布式系统无法容忍数据不一致宁可牺牲系统的可用性即在异常时拒绝服务或长时间阻塞等待则会选择保障 CP 并舍弃 A。典型代表分布式数据库如 HBase、分布式协调服务 ZooKeeper。场景解析以 ZooKeeper 为例其核心职责是保证各节点间元数据的高度一致。当发生网络分割或客户端心跳丢失时ZooKeeper 会迅速触发剔除机制或拒绝部分写请求宁可返回错误或导致客户端超时重试也绝不返回不一致的旧数据。 3. AP without C可用性优先为了追求极致的高可用并允许网络分区存在系统会选择放弃强一致性转而通过异步同步来实现最终一致性。典型代表注册中心 Eureka、各类大规模互联网高并发业务模块。场景解析以 12306 抢票或电商大促为例系统会将可用性放在首位。你在下单时系统提示有票并允许你提交订单但后台核验时可能提示“余票不足”。这种设计牺牲了下单瞬间的强一致性换取了系统的高并发与高可用随后通过异步补偿机制来保证数据的最终一致性。Eureka 机制当 Eureka 客户端与服务端心跳断开时服务端会启动自我保护机制保留注册表信息继续提供服务而不是粗暴地剔除节点这也是典型的 AP 架构设计。 适合的才是最好的金融财务场景涉及资金安全、账目核对等核心业务必须保证数据的一致性C。宁可发生网络故障时系统短暂停机如早前支付宝某光缆被挖断时表现出的长时间不可用也绝对不允许出现账目错乱。海量互联网场景对于商品浏览、点赞、评论等业务用户对毫秒级的强一致性并不敏感更在意页面的顺畅访问与高可用性A通常会采用 AP 架构并辅以 BASE 理论Basically Available, Soft state, Eventually consistent实现最终一致性。 CP 与 AP 的典型应用对比CP 典型应用电商平台的商品价格配置商家修改价格后要求各节点实时生效杜绝超卖或价格差。AP 典型应用内容社区的点赞与评论计数用户更在意点赞操作能否秒级响应短时间的数字不同步完全可以接受。 四、总结对于 CAP 理论的深度思考可以用一句话概括CAP 理论为我们划定了分布式系统的设计边界。虽然试图打破这一边界是徒劳的但优秀的架构设计能够让我们无限逼近边界并以此作为系统演进的航标。无论你是架构师还是后端开发工程师在设计和实现分布式系统时都应当结合业务场景的实际痛点在 CAP 权衡中找到最契合的平衡点。