- CAP 原理
- 定义
- 应用场景
- 弱化一致性
- 弱化可用性
- 弱化分区容忍性
CAP 原理
CAP 原理最早出现在 2000 年,由加州大学伯克利分校的 Eric Brewer 教授在 ACM 组织的 Principles of Distributed Computing(PODC)研讨会上提出猜想。两年后,麻省理工学院的 Nancy Lynch 等学者进行了理论证明。
该原理被认为是分布式系统领域的重要原理之一,深刻影响了分布式计算与系统设计的发展。
定义
CAP 原理:分布式系统无法同时确保一致性(Consistency)、可用性(Availability)和分区容忍性(Partition),设计中往往需要弱化对某个特性的需求。
一致性、可用性和分区容忍性的具体含义如下:
- 一致性(Consistency):任何事务应该都是原子的,所有副本上的状态都是事务成功提交后的结果,并保持强一致;
- 可用性(Availability):系统(非失败节点)能在有限时间内完成对操作请求的应答;
- 分区容忍性(Partition):系统中的网络可能发生分区故障(成为多个子网,甚至出现节点上线和下线),即节点之间的通信无法保障。而网络故障不应该影响到系统正常服务。
CAP 原理认为,分布式系统最多只能保证三项特性中的两项特性。
比较直观地理解,当网络可能出现分区时候,系统是无法同时保证一致性和可用性的。要么,节点收到请求后因为没有得到其它节点的确认而不应答(牺牲可用性),要么节点只能应答非一致的结果(牺牲一致性)。
由于大部分时候网络被认为是可靠的,因此系统可以提供一致可靠的服务;当网络不可靠时,系统要么牺牲掉一致性(多数场景下),要么牺牲掉可用性。
注意:网络分区是可能存在的,出现分区情况后很可能会导致发生“脑裂”现象。
应用场景
既然 CAP 三种特性不可同时得到保障,则设计系统时候必然要弱化对某个特性的支持。
弱化一致性
对结果一致性不敏感的应用,可以允许在新版本上线后过一段时间才最终更新成功,期间不保证一致性。
例如网站静态页面内容、实时性较弱的查询类数据库等,简单分布式同步协议如 Gossip,以及 CouchDB、Cassandra 数据库等,都为此设计。
弱化可用性
对结果一致性很敏感的应用,例如银行取款机,当系统故障时候会拒绝服务。MongoDB、Redis、MapReduce 等为此设计。
Paxos、Raft 等共识算法,主要处理这种情况。在 Paxos 类算法中,可能存在着无法提供可用结果的情形,同时允许少数节点离线。
弱化分区容忍性
现实中,网络分区出现概率较小,但很难完全避免。
两阶段的提交算法,某些关系型数据库以及 ZooKeeper 主要考虑了这种设计。
实践中,网络可以通过双通道等机制增强可靠性,实现高稳定的网络通信。