CAP

以下来自 分布式的 CAP 定理和一致性模型 | 春水煎茶 (writings.sh) 对于一个数据存储系统，它具有以下美好的性质： 可用性 ： 收到请求总会响应 。 一致性 ： 两次读请求，总会返回一致的结果。 在单节点系统中，达到这两条性质并不难 然而，单节点系统有以下问题： 服务能力有限。 单点风险： 一旦这个节点故障，整个系统将不可用。 我们可以使用主从结构，从节点不提供服务，只作为数据备份 网络分区发生的时候，无论 同步还是异步的方式，如果不放弃可用性，都不能保证一致性。 CAP 定理 经过前面的一番讨论之后，所谓「CAP 定理」已经呼之欲出了。 CAP 定理又叫做布鲁斯定理, 该定理源于埃里克·布鲁尔在2000年的分布式计算原理研讨会上提出的一个猜想， 在2002年麻省理工学院的Gilbert和Lynch发表了证明[1]，使之成为一个定理： 这就是所谓「CAP」的名字由来，我们只能在 C,A,P 中三个性质中选两个。 这个定理也可以表达为： 在网络分区发生的情况下，分布式系统不能同时保证一致性和可用性。 除非是单节点系统， 否则无法同时保证 CA 这个结论在分布式领域已经耳熟能详， 不过， 关于 CAP 定理，需要特别注意搞清楚以下两点： CAP 定理范畴下的一致性、可用性、分区的概念都是 非常狭义的 。 CAP 所说的 一致性其实是 线性一致性。 CAP 所说的 可用性其实是非常高的可用性。 **分区现象在现实网络中不可避免，**也就是说， 现实中我们只能在 C和 A中做选择 。 CAP 其实在说 强一致性和高可用性，二者择其一 。 在前面的讨论中，我们曾多次提到「分区现象」， 正是这个问题导致我们无法同时具备一致性和可用性上。 要了解分区容忍性，就要先了解什么是分区现象。 当两个节点之间的网络不再连通，相当于分成了几块分区，所以叫做分区现象。 分区所强调的是 节点间的不连通问题，即使每个节点都可以工作 。 简单来说，Partition != Crash。 节点故障一般会造成节点的无响应，导致分区出现， 但是分区的出现不一定代表节点真的故障（宕机）了。 现实中的分布式网络，丢包、延迟、中断都是存在的， 所以在实际的系统设计中，分区容忍性是必选的。 也就是说，我们只能在可用性和一致性这两个性质中做选择。 先用最直观地方式理解下其含义： Availability = Reads and writes always succeed. 可用性并没有要求读到的数据的正确性，只描述了系统可以总可以非错的工作的能力。 也就是说，在 CAP 的范畴下，如果一个系统没有做好故障转移的逻辑， 那么这个系统不具备可用性。 CAP 定理中的可用性的定义，可以说很强，也可以说很弱： 很强，是因为要求必须响应 100% 的请求。 很弱，是因为并没有要求响应的时限，只需要最终返回。 而通常我们对系统的响应时限是有要求的， 所以说 CAP 定理中的可用性的条件很强， 在 CAP 的理论范畴下，没有「可用性的强弱程度」一说。 综合看来， CAP 定理中对可用性的定义是狭义的。 在实际中，可用性却不是一个非黑即白的简单判定， 和工程上对一致性的概念类似，存在不同可用性高低之分的说法。 我们常说的高可用性 high availability， 一般是指部分节点损失后整个系统仍可以正常工作。 要达成高可用性，就必须做好故障转移。 所以我们也可以说， CAP 定理中的可用性其实是我们所说的高可用性，而且是最高的可用性 。 简单直观地理解是： 分布式系统中多个节点的数据返回始终一致的性质。 Consistency = two reads return the same value. 所有节点在同一时刻的看到的数据是一样的。 CAP 定理中的一致性，要求所有节点都可以看到最新修改的数据。 其实这个要求是非常强的， 我们接下来会讨论一致性的模型， CAP 中的 C 就是强一致性中的线性一致性 。 一致性的分类 实际中，一致性也不是非黑即白的性质， 而是有强弱之分。 人们对一致性的研究和实践中， 按照强弱程度建立了一致性模型。 一致性按强弱程度可以分为三类： After a write, reads may or may not see it. 向系统写入一个值后，后续的读操作可能读出来，也可能读不出来。 After a write, reads will eventually see it. 向系统写入一个值后，后续立刻的读操作可能读不出来，但是 在某个时间段后，读取一定成功 。 例如，读写分离的关系型数据库。 After a write, reads will always see it. 向系统写入一个值后，后续任意时刻的读取一定成功。 在实际的分布式系统设计中，我们无法同时达成强一致性和高可用性。 CAP 定理是我们在设计一个分布式系统之初时的一个有益参考， 它让我们在设计系统的时候不必浪费时间去寻求理论上都达不成的目标。 CAP 范畴下的一致性和可用性的定义其实是非常狭义的、非常精确的， 它所讨论的是非常极限的情况， CAP 只否定了我们没办法同时达成最强的一致性和最高的可用性。 选择 C 多一些的情况 为了实现更强的一致性，这个系统可能会在某些情况下拒绝服务、甚至直接关闭节点。 实例中，比较偏好 C 的有 Zookeeper，Hbase，MongoDB 等。 选择 A 多一些的情况 为了实现更高的可用性，这个系统必须做好故障转移，尽可能地响应所有请求，但是有可能返回不一致的结果。 实例中，比较偏好A的是有D ynamo，CouchDB，Riak，Cassandra 等。 没有绝对的选择和放弃，只有更偏好哪个和弱化哪个的说法。