2000年7月，加州大学伯克利分校的埃里克布朗教授在ACM PODC会议上提出了CAP预期。 两年后，麻省理工学院的Seth Gilbert和快的哆啦A梦Lynch在理论上证明了CAP。 此后，CAP理论正式成为分布式计算领域的公认定理。
CAP理论概述分布式系统最多只能满足一致性、可用性和分区容错三个中的两个。
请注意，CAP理论中的CA和数据库事务中的ACID中的CA完全相同。 在两者中，a都是c，是一致性。 CAP中的a指可用性(Availability )，ACID中的a指原子性)。 请不要混淆。 CAP的定义一致性是指allnodesseethesamedataatthesametime。 也就是说，更新操作成功并返回客户端完成后，所有节点上同一时间的数据将完全匹配。 分布式一致性
关于一贯性，可以分为客户端和服务端两个不同的视点。 在客户端看来，一致性主要是指如何在多个同时访问时检索更新的数据。 从服务方面看，更新复制如何分布在整个系统上，以确保数据最终是一致的。 一致性是同时读写引起的问题，所以在理解一致性问题时，必须注意同时读写的情况。
从客户端角度看，当多个进程同时访问时，更新的数据是如何检索每个进程的决定着不同的一致性。 对于关系数据库，要求更新的数据在后续访问中可见。 这是很强的一致性。 如果可以接受后续部分或全部不可访问，则为弱一致性。 如果需要允许访问经过一段时间后更新的数据，则是最终的一致性。
Availability的可用性是指“读取和写入全部就绪”。 这意味着服务始终可用，并且是正常的响应时间。
对于高可用性分布式系统，每个无故障节点都必须响应每个请求。 因此，通常在测量系统可用性时计算停机时间。
可用性级别(% )允许的年停机容错可用性99.99991 min可用性99.9995 min高可用性99.9953 min高可用性99.98.8h产品可用性9943.8 min通常描述一个系统的可用性，具有极高的可用性99.9995 min故障自动恢复功能也就是说，他的可用水平为99.999%，年停机时间为(1-0.99999 ) *365*24*60=5.256 min以下，这是极高的要求。
高可用性主要是指系统可以为用户提供服务，用户体验不会失败，也不会出现访问超时等问题。 许多系统(包括负载平衡、WEB服务器、APP应用程序代码和数据库服务器)都是设计在上下游的分布式系统，任何节点的不稳定性都会影响可用性。
Partition Tolerance分区容错分区容错是指thesystemcontinuestooperatedespitearbitrarymessagelossorfailureofpartofthesystagelossssagelelereofpartofpartoftoftofthethethethesysysysysysysthed
分区的容错性和可扩展性密切相关。 在分布式APP应用程序中，由于某些分布式原因，系统可能无法正常工作。 良好的分区容错要求使APP应用程序看起来像是一个分布式系统，但却能正常工作的整体。 例如，在当前的分布式系统中，即使一台或几台机器停机，其他机器也能正常运行以满足系统的需要。 或者机器之间存在网络异常，将分布式系统分为几个不独立的部分，每个部分都可以保持分布式系统的运行，具有良好的分区容错能力。
CAP证明
上图是我们证明CAP的基本场景。 可以看到，网络有两个节点N1和N2，N1和N2分别是两台计算机，它们之间连接着网络。 N1有APP应用程序a和数据库v，N2也有APP应用程序B2和数据库v。 目前，a和b是分布式系统的两个部分，v是分布式系统数据存储的两个子数据库。
满足一致性时，N1和N2的数据相同，V0=V0。 如果满足可用性，则用户在请求N1或N2时会立即响应。 如果满足分区容错要求，则N1或N2中的任何一个中断或网络中断都不会影响N1和N2之间的正常操作。
上图是分布式系统正常运行的流程，其中用户请求N1计算机更新数据，程序a将数据库Vo更新为V1。 分布式系统对数据执行同步操作m，将V1同步为N2中的V0，N2中的数据V0也更新为V1，N2中的数据再次响应N2的请求。
在此，可以定义N1和N2数据库v之间的数据是否相同的外部对N1和N2的请求响应是可以使用的行； N1和N2之间的网络环境是分区容错。 这是正常工作的场景，也是理想的场景。 但是，现实很残酷。 发生错误时，分区具有一致性和可用性。 同时令人满意吗？ 还是要取舍呢？
作为分布式系统，与独立系统最大的区别在于网络。 现在，假设极端的情况，n
1和N2之间的网络断开了，我们要支持这种网络异常，相当于要满足分区容错性，能不能同时满足一致性和响应性呢？还是说要对他们进行取舍。假设在N1和N2之间网络断开的时候，有用户向N1发送数据更新请求，那N1中的数据V0将被更新为V1，由于网络是断开的，所以分布式系统同步操作M，所以N2中的数据依旧是V0；这个时候，有用户向N2发送数据读取请求，由于数据还没有进行同步，应用程序没办法立即给用户返回最新的数据V1，怎么办呢？
有二种选择，第一，牺牲数据一致性，响应旧的数据V0给用户；
第二，牺牲可用性，阻塞等待，直到网络连接恢复，数据更新操作M完成之后，再给用户响应最新的数据V1。
这个过程，证明了要满足分区容错性的分布式系统，只能在一致性和可用性两者中，选择其中一个。
CAP权衡通过CAP理论，我们知道无法同时满足一致性、可用性和分区容错性这三个特性，那要舍弃哪个呢？
CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。
CP without A：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。
CA without P这种情况在分布式系统中几乎是不存在的。首先在分布式环境下，网络分区是一个自然的事实。因为分区是必然的，所以如果舍弃P，意味着要舍弃分布式系统。那也就没有必要再讨论CAP理论了。这也是为什么在前面的CAP证明中，我们以系统满足P为前提论述了无法同时满足C和A。
比如我们熟知的关系型数据库，如My Sql和Oracle就是保证了可用性和数据一致性，但是他并不是个分布式系统。一旦关系型数据库要考虑主备同步、集群部署等就必须要把P也考虑进来。
其实，在CAP理论中。C，A，P三者并不是平等的，CAP之父在《Spanner，真时，CAP理论》一文中写到：
如果说Spanner真有什么特别之处，那就是谷歌的广域网。Google通过建立私有网络以及强大的网络工程能力来保证P，在多年运营改进的基础上，在生产环境中可以最大程度的减少分区发生，从而实现高可用性。
从Google的经验中可以得到的结论是，无法通过降低CA来提升P。要想提升系统的分区容错性，需要通过提升基础设施的稳定性来保障。
所以，对于一个分布式系统来说。P是一个基本要求，CAP三者中，只能在CA两者之间做权衡，并且要想尽办法提升P。
CP without A如果一个分布式系统不要求强的可用性，即容许系统停机或者长时间无响应的话，就可以在CAP三者中保障CP而舍弃A。
一个保证了CP而一个舍弃了A的分布式系统，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。
设计成CP的系统其实也不少，其中最典型的就是很多分布式数据库，他们都是设计成CP的。在发生极端情况时，优先保证数据的强一致性，代价就是舍弃系统的可用性。如Redis、HBase等，还有分布式系统中常用的Zookeeper也是在CAP三者之中选择优先保证CP的。
无论是像Redis、HBase这种分布式存储系统，还是像Zookeeper这种分布式协调组件。数据的一致性是他们最最基本的要求。一个连数据一致性都保证不了的分布式存储要他有何用？
在我的Zookeeper介绍（二）——Zookeeper概述一文中其实介绍过zk关于CAP的思考，这里再简单回顾一下：
ZooKeeper是个CP（一致性+分区容错性）的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性。但是它不能保证每次服务请求的可用性，也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果。ZooKeeper是分布式协调服务，它的职责是保证数据在其管辖下的所有服务之间保持同步、一致。所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性的了。
AP wihtout C要高可用并允许分区，则需放弃一致性。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，则每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。
这种舍弃强一致性而保证系统的分区容错性和可用性的场景和案例非常多。前面我们介绍可用性的时候说到过，很多系统在可用性方面会做很多事情来保证系统的全年可用性可以达到N个9，所以，对于很多业务系统来说，比如淘宝的购物，12306的买票。都是在可用性和一致性之间舍弃了一致性而选择可用性。
你在12306买票的时候肯定遇到过这种场景，欢喜的汉堡购买的时候提示你是有票的（但是可能实际已经没票了），你也正常的去输入验证码，下单了。但是过了一会系统提示你下单失败，余票不足。这其实就是先在可用性方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，会影响一些用户体验，但是也不至于造成用户流程的严重阻塞。
但是，我们说很多网站牺牲了一致性，选择了可用性，这其实也不准确的。就比如上面的买票的例子，其实舍弃的只是强一致性。退而求其次保证了最终一致性。也就是说，虽然下单的瞬间，关于车票的库存可能存在数据不一致的情况，但是过了一段时间，还是要保证最终一致性的。
对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证P和A，舍弃C（退而求其次保证最终一致性）。虽然某些地方会影响客户体验，但没达到造成用户流程的严重程度。
适合的才是最好的上面介绍了如何CAP中权衡及取舍以及典型的案例。孰优孰略，没有定论，只能根据场景定夺，适合的才是最好的。
对于涉及到钱财这样不能有一丝让步的场景，C必须保证。网络发生故障宁可停止服务，这是保证CA，舍弃P。比如前几年支付宝光缆被挖断的事件，在网络出现故障的时候，支付宝就在可用性和数据一致性之间选择了数据一致性，用户感受到的是支付宝系统长时间宕机，但是其实背后是无数的工程师在恢复数据，保证数数据的一致性。
对于其他场景，比较普遍的做法是选择可用性和分区容错性，舍弃强一致性，退而求其次使用最终一致性来保证数据的安全。这其实是分布式领域的另外一个理论——BASE理论。我们下一篇文章再来介绍。
参考资料：CAP和BASE理论 CAP原理的证明
拓展阅读：CAP理论