CAP定理

 

1、解释说明 ：C（Consistency即“一致性” ）；A（ Availability“可用性” ,指的是快速获取数据)）；P （Partition-tolerance“ 分区容忍性”, 指的是分布式）。

2、理论结论： CAP理论告诉我们，一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。

3、 Consistency到底是什么？

一个服务是一致的完整操作或完全不操作（A service that is consistent operates fully or not at all，精确起见列出原文，也有人将其简称为数据一致性）。Gilbert 和Lynch在他们的证明中使用“atomic”而不是consistent，技术上来讲更准确，因为严格来说，当用在数据库事务的属性中 时，consistent是指ACID 中的C，其含 义是如果数据违反了某些预设的约束（preset constraints）就不能被持久化（persisted）。但如果你将其认为是分布式系统中的一个预设约束：不允许同一数据有不同的值，那么我认为 这个抽象概念的漏洞就被堵住了（而且，如果Brewer使用atomic这个词，就会被称为AAP定理，那每次我们读它的时候都会被送进医院）（注：我估 计是有口吃加白痴的嫌疑）。在前面购书的例子中，你将书加入购物车或无法加入。支付成功或不成功。你无法部分加入或部分支付一本书。库存中只有一本书，当 天只有一个人能得到它。如果2个客户都可以完成订单流程（如完成支付），那么仓库中的和系统中的不一致性就会导致问题。在这个例子中也许并不是个大问题： 某个人在假期中会很无聊或摆弄防晒霜，但如果将其扩大到数千个不一致性，并且涉及到金钱（例如：金融交易中关于买卖的东西和交易记录的内容不一致）就会是 个大问题。也许我们可以利用数据库来解决一致性问题。在（购书的）订单流程中的某个点减少《战争与和平》的库存记录。当其他的客户到达这个点的时候，书架 空了，订单流程将会通知客户，而不会进行到支付环节。这样第一个操作顺利完成，第二个操作则不会完成。数据库非常适合这种情况，因为数据库关注ACID属 性，并且通过隔离性（Isolation）来保证一致性，这样当第一个客户会使得库存记录减1，同时购物车的记录加1，任何中间状态同第二个客户都是隔离 的，当然第二个客户必须等待几百毫秒以便数据存储达到一致状态。

 

4、 Availability到底是什么？ 
可用性只是意味着服务是可用的（可以完成如上的操作或不完成）。当你购书时期望得到反馈，而不是浏览器报告网站无法连接的信息。Gilbert 和Lynch在其CAP定理的证明中很好地指出了，可用性通常在你最需要的时刻背弃你。网站通常在业务最繁忙的时刻挂掉，因为网站压力最大。一个他人无法 访问的服务对任何人都没有价值。

 

5、 Partition Tolerance 到底是什么？ 
如果你的应用和数据库运行在一个机器上（忽略规模的问题并假定你的代码都没问题），你的服务器是作为一种原子处理单元（atomic processor）：要么工作要么不工作（例如：如果down机就不可用，但也不会造成数据不一致问题）

一旦开始将数据和逻辑分布在不同的节点上，就有形成partition的风险。假定网线被切断，partition就形成了，节点A无法和节点B通讯。由 于Web提供的这种分布式能力，临时的partition是一个常见的情况，如之前说所的，在全球化的有多个数据中心的公司中这并不罕见。

 

Gilbert 和Lynch是这样定义partition tolerance的

除了整个网络的故障外，其他的故障（集）都不能导致整个系统无法正确响应。(No set of failures less than total network failure is allowed to cause the system to respond incorrectly)

请注意Brewer的注释，单节点partition就等同于服务器crash，因为如果无法连接它，那它就和不存在一样。

 

6、定理的重要性

CAP定理在应用系统规模化时最有效。在低压力的情况下，小的延迟（以便数据库达到一致的状态）还不足以对总体的性能或用户体验造成影响。你所承担的负载分布，可能都是出于系统管理的原因。？

但随着活动的增加，吞吐量的上限（pinch-points）将会限制增长并产生错误。必须等待网页的返回是一种情况，另一种情况则是在你输入信用 卡信息后遇到 “HTTP 500 java.lang.schrodinger.purchasingerror”，你就想知道你是否付了钱但无法得到东西，还是没付钱，或者这只是交易中 一个不重要的错误。谁知道呢？你不太可能继续下去，很有可能到别的地方购物，或更有可能给银行打电话。

不管是那种情况对业务都没有好处。Amazon声称 每0.1秒的响应延迟都会导致1％的销售降低。Google说 他们注意到0.5秒的延迟会使流量减少20%。

我之前 曾 就scalability写过一些东西，不想在这里重复，只想指出2点：第一点是，解决scale问题看起来是一个架构方面的问题，但最初的讨论却不是， 而是业务决策。我已经很厌倦听到技术人员说，因为当前的流量，这样或那样的方案不能用。并不是说技术人员错了，通常他们讲的非常正确，是由于从一开始所限 定的scale 隐含地做了revenue决策－这一问题应该在业务分析时明确地决定下来。

第二点是，一旦你开始讨论如何scale业务系统，大致会落到2种意识形态阵营中：数据库派和非数据库派。

对于数据库派来说，毫无疑问，钟爱数据库技术，并倾向于谈论optimistic locking 和sharding 这类的东西来解决scale问题，并将数据库作为系统的核心。

非数据库派会倾向于尽可能多的在数据库环境（避免关系世界）之外管理数据以解决scale问题。

我认为，可以公平地说，前一派人对CAP定理的热情肯定不如后一派（尽管他们在讨论定理 ）。 这是因为，如果你必须在consistency，availability，partition tolerance三者中放弃一个，大多数会选择放弃consistency，而consistency是数据库存在的理由。（选择的）逻辑，无疑，是 availability和partition tolerance能够使你赖以赚钱的系统生存下去，而不一致性感觉好像是你可以用好的设计来解决的问题。

和IT中的其他事情一样，这不是非黑即白的问题。Eric Brewer在其PODC演讲的第13页slide中，当比较ACID和其非正式的对应物的BASE 时，甚至说“我认为这是一个系列（spectrum）”（注：这里光谱有一个系列的含义，是指ACID和BASE是不对立的）。如果你对这个主题感兴趣（有些超出我在这里讨论的范围了），你可以从一篇叫做，“Design and Evaluation of a Continuous Consistency Model for Replicated Service  ”的论文开始，该文由Haifeng Yu和Amin Vahdat 编写。大家不可以将CAP解读为暗示数据库的消亡。

尽管这样，双方都认同scale的解决之道是分布式的并行计算，而不是曾经认为的超级计算机。90年代中期进行的Network of Workstations 项目受到了Eric Brewer的影响，并最终导致了CAP定理的诞生，因为他在一个关于Inktomi and the Internet Bubble  的介绍中说到，答案总是并行处理：

如果不通过并行的方式，你就没有机会，在合适的时间内解决问题。和其他许多事情一样。如果是个很大的项目，会需要很多人来完成它。因此，如果想建造一个桥梁，就需要很多建筑工人。这就是并行处理。因此问题会演变为“如何将并行处理和internet结合在一起”

图片证明

这里有一个简单的图片证明，因为我发现用图片会比较好理解。多数情况下我使用和Gilber 和Lynch相同的术语，以便和他们的论文联系起来。

上图显示了网络中的两个节点N1，N2。他们共享同一数据V（库存中《战争与和平》的数量），其值为V0。N1上有一个算法A，我们可以认为A是安全，无bug，可预测和可靠的。N2上有一个类似的算法B。在这个例子中，A写入V的新值而B读取V的值。

正常情况下（sunny-day scenario），过程如下：(1)A写入新的V值，我们称作v1。(2)N1发送信息给N2，更新V的值。(3)现在B读取的V值将会是V1。

如果网络断开（partions）（意味着从N1无法发送信息到N2）那么在第3步的时候，N2就会包含一个步一致的V值。

希望看上去很明白。即使将其scale到几百个事务（transaction）中，这也会成为一个大问题。如果M是一个异步消息，那么N1无法知道 N2是否收到了消息。即使M是保证能发送的（guaranteed delivery），N1也无法知道是否消息由于partition事件的发生而延迟，或N2上的其他故障而延迟。即使将M作为同步 （synchronous）信息也不能解决问题，因为那将会使得N1上A的写操作和N1到N2的更新事件成为一个原子操作（atomic operation），而这将导致同样的等待问题，该问题我们已经讨论过（或更糟）。Gilbert 和Lynch已经证明，使用其他的变种方式，即使是部分同步模型（每个节点上使用安排好的时钟）也无法保证原子性（atomicity）。

因此，CAP告诉我们，如果想让A和B是高可用（highly available）的（例如，以最小的延迟（latency）提供服务）并且想让所有的N1到Nn（n的值可以是数百甚至是上千）的节点能够冗余网络的 partitions（丢失信息，无法传递信息，硬件无法提供服务，处理失败），那么有时我们就得面临这样的情况：某些节点认为V的值是V0（一本《战争 与和平》的库存）而其他节点会认为V的值是V1（《战争与和平》的库存为0）

我们都希望所有的事情是结构化的，一致的且和谐的，就像70年代早期的prog rock 乐队，但我们面临的是一些punk风格的混乱。事实上，尽管有可能会吓到我们的祖母，但一旦你了解了它就还OK，因为2者可以非常愉快地在一起工作。

让我们从事务（transactional）的角度快速分析一下。

如果我们有个事务（例如：一组围绕着persistent数据项V的工作单元）a，a1是写操作，a2是读操作。在一个local的系统中，可以利 用数据库中的简单锁（simple locking）的机制方便地处理，隔离（isolating）a2中的读操作，直到a1的写成功完成。然而，在分布式的模型中，需要考虑到N1和N2节 点，中间的消息同步也要完成才行。除非我们可以控制a2何时发生，我们永远无法保证a2可以读到a1写入的数据。所有加入控制的方法（阻塞，隔离，中央化 的管理，等等）会要么影响partition tolerance，要么影响a1(A)和a2(B)的可用性。

CAP选择

当处理CAP的问题时，你会有几个选择。最明显的是：

1. 放弃Partition Tolerance 如果你想避免partition问题发生，你就必须要阻止其发 生。一种做法是将所有的东西（与事务相关的）都放到一台机器上。或者放在像rack这类的atomically-failling单元上。无法100%地 保证，因为还是有可能部分失败，但你不太可能碰到由partition问题带来的负面效果。当然，这个选择会严重影响scale限制。
2. 放弃Availability 相对于放弃partition tolerance来说，其反面就是放弃availability。一旦遇到partition 事件，受影响的服务需要等待数据一致，因此在等待期间就无法对外提供服务。在多个节点上控制这一点会相当复杂，而且恢复的节点需要处理逻辑，以便平滑地返 回服务状态。
3. 放弃Consistency 或者如同Werner Vogels所提倡的，接受事情会变得“最终一致 （Eventually Consistent）”（2008年12月更新）。Vogels的文章值得一读。他比我在这里讨论了更多的操作方面的细节。许多的不一致性并不比你想的 需要更多的工作（意味着持续的consistency或许并不是我们所需要的）。在购书的例子中，如果一本库存的书，接到了2个订单，第二个就会成为备份 订单。只要告知客户这种情况（请记住这是一种罕见的情况），也许每个人都会高兴的。
4. 引入（jump）BASE 
   有一种架构的方法（approach）称作BASE（B asically A vailable, S oft-state, E ventually consistent）支持最终一致概念的接受。BASE（注：化学中的含义是碱），如其名字所示，是ACID（注：化学中的含义是酸）的反面，但如果认 为任何架构应该完全基于一种（BASE）或完全基于另一种（ACID），就大错特错了。这一点是需要谨记重点，尤其是这个行业的“一边倒（oooh shiny，注：这个完全意译了）”的习惯性的采用策略。这里，我要遵从Brewer教授自己的观点，他就本文通过email表达了自己的观点 （comment）： 

   如您所指出的，术语BASE第一次出现是在1997年的SOSP文章中。那一年，我和我的学生在他们的办公室中，一起造了 这个词。我承认这有些人为的因素，但ACID也是一样的－－远超人们所能意识到的，所以我们人为还行。Jim Gray和我讨论了这些缩写，他欣然认可ACID也有些扭曲（stretch）– A和D（的概念）有相当多的重复部分，C至多也是含糊不清的。但这对术语暗示了一系列的理念（idea of spectrum），这是PODC演讲中的一个重要观点，你正确地指出了这一点。

   EBay的Dan Pritchett有一篇关于BASE的很棒的介绍  （presentation）。

5. 围绕其进行设计 
   Guy Pardon， atomikos 的CTO写了一篇他称作“CAP解决之道（证实Brewer的错误） ”的文章，提出了一种架构方法，可以达到Consistency, Availability和Partition-tolerance，当然附带了一些说明（显然你不可能在同一时刻满足全部的3个要求）。值得一读，Guy雄辩地表达了（在该领域）相反的观点。

总结

在Consistency, Availability和Partition-tolerance中，你只能保证2点，这是确实的，并且已经被这个星球上最成功的网站证实了。如果对网 站是有效的，我看不出在企业环境中，在日常的工作中，不考虑同样的折衷设计的理由。如果业务方面明确表明不需要上规模（scale）那好，有简单的解决方 案，但这是值得讨论的。在任何情况下，这些讨论都是针对特定操作的适合的设计，而不是庐山（注：shebang取意译）全貌。正如Brewer在其邮件中 所说的：“唯一的我可以加入的是同一服务的不同部分可以选择这一系列（spectrum）中的不同的点”有时，无论scale的代价如何，你绝对需要一致性 ，因为缺少它的风险太大了。

这些天，我说得有些过，说Amazon和EBay没有scalability问题，我认为他们的确有这类问题，但他们现在有办法解决该问题。这也是 为何他们可以自由讨论这些问题的原因。不论他们现在是何规模（结合他们早就公布的数字）只会越来越大。一旦规模上来，你的问题就会转到（shift）诸如 操作维护，监控，发布软件的更新等等 － 当然（这些问题）都很难解决，但值得，尤其当你因此获得现金流（revenue stream）。

参考

1. HP接纳CAP定理，白皮书的标题为“分布式数据没有免费的午餐  ”
2. Sussex大学计算机科学讲义，关于分布式事务 和网络partitions
3. Jens Alfke的关于数据库，scaling和Twitter的好文
4. Pat Helland 的关于分布式事务和SOA的Microsoft论文，叫做数据在外和数据在外  ，他随后将其和CAP理论关联了起来 。
5. 另一套计算机科学方面课程slides  ，这一次是来自Virginia的George Mason大学，是关于分布式软件系统 和CAP定理以及ACID和BASE两大阵营的对比

http://www.infoq.com/cn/articles/cap-twelve-years-later-how-the-rules-have-changed