首先我们再来明确一下CAP里的A的标准（非常高的标准）
For a distributed system to be continuously available, every request received by a non-failing node in the system must result in a response.
这个标准可能和我们平时用的可用性是不一样的。比如你肯定会听说有这样一个概念，5个9可用。这里的可用性是关于“time system available” 除以 “total time”
所以定义上有很大的不同。CAP里的可用性不是being available的意思。而且主要讨论当系统处于网络分区情况下的该有的行为。
但是，我们还是可以用CAP里的A的术语，来定义高可用和部分可用
High-Availability: “Every request received by a subset of the non-failing nodes in the system must result in a response.”
Partial-Availability: “Some requests received by a subset of the non-failing nodes in the system must result in a response.”
Non-Availability: All requests fail.
区别在于，高可用允许有些没挂掉的节点不给出响应。但是所有请求总有一部分节点是肯定能给出响应的。（如共识系统zookeeper）
部分可用就是允许有一些请求，所有节点都无法给出响应,有一些会有一部分节点肯定可以给出响应。
基于前面2节，系统可以划分到4类。
CP: Consistent, but not CAP-Available.
AP: CAP-Available, but not Consistent.
CA: Consistent and CAP-Available, but not partition-tolerant. This specifies an operating range, so the overlap between CA and CP is not a real issue.
non-CA: Not Consistent and Not CAP-Available. For systems that are neither consistent nor CAP-Available
现在我们对一些系统做分类，▲意味着是网络分区下的典型，绝大多数的表现，△意味着网络分区下的有可能的一些表现
上图第一行是 一个WEB应用连接一个SQL DB 是一个CA系统，基本是完全不可用的当发生网络分区时。
Typical CP big data system 是一个CP的系统。典型的情况是网络分区下是高可用，有一些是部分可用或完全不可用。
下面我们来逐行分析
Single web-server with a single database
这个系统可以宣称自己是CP或者CA（我无法处理partition的情况）都可以。
说CP对市场营销是有好处的：虽然在有分区的情况下系统无法正常工作，但它被标记为“耐分区”。 直到有一个分区，最终用户发现CP的真正含义
说CA强调了网络分区是系统的实际问题，应该特别注意网络。 从软件工程的角度来看，这似乎是最好的类别。
Single web-server with an eventually consistent database
之前分析过了是 non-CA的，意思是这个系统不是强一致，在网络分区下，不可用。
Multiple databases and the two-phase commit
这个系统上述的2PC是带逃生窗口的2PC，可以被划分到下述2类。
- non-CA (behavior when partitioned)
- CA (specifies that it does not handle partition).
所以CA是最好的选择。两阶段提交不仅放弃一致性（有逃生窗口），而且还放弃其他关键属性（ACID原子性）。
两阶段提交仅针对网络分区启动时正在进行的事务放弃ACID原子性，但是对于所有其他情况将选择一致性高于可用性。
同时他是部分可用的，因为之后的请求涉及到的节点在一个网络分区就可用。如果在不同的分区就不可用。所有无法找到一个子集可以满足任意请求，只能是部分可用。
Distributed Consensus
CP系统，上一章已经分析过了。同时是高可用的，只要在多数的那个分区里，可以响应任意请求。
A CP Big Data store
这是一个有很多种可用性的类型。CP大数据存储对于某些分区可能是高度可用的，但并非对每个分区都可用。 某些分区至少有部分可用性
这或多或少是直观的：数据量很大，因此无法容纳所有可能的分区。 然后，根据网络分区，我们可以找到：
一个分区具有所有数据的副本：这是高可用性。
没有一个分区具有所有数据的副本，并且使用大数据存储的应用程序无法应对这种情况。 整个系统不可用。
没有一个分区具有所有数据的副本，但是应用程序可以处理丢失的数据。 那是部分可用性。 这取决于应用程序，因为应用程序必须显式管理这种情况。 他们中的大多数将无法应付这种情况。
为了说明所有这些，让我们来看一个实际的实现。 下面数学中的逻辑是使用最乐观的计算：在大多数实际情况下，实际可用性会更糟。
HDFS，Hadoop分布式文件系统。 HDFS是一个CP大数据系统：如果将系统分为两个分区，则只有一个分区将继续为查询提供服务。
其特点是：
- 数据分为128Mb的块。
- 块被同步复制到3个节点。
- 1份放入一个机架，2份转移到另一个。
所有这些都是可配置的，但是此处提到的值是常用的。 假设我们有10个机架，在复制整个集群之前有200 Tb的数据。 也就是说，每个HDFS块有160万块，每块128 Mb。
如果机架级别有网络分区怎么办？
将有两个分区：一个分区具有1至9的机架，另一个分区具有10的机架。有了这样的分区，前9个机架可以继续满足所有请求：通过构造，它们具有所有数据，就像将所有块写入机架一样 10个也被复制到另一个机架中。 但是，机架10中的客户端无法将请求发送到这9个机架，因此该系统总体上是高度可用的，但没有CAP可用。（因为要求所有请求到任意一个没有挂掉的节点都可用，显然机架10不符合要求）
请注意，即使机架10具有所有数据，机架10中的客户端仍将无法在本地执行任何工作：CP系统不能使两个分区（CAP）并行运行。（这样会违反一致性，因为数据必须同步复制出去）
如果我们有一个网络分区，每个分区中有50％的机架怎么办？
为了高度可用，该分区至少需要每个块一个副本。 现在，如果我们只有50％的机架，那么拥有至少一份数据副本的概率是多少？ 为了进行计算，我们简化一下，说每个块都复制在3个不同的机架上。 因此，将所有副本放在另一个分区中的概率为：
初版：10个中有5个坏机架
第二份副本：9个中有4个坏机架
第三副本：8个坏机架中的3个
这样，我们得到一个块：（5/10）（4/9）（3/8），即8％。 因此，对于单个块，我们在主分区中至少有一个副本的可能性约为92％。 很好，但是我们有160万个区块。 所有块中至少有一个副本的概率为92%。 160万个块，实际上为零。 从CAP分类的角度来看，这并没有任何改变：它仍然是CP，因为CP允许我们在任何节点上的某些请求失败。 但是该系统不再具有高可用性。
An Eventually Consistent Big Data Store
首先最终一致不是强一致的，其次他不是CAP的可用。在大多数这样的系统里它可以保持高可用
大多数网络分区将导致一个有足够数据的分区与另一个没有足够数据的分区之间的分裂。 对于这些分区，系统作为存储是高度可用的，但对于CAP不可用：第二个分区无法处理所有请求（如果有）。
如果配置了数据中心之间的复制，则对于数据中心之间的分区（仅对此分区），系统将是CAP级别的可用。(因为任意请求在任意机器上都可以得到响应，因为数据中心包含了所有数据）
An Eventually Consistent AP system
虽然不可能使“最终一致的大数据系统”成为AP，但也很难使任何最终一致的系统都属于该类别。 这是因为AP系统必须
- 在所有分区中拥有所有数据；
-
在网络分区期间继续支持写操作，并且在所有分区中都支持写操作。
AP systems are rare, but they do exist
这对于配置服务等是可能的。 从其文档来看，Netflix的Eureka似乎已接近现实生活中的AP系统。 由于它是服务发现组件，因此数据量很小，可以放在任何节点上。 此外，它们还会发生本地写入然后解决冲突：服务注册上的冲突很容易合并，因此服务可以非常可靠。 CouchDB是一个更通用的数据库，也属于此类别（免责声明：我自己并未使用这些系统）。
但是，即使在技术上可以构建最终一致的AP系统时，某些应用程序仍可能具有安全约束，这将使断网的操作变得困难。 对于今天的某些业务应用程序，有一些关于“限时访问”的要求，这些要求可以在几分钟内制定。 访问权限和身份验证应用程序是愿意选择“可用性”而不是“一致性”的应用程序的典型示例，但是它们也受到这些“限时访问”要求的限制。
总结
市场营销中使用的CAP分类与CAP定理的实质无关。大部分将自己描述为CP的系统并非全部都不具有分区容错性，并且大多数声称是AP的系统也不是全部可用。以下是一些简要介绍：
CAP可以用于任何分布式系统，但是需要具体问题具体分析。例如，选择CA在LAN上比在WAN上更有意义。
可用性不仅限于CAP可用性。许多现实生活中的应用程序都针对高可用性和部分可用性。
想要传达网络分区是一个严重问题的分布式系统应使用CA（并附有有关实际问题的文档）。
不存在最终一致的AP大数据存储数据库。
埃里克·布鲁尔（Eric Brewer）在2012年的论文C3].中已经提到了这里提出的许多观点。 在2000年的演讲C1,
中，他已经研究了部分可用数据的细节。
而且，Daniel Abadi在[C8中已经指出：“我对CAP的主要问题是，它将CAP集中在所有人身上，这是使每个人都专注于一致性/可用性之间的权衡，从而导致人们认为NoSQL系统放弃一致性的原因是为了获得可用性。 但是，实际上，大多数放弃一致性的应用最终并没有获得更多的可用性。