简明入门讲义——CAP 理论，鱼和熊掌不可兼得

CAP 理论缘起

开发人员常常要将对性能与扩展性的思考体现在代码中
出现性能（Performance）问题，即单个用户请求是缓慢的
出现扩展（Scalability）问题，即单个用户请求是满足要求的，但系统在高负载下处理用户请求是缓慢的。

如果这个服务是可扩展的，则随着系统资源的增加，服务性能是成比例提升的。

随着可扩展服务系统资源的增加（这里指的是横向扩展（Horizontal Scalability）），系统就会开始变得复杂，出现以往单机不需要考虑的问题。

CAP 概述

于是就有了 CAP 理论：在一个分布式系统中，节点彼此连接共享数据，你有且只能使系统保证一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）三个中的两个。

一致性：从任一节点读取返回的都是客户端最近一次的写入结果
可用性：访问任一在线（No-Failing）节点均可以在一定时间范围内得到返回结果，而不会产生超时或其他错误
分区容错性：发生网络分区时，系统依然可以运作

实际上的 CAP

分布式计算的谬误

理论上可以满足 CP, AP, AC。 然而这是在理想的网络状态下。
Sun 公司的 Arnon Rotem Gal Oz 提出分布式计算的谬误（Fallacies of distributed computing），理想的网络是：

1. 网络是可靠的
2. 网络延迟为 0
3. 带宽是无限的
4. 网络是安全的
5. 网络拓扑是不变的
6. 系统只有一个管理员
7. 传输损耗为 0
8. 网络是同构的 (homogeneous)

如果不满足上述的任一条件，那么必须容忍 P，因此实际的 CAP 理论是：在网络分区下，我们只能选择保证一致性或者可用性的一个

现实中的伪 CAP

而在真实的生产环境呢？可能又不一样了！一致性可能退化成了最终一致性，而可用性也只是部分节点可用。

对于一致性，CAP 理论讲的是任一节点都返回最近一次写入结果。而大部分使用共识算法的软件例如 RabbitMQ 的 Quorum Queue 及 Kafka Topic，只要保证多数节点写入成功，即对外允许读取了。包括被外界看做 CP 系统的 Zookeeper 默认也不会在读操作前发送 Sync 命令来保证 CAP 的一致性。对于一些系统而言，延迟更无法忍受。

对于可用性，在网络分区发生时，任一在线的节点不一定能提供服务。例如 RabbitMQ Quorum Queue 的策略是多数节点分区继续工作，少数节点即使已有客户端连接，也会被断开，停止对外提供服务。

Ref

1. Understanding Latency versus Throughput
2. Please stop calling databases CP or AP
3. CAP theorem - Wikipedia

WeChat Official Account: 程序员的碎碎念