CAP 原理

CAP 原理最早由 Eric Brewer 在 2000 年,ACM 组织的一个研讨会上提出猜想,后来 Lynch 等人进行了证明。

该原理被认为是分布式系统领域的重要原理。

定义

分布式计算系统不可能同时确保一致性(Consistency)、可用性(Availablity)和分区容忍性(Partition),设计中往往需要弱化对某个特性的保证。

  • 一致性(Consistency):任何操作应该都是原子的,发生在后面的事件能看到前面事件发生导致的结果,注意这里指的是强一致性;
  • 可用性(Availablity):在有限时间内,任何非失败节点都能应答请求;
  • 分区容忍性(Partition):网络可能发生分区,即节点之间的通信不可保障。

比较直观地理解,当网络可能出现分区时候,系统是无法同时保证一致性和可用性的。要么,节点收到请求后因为没有得到其他人的确认就不应答,要么节点只能应答非一致的结果。

好在大部分时候网络被认为是可靠的,因此系统可以提供一致可靠的服务;当网络不可靠时,系统要么牺牲掉一致性(大部分时候都是如此),要么牺牲掉可用性。

应用场景

既然 CAP 不可同时满足,则设计系统时候必然要弱化对某个特性的支持。

弱化一致性

对结果一致性不敏感的应用,可以允许在新版本上线后过一段时间才更新成功,期间不保证一致性。

例如网站静态页面内容、实时性较弱的查询类数据库等,CouchDB、Cassandra 等为此设计。

弱化可用性

对结果一致性很敏感的应用,例如银行取款机,当系统故障时候会拒绝服务。MongoDB、Redis 等为此设计。

Paxos、Raft 等算法,主要处理这种情况。

弱化分区容忍性

现实中,网络分区出现概率减小,但较难避免。某些关系型数据库、ZooKeeper 即为此设计。

实践中,网络通过双通道等机制增强可靠性,达到高稳定的网络通信。