CAP定理
CAP定理（CAP theorem）,又被称作布鲁尔定理（Brewer’s theorem）,指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，最多只能同时满足其中的2个。
CAP的具体定义：
- Consistency（一致性）：指数据在多个副本之间能够保持一致的特性,一般特指写操作之后的读操作，必须返回该值。举例来说，某条记录是 v0，用户向 G1 发起一个写操作，将其改为 v1。
- Availability（可用性）：指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应，但是不保证获取的数据为最新数据。
- Partition tolerance（分区容错性）：分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障
理解CAP理论的最简单方式是想象两个节点分处分区两侧:允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。
CAP原则论证
一般来说，分区容错无法避免，因此可以认CA的P总是成立。CAP定理告诉我们，剩下的C和A无法同时做到，下面是一个详细的推论过程来展示CA直接的矛盾。
网络中有两个节点N1和N2，可以简单的理解N1和N2分别是两台计算机，他们之间网络可以连通，N1中有一个应用程序A，和一个数据库V，N2也有一个应用程序B和一个数据库V。现在，A和B是分布式系统的两个部分，V是分布式系统的数据存储的两个子数据库。
- 在满足一致性的时候，N1和N2中的数据是一样的，V0=V0。
- 在满足可用性的时候，用户不管是请求N1或者N2，都会得到立即响应。
- 在满足分区容错性的情况下，N1和N2有任何一方宕机，或者网络不通的时候，都不会影响N1和N2彼此之间的正常运作。
假设用户向N1机器请求数据更新，程序A更新数据库V0为V1。分布式系统将数据进行同步操作M，将V1同步的N2中V0，使得N2中的数据V0也更新为V1，N2中的数据再响应N2的请求。
根据CAP原则定义，系统的一致性、可用性和分区容错性细分如下：
- 一致性：N1和N2的数据库V之间的数据是否完全一样。
- 可用性：N1和N2的对外部的请求能否做出正常的响应。
- 分区容错性：N1和N2之间的网络是否互通。
这是正常运作的场景，也是理想的场景。作为一个分布式系统，它和单机系统的最大区别，就在于网络。现在假设一种极端情况，N1和N2之间的网络断开了，我们要支持这种网络异常。相当于要满足分区容错性，能不能同时满足一致性和可用性呢？还是说要对他们进行取舍？
假设在N1和N2之间网络断开的时候，有用户向N1发送数据更新请求，那N1中的数据V0将被更新为V1。由于网络是断开的，所以分布式系统同步操作M，所以N2中的数据依旧是V0。这个时候，有用户向N2发送数据读取请求，由于数据还没有进行同步，应用程序没办法立即给用户返回最新的数据V1，怎么办呢？ 这里有两种选择：
- 牺牲数据一致性，保证可用性。响应旧的数据V0给用户。
- 牺牲可用性，保证数据一致性。阻塞等待，直到网络连接恢复，数据更新操作M完成之后，再给用户响应最新的数据V1。
CAP原理的应用
互联网场景
对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证P和A，舍弃C（退而求其次保证最终一致性）。虽然某些地方会影响客户体验，但没达到造成用户流失的严重程度。
对于涉及到钱财这样不能有一丝让步的场景，C必须保证。网络发生故障宁可停止服务（或者只读不写），这是保证CA，舍弃P
数据库领域
依据CAP理论，从应用的需求不同，我们选型数据库时，可以从三方面考虑：
考虑CA，这就是传统上的关系型数据库(RMDB)
考虑CP，主要是一些Key-value数据库，典型代表为google的Big Table
考虑AP，主要是一些面向文档的适用于分布式系统的数据库，如SimpleDB
以下是一张流传甚广的图，它展示了按照CAP中三选二对数据库系统的分类：
