转自光头老蒋:http://www.click2earth.com/post/119.html
2000年7月19号，周三，对主流文化来说并不（象前者一样）具有同样的重要性，但这个日子对互联网公司来说，和25年Sex Pistols对音乐所做的一样，具有同样的影响。这就是Eric Brewer在ACM研讨会上关于分布式计算的原则（Principles of Distributed Computing）所做的开题演讲
（keynote speech）。
Sex Pistols向同时代的人展示了几乎无限制的狂躁远比学院派的结构主义重要的多，给任何人3根弦以及一些许可就可以组建一支乐队。Eric Brewer，在那时被称为Brewer猜想，认为当应用系统变得越来越web化，应当放弃对数据一致性（data consistency）的担忧，因为要想获得这种新的分布式系统的高可用性（high availability），确保数据一致性是我们无法做到的，这样给予任何人3台服务器和一双关注客户体验的眼睛就可以建立一家互联网公司。 Brewer的信徒（当天就有的和后来皈依的）包括像Amazon, EBay和Twitter这类公司
2年后，2002年，麻省理工（MIT）的Seth Gilbert和Nancy Lynch，理论上证明了Brewer猜想是正确的，就此Brewer定理（Theorem）诞生了。
Brewer（CAP）定理
那么到底Brewer的定理是什么，为何它足以和1976年Manchester的punk演出媲美？
Brewer 在2000年的演讲是基于他在UC Berkley的理论工作以及主持Inktomi（期间）的观察，是通过数年前Brewer和其他人，在如何构建高伸缩性系统（highly scalable system）时所做出的各种折衷方案的讨论（例如：SOSP（Symposium on Operating System Principles）的1997年的Cluster-Based Scalable Network Service和1999年的Harvest, yield, and scalable tolerant system）就像其他的许多思想，因此这个演讲的内容并不是全新的，它是许多聪明人的共同成果（我确信Brewer会很快说明这一点）。
Brewer认为在分布式的环境下设计和部署系统时，有3个核心的系统需求（systemic requirements），以一种特殊的关系存在。（他主要是谈论Web类的应用，但如今非常多的公司业务是多站点／多国家的，因此该理论同样适用于你的数据中心/LAN/WAN的设计）
这3个核心的需求是：Consistency，Availability和Partition Tolerance，赋予了该理论另外一个名字 － CAP。
要想将该理论和现实的联系起来，让我们举一个简单的例子：你想购买一套托尔斯泰的《战争与和平》，以便在明天开始的长假中有可读的东西。然而你最喜欢的网上书店只有一本库存了。你进行搜索，确认书可以在你出发前送到，然后将书加入你的购物车。接着你想起来还有一些其他的东西要买，所以继续浏览网站（你是否在网站只买一件东西？当然要充分利用包裹的费用了）。但当你查看某个防晒霜的客户反馈时，国内某个地方的某个人，进入网站，将那本书加入到自己的购物车，然后直接付款（他们急需解决桌子摇晃的问题，其中一条桌脚比其他的短的多）。
- 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，任何中间状态同第二个客户都是隔离的，当然第二个客户必须等待几百毫秒以便数据存储达到一致状态。
- Availability
可用性只是意味着服务是可用的（可以完成如上的操作或不完成）。当你购书时期望得到反馈，而不是浏览器报告网站无法连接的信息。Gilbert 和Lynch在其CAP定理的证明中很好地指出了，可用性通常在你最需要的时刻背弃你。网站通常在业务最繁忙的时刻挂掉，因为网站压力最大。一个他人无法访问的服务对任何人都没有价值。
- 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，因为如果无法连接它，那它就和不存在一样。
定理的重要性
CAP定理在应用系统规模化时最有效。在低压力的情况下，小的延迟（以便数据库达到一致的状态）还不足以对总体的性能或用户体验造成影响。你所承担的负载分布，可能都是出于系统管理的原因。？
但随着活动的增加，吞吐量的上限（pinch-points）将会限制增长并产生错误。必须等待网页的返回是一种情况，另一种情况则是在你输入信用卡信息后遇到 “HTTP 500 java.lang.schrodinger.purchasingerror”，你就想知道你是否付了钱但无法得到东西，还是没付钱，或者这只是交易中一个不重要的错误。谁知道呢？你不太可能继续下去，很有可能到别的地方购物，或更有可能给银行打电话。
不管是那种情况对业务都没有好处。Amazon声称每0.1秒的响应延迟都会导致1％的销售降低。Google说他们注意到0.5秒的延迟会使流量减少15%。
我之前曾就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结合在一起”
总结
在Consistency, Availability和Partition-tolerance中，你只能保证2点，这是确实的，并且已经被这个星球上最成功的网站证实了。如果对网站是有效的，我看不出在企业环境中，在日常的工作中，不考虑同样的折衷设计的理由。如果业务方面明确表明不需要上规模（scale）那好，有简单的解决方案，但这是值得讨论的。在任何情况下，这些讨论都是针对特定操作的适合的设计，而不是庐山（注：shebang取意译）全貌。正如Brewer在其邮件中所说的：“唯一的我可以加入的是同一服务的不同部分可以选择这一系列（spectrum）中的不同的点”有时，无论scale的代价如何，你绝对需要一致性，因为缺少它的风险太大了。