引言
CAP是分布式系统，特别是分布式存储领域讨论最多的理论，“什么是CAP定理？ ”在Quora的分布式系统分类中排在FAQ的第一位。 CAP在程序员中也很普遍，不仅仅是“C、a、p不能同时满足，最多只能选择三选二”。 下面，综合各方面的观点，从发展历史、工程实践等角度来阐述CAP理论。 希望大家通过本文能对CAP理论有更多的了解和认识。
CAP定理
CAP是由Eric Brewer在2000年的PODC会议上提出的[1][2]，它描述了Eric Brewer在Inktomi[3]期间开发搜索引擎、分布式web缓存时得到的数据完整性(consistency
itisimpossibleforawebservicetoprovidethethreefollowingguarantees 3360一致性，availabilityandpartition-tolerance。
该猜想在提出两年后被证明是成立的[4]，成为了众所周知的CAP定理：
http://www.Sina.com/(consistency ) :如果系统写入成功，所有后续的读取请求都必须读取此新数据。 如果返回失败，所有读取操作都无法读取此数据。 对调用方来说数据一致性强(strong consistency ) (原子性atomic，也称为线性一致性linearizable consistency ) )5) http://www.Sina.com/) avail http://www.Sina.com/(partition-tolerance ) :对于网络分区，被划分的节点可以正常地提供对外服务
在某一时刻满足AP，分离的节点同时提供对外服务，但如果不能相互通信，就无法满足状态不一致，即c； 如果满足CP，对于网络分区，为了达到c，请求只能一直等待。 也就是说，不满足a。 满足CA要求在一定时间内节点状态一致，不出现网络分区，无法满足p。
C、a、p这3个最多只能满足其中的2个，和FLP定理一样，CAP定理也显示了不可能达成的结果(impossibility result )。
数据一致性
CAP理论提出7、8年后，NoSql圈以CAP理论作为对抗传统关系型数据库的依据，揭示了放宽数据一致性要求的正确性(6)，随后引发了对CAP理论的广泛讨论
虽然CAP理论似乎给我们提出了三道选择题，但在工程实践中存在许多现实的限制条件，为了避免CAP认识的错误，我们需要进行更多的考虑和权衡[7]。
服务可用性
Partition顾名思义是指网络分区，即根据网络因素将系统分成多个独立的部分。 可能会说网络分区的发生概率非常低吧。 不考虑p就保证CA不就好了吗[8]。 要理解p，请看看CAP证书[4]中p的定义。
inordertomodelpartitiontolerance，thenetworkwillbeallowedtolosearbitrarilymanymessagessentfromonenodetoanother。
这在网络分区的情况下属于该定义，在网络数据包丢失的情况下也属于上述定义，在节点断开，从其他节点到下行节点的数据包也丢失的情况下也同样属于该定义。 现实中，我们面临的是不可靠的网络、以一定概率瘫痪的设备、这两个要素都会导致Partition，因此在分布式系统的实现中，p是必须项目，不是选项[9][10]。
对于分布式系统工程实践，CAP理论更好地描述为：在满足分区容错的前提下，没有同时满足数据完整性和服务可用性的算法[11] :
inanetworksubjecttocommunicationfailures，itisimpossibleforanywebservicetoimplementanatomicread/writesharedmorythatguarand
分区容错性
p是一个必需的选择，这三个选项应该是数据完整性(consistency )、服务可用性(availability )这两个选项？ 工程实践中的一致性有不同程度，可用性也有层次。 在保证地块容错能力的前提下，通过放宽约束可以兼顾一致性和可用性，两者则不然
[12]。
CAP定理证明中的一致性指强一致性，强一致性要求多节点组成的被调要能像单节点一样运作、操作具备原子性，数据在时间、时序上都有要求。如果放宽这些要求，还有其他一致性类型：
序列一致性(sequential consistency)[13]：不要求时序一致，A操作先于B操作，在B操作后如果所有调用端读操作得到A操作的结果，满足序列一致性最终一致性(eventual consistency)[14]：放宽对时间的要求，在被调完成操作响应后的某个时间点，被调多个节点的数据最终达成一致
可用性在CAP定理里指所有读写操作必须要能终止，实际应用中从主调、被调两个不同的视角，可用性具有不同的含义。当P(网络分区)出现时，主调可以只支持读操作，通过牺牲部分可用性达成数据一致。
工程实践中，较常见的做法是通过异步拷贝副本(asynchronous replication)、quorum/NRW，实现在调用端看来数据强一致、被调端最终一致，在调用端看来服务可用、被调端允许部分节点不可用(或被网络分隔)的效果[15]。
3、跳出CAP
CAP理论对实现分布式系统具有指导意义，但CAP理论并没有涵盖分布式工程实践中的所有重要因素。
例如延时(latency)，它是衡量系统可用性、与用户体验直接相关的一项重要指标[16]。CAP理论中的可用性要求操作能终止、不无休止地进行，除此之外，我们还关心到底需要多长时间能结束操作，这就是延时，它值得我们设计、实现分布式系统时单列出来考虑。
延时与数据一致性也是一对“冤家”，如果要达到强一致性、多个副本数据一致，必然增加延时。加上延时的考量，我们得到一个CAP理论的修改版本PACELC[17]：如果出现P(网络分区)，如何在A(服务可用性)、C(数据一致性)之间选择；否则，如何在L(延时)、C(数据一致性)之间选择。
小结
以上介绍了CAP理论的源起和发展，介绍了CAP理论给分布式系统工程实践带来的启示。
CAP理论对分布式系统实现有非常重大的影响，我们可以根据自身的业务特点，在数据一致性和服务可用性之间作出倾向性地选择。通过放松约束条件，我们可以实现在不同时间点满足CAP(此CAP非CAP定理中的CAP，如C替换为最终一致性)[18][19][20]。
有非常非常多文章讨论和研究CAP理论，希望这篇对你认识和了解CAP理论有帮助。
[1] Harvest, Yield, and Scalable Tolerant Systems, Armando Fox , Eric Brewer, 1999
[2] Towards Robust Distributed Systems, Eric Brewer, 2000
[3] Inktomi's wild ride - A personal view of the Internet bubble, Eric Brewer, 2004
[4] Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web, Seth Gilbert, Nancy Lynch, 2002
[5] Linearizability: A Correctness Condition for Concurrent Objects, Maurice P. Herlihy,Jeannette M. Wing, 1990
[6] Brewer's CAP Theorem - The kool aid Amazon and Ebay have been drinking, Julian Browne, 2009
[7] CAP Theorem between Claims and Misunderstandings: What is to be Sacrificed?, Balla Wade Diack,Samba Ndiaye,Yahya Slimani, 2013
[8] Errors in Database Systems, Eventual Consistency, and the CAP Theorem, Michael Stonebraker, 2010
[9] CAP Confusion: Problems with 'partition tolerance', Henry Robinson, 2010
[10] You Can’t Sacrifice Partition Tolerance, Coda Hale, 2010
[11] Perspectives on the CAP Theorem, Seth Gilbert, Nancy Lynch, 2012
[12] CAP Twelve Years Later: How the "Rules" Have Changed, Eric Brewer, 2012
[13] How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs, Lamport Leslie, 1979
[14] Eventual Consistent Databases: State of the Art, Mawahib Elbushra , Jan Lindström, 2014
[15] Eventually Consistent, Werner Vogels, 2008
[16] Speed Matters for Google Web Search, Jake Brutlag, 2009
[17] Consistency Tradeoffs in Modern Distributed Database System Design, Daniel J. Abadi, 2012
[18] A CAP Solution (Proving Brewer Wrong), Guy's blog, 2008
[19] How to beat the CAP theorem, nathanmarz , 2011
[20] The CAP FAQ, Henry Robinson