CAP定理-wiki

Evan_L

已于 2022-11-06 22:49:25 修改

阅读量194

点赞数

分类专栏：分布式系统理论文章标签： java 分布式

于 2022-11-05 23:37:11 首次发布

原文链接：https://en.wikipedia.org/wiki/CAP_theorem

版权

分布式系统理论专栏收录该内容

2 篇文章

订阅专栏

前言

当我第一次看到Wiki百科关于CAP定理时，感觉有些原来的疑惑忽然豁然开朗。它甚至引用提出CAP定理的教授大佬的原话，点明可能导致误解的地方。同时，我对比过百度百科的解释，确实不太一样。
本文章为Wiki百科的翻译，可能受限于译者水平，希望各位指出有关错误之处。

CAP定理

在理论计算机科学中，CAP定理，也以计算机科学家埃里克·布鲁尔的名字命名布鲁尔定理，它声明任何分布式数据存储只能提供以下三种保证中的两种：
一致性Consistency

每次读都能接收到最近的写入（结果）或者一个错误。【站在分布式系统服务的角度，描述服务的对于并发操作的正确性条件】

可用性Availability

每个请求都接收到一个（非错误的）响应，不保证它包含最近的写入（结果）

分区容错性Partition Tolerance

在任意数量的消息由于节点间的网络发生丢失（或延迟）时，系统依然可以运作。
当发生网路分区故障时，系统必须决定选择以下其中一种策略应对：

取消操作，牺牲可用性保证一致性
继续完成操作，提供可用性但由此带来不一致的风险.

所以，如果发生网路分区，将不得不在一致性和可用性之间选择其一。注意，在CAP定理中的定义的一致性与ACID数据事务保证的一致性是十分不一样的。
Eric Brewer争辩说，常用的“三选二”概念可能会引起一些误解，因为系统设计者只需要在发生（网路）分区时，选择牺牲一致性或者可用性。而这在许多系统中，分区都是极少发生的。

阐释：

对于网络故障而言，分布式系统都是不安全的。因此，网络分区是不得不容忍的。在发生分区时，我们只能二选一：一致性还是可用性。当选择一致性而不是可用性时，如果一个特定的信息由于网络分区故障，无法保证时最新的，那么系统必然会返回一个错误或者超时。但选择可用性而不是一致性，系统总是会处理查询，并且尝试返回最近的可用版本的信息，即便由于网络分区它无法保证该信息时最新的。
当不存在分区时，可以同时满足可用性和一致性。
数据库系统传统的ACID保证设计例如RDBMS（关系型数据库管理系统）考虑的是一致性而不是可用性。而围绕着BASE理论设计的系统，常见于NoSQL运动，选择的是可用性而不是一致性。

历史

根据加利福尼亚的伯克利大学的计算机科学家Eric Brewer（布鲁尔），该定理首次出现与1998年秋天。于1991年，作为CAP原理发表，并在2000年的在分布式计算研讨会上作为布鲁尔的猜想提出。在2002年麻省理工的Seth Gilbert和Nancy Lynch发表了布鲁尔惨笑的正式证明，十七成为一个定理。
在2012年，布鲁尔阐明了他的立场，包括：为什么常用的“三选二”概念可能会引起一些误解，因为系统设计者只需要在发生（网路）分区时，选择牺牲一致性或者可用性；存在分区管理和恢复技术。布鲁尔也注意到先对于ACID中对于一致性的定义，在CAP定理中的一致性的定义是不一样的。
一个相似的定理被Birman和Friedmand于1996年发布：分布式系统中的一致性和可用性的权衡。Birman and Friedman将结果将下界限制在非通勤操作（non-commuting operations）。
PACELC定理与2010年被引入，在CAP的基础上声明：即使在不存在分区的情况下，也需要延迟和一致性之间进行权衡。PACELC意思是：当分区（P）发生，需要在可用性（A）一致性（C）之间进行权衡；如果（E：else）不存在分区，则需要在延迟和一致性之间进行权衡。
区块链技术（Blockchain technology）经常牺牲即时可用性换取可用性是和分区容错性。通过要求特定数量的“确认”，区块链共识算法基本上是减少到最终一致性。