CAP - 分布式系统的三个指标

CAP 是以下三个单词的首字母拼成,

Consistency (一致性)
Availability (可用性)
Partition tolerance (分区容错性)

由加州大学 Eric Brewer 提出, 并且给出 CAP 三个指标不可能同时做到的猜想. 也称为 CAP 定理

Consistency 一致性

一致性指 在所有节点访问能访问到同一份最新的数据副本, 这个很好理解, 例如在 数据库分库后, 我们需要保证读库和写库的数据一致性.

在并发读写时非常容易出现一致性问题, 所以在考虑一致性问题是, 要注意结合并发读写的场景.

通常有三种一致性策略

  • 对于关系型数据库, 要求更新过的数据能被后续的访问都看到, 这是 强一致性
  • 如果能容忍后续的 一部分 或者 全部 访问不到, 则是 弱一致性
  • 如果经过一段时间后 要求能访问到更新后的数据, 则是 最终一致性

CAP 中的 一致性 指的是 强一致性

Availability 可用性

可用性也就是说 这个节点 或者 服务 是一直可以正常响应请求的. 这和 利用多副本实现无状态节点的高可用 中的 可用 是相同的意思.

通常通过 停机时间 来衡量一个系统的可用性.

可用性分类 可用水平 年可容忍停机时间
容错可用性 99.9999 <1 min
极高可用性 99.999 <5 min
具有故障自动恢复能力的可用性 99.99 <53 min
高可用性 99.9 <8.8 h
商品可用性 99 <43.8 h

计算停机时间的公式如下 (1- 可用水平百分数)*365*24*60 得到 全年可容忍的停机时间 分钟数

Partition Tolerance (分区容忍度)

对于 Partition Tolerance , 通常有些文献中被翻译成 分区容错性 , 个人觉得这样容易产生歧义, 更贴切的翻译个人认为是 分区容忍性

以下来自 邬江 - CAP 理论中的 P 到底是个什么意思? 的回答 - 知乎

一个分布式系统里面,节点组成的网络本来应该是连通的。然而可能因为一些故障,使得有些节点之间不连通了,整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。

当你一个数据项只在一个节点中保存,那么分区出现后,和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。

提高分区容忍性的办法就是一个数据项复制到多个节点上,那么出现分区之后,这一数据项就可能分布到各个区里。容忍性就提高了。

然而,要把数据复制到多个节点,就会带来一致性的问题,就是多个节点上面的数据可能是不一致的。要保证一致,每次写操作就都要等待全部节点写成功,而这等待又会带来可用性的问题。

总的来说就是,数据存在的节点越多,分区容忍性越高,但要复制更新的数据就越多,一致性就越难保证。为了保证一致性,更新所有节点数据所需要的时间就越长,可用性就会降低。

为何 C/A/P 三者中会出现 "三选二" 的情况

想象一种这样一种情况, 在两个可用区 A,B 中, 分别有服务器 AS1,BS1 和数据库 AD1 和 BD1, 同时, AD1和BD1两台数据库之间做了数据同步, 这样就变成了一个标准的双可用区部署. 此时, 客户端无论是从 AS1上访问还是从 BS1 上访问和操作, 都可以得到同样的结果.


 用户访问                用户访问
   v                       v
|-----|                 |-----|
| AS1 (服务器)           | BS1 (服务器)
|     |                 |     |
|     |                 |     |
| AD1 (数据库) <= 同步 => | BD1 (数据库)
|-----|                 |-----|

但是当同步中断时,也就是我们的一整个集群被网络故障切割成了两个, 在 C 和 A 我们将只能选择保证其一

  • 当 BD1 有数据写入时, 因为中间的同步已经断开, 那么为了保证数据的一致性, 我们只有牺牲可用性, 等到网络故障恢复后, 再提供服务
  • 假设在上面的情况下我们选择为了保证服务可用性, 而牺牲数据的一致性, 我们会响应旧的数据给用户

所以这样就得出结论, 在需要容忍分区割裂的分布式系统中, 只能在数据一致性和服务可用性间二选一. 再根据业务特点进行妥协和优化

CAP 权衡

AP without C

做到服务的高可用并容忍被网络分区的话, 我们需放弃一致性, 使用这种案例的场景很多, 例如 在高并发场景下, 一旦 数据库宕机 或者 数据库负载过高处理过慢 或者 调用链路中的某一环挂掉, 那么就形成了 P 的状态, 此时我们仍需继续处理请求并等待服务恢复, 常见的案例有 12306 的购票, 以及 双十一淘宝

CP without A

CA without P

What's Next

ref: >

  1. hollis - 分布式系统的 CAP 理论 (通俗易懂, 推荐)
  2. 邬江 - CAP 理论中的 P 到底是个什么意思? 的回答 - 知乎
  3. wiki-CAP
  4. infoQ-CAP 理论十二年回顾:"规则"变了
Copyright © Haoyu LIN 2017-2018 all right reserved,powered by Gitbook该文件修订时间: 2019-09-28 17:31:35

results matching ""

    No results matching ""