CAP 定理是分布式系统中的一个基本定理，由加州大学伯克利分校的计算机科学家 Eric Brewer 教授提出，CAP 定理指出任何分布式系统最多可以满足以下三个指标中的两个。
Consistency
Availability
Partition Tolerance
本文主要介绍 CAP 定理的含义及其应用。掌握CAP定理可以帮助我们对系统设计中目标进行取舍，合理规划系统拆分的维度。
分布式系统的特点
为了解决集中式架构的性能瓶颈问题，使系统能够支持高并发访问和处理海量数据，我们将分布在不同地理位置的、建立在网络之上的、彼此之间通过消息等方式进行通信和协调的软件系统组成分布式系统对外提供服务。
分布式系统的核心是可扩展性，通过对服务、存储的扩展，来提高系统的处理能力。此外，分布式系统还有不出现单点故障、服务或者存储无状态等特点。
单点故障（single point failure）：系统中某个组件停止服务，会导致整个系统停止服务。单点不影响整体，是分布式系统的设计目标之一。
无状态：无状态的服务才能保证部分机器宕机不会影响整个系统，并且满足随时进行扩展的需求。
分布式系统在提高系统的处理能力的同时，也带来了新的问题，如系统中节点之间通信失败、网络分区故障、多个副本的数据不一致等。为了更好的设计分布式系统，学者们提出了一系列理论，其中具有代表性的就是 CAP 定理。
Consistency
Consistency 中文直译过来是 “一致性”。意思是，所有节点同时看到相同的数据，即写操作成功之后，所有节点在同一时间的数据完全一致，等同于所有节点拥有数据的最新版本，此时进行读操作，必须返回最新写入的数据。
any read operation that begins after a write operation completes must return that value, or the result of a later write operation. - Gilbert and Lynch
举个例子，Client 向 Server 1 发送写操作指令，将 v0 更新为 v1。
然后，Client 向 Server 1 发送的读操作就会得到 v1，这就叫一致性。
但是，Client 可能向 Server 2 发起读操作，由于 Server 2 的值没有发生变化，因此返回的是 v0。Server 1 和 Server 2的读操作结果不一致，不满足一致性。
一致性可以分为以下三类：
强一致性：要求更新过的数据能被后续的访问看到。
弱一致性：容忍更新过的数据对于后续的访问部分不可见或全部不可见。
最终一致性：经过一段时间后要求访问到更新后的数据。
Availability
Availability 中文直译为 “可用性”。意思是，任何时候，读写都是成功的。即只要收到客户端请求，服务器必须给出回应，并且是正常响应时间。
every request received by a non-failing node in the system must result in a response. - Gilbert and Lynch
如果系统每运行100个时间单位，会有1个时间单位无法提供服务，则说系统的可用性是99%，这是对可用性的一种描述，叫做服务水平协议（SLA）。举个例子，比如月度99.95%的SLA，则每个月服务出现故障的时间占总时间的0.05%，如果这个月是30天，那么就是21.6分钟。
可用性 和 可靠性 是两个比较容易搞混的指标，以一台取款机为例：
正确的输入，能够取到正确的钱，表示系统可靠。
取款机7*24小时提供服务，表示系统可用。
Partition tolerance
Partition tolerance 中文直译为 “分区容错”。意思是，分布在多个子网络（每个子网络就叫做一个 partition）的节点可能因为分区故障导致彼此无法通信。
the network will be allowed to lose arbitrarily many messages sent from one node to another. - Gilbert and Lynch
举个例子，Server 1 和 Server 2 是两台跨区的服务器，Server 1 向 Server 2 通过网络发送一条消息，Server 2 可能无法收到。当发生节点之间无法通信时，数据是否还能保持一致，系统要如何进行容错处理，是系统设计时需要考虑的。
一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。
Consistency 和 Availability 的矛盾
因为节点之间可能通信失败（即出现分区容错），所以一致性和可用性不可能同时成立。
如果保证 Server 2 的一致性，那么 Server 1 必须在写操作时，锁定 Server 2 的读操作和写操作，只有数据同步后，才能对 Server 2 进行读写操作。锁定期间，Server 2 不能读写，降低了系统的可用性。
如果保证 Server 2 的可用性，那么势必不能锁定 Server 2，所以一致性不成立。
综上所述，在分布式系统中，无法同时满足 CAP 定理中的 “一致性” 和 “可用性”。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。分布式系统所关注的，就是在 Partition tolerance 的前提下，如何实现更好的 Availability 和更稳定的 Consistency。CAP 的应用模型就是 CP 架构和 AP 架构。
CP 架构和 AP 架构的取舍
在分布式系统中，通常为了保证数据的高可用，会将数据保留多个副本（Replica），网络分区是既成的事实，于是只能在一致性和可用性二者之间做出选择。CAP定理关注的是在绝对情况下，但是在工程实践中，保证强一致性通常对系统的并发性能，以及高可用有较大影响，因此可用性和一致性并不是完全对立的，更多的是保证“最终一致性”，提高系统的可用性。最终一致性即短期内未必读到最新的数据，但在一个可接受的时间窗口之后，能够读到最新的数据。
业务上的对一致性的要求会直接反映在系统设计中，典型的就是 CP 和 AP 架构。
CP 架构：放弃可用性，追求一致性和分区容错性。
ZooKeeper就是采用了 CP 架构，在CAP模型中，ZooKeeper面对网络分区时，为了保持一致性，它是不可用的。其核心算法是 Zab，所有设计都是为了一致性。
AP 架构：放弃强一致性，追求可用性和分区容错性。Base 理论就是根据AP来扩展的。
Eureka就是采用了 AP 架构，Eureka 集群的各个节点都是平等的，几个节点挂掉不影响正常节点的工作，剩余的节点依然可以提供注册和查询服务，只要有一个 Eureka 节点还在，就能保证注册服务可用，只不过查到的信息可能不是最新的版本，不保证一致性。
