CAP理论是分布式系统非常基础和重要的概念，想了解分布式系统就绕不开它，这里简单对此理论的基础概念做下介绍。
首先需要注意一点：
CAP仅适用于原子读写的NOSQL场景中，并不适合数据库系统。
CAP理论概念
一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
简单介绍：
- 一致性（Consistence） :所有节点访问同一份最新的数据副本
- 可用性（Availability）:每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据
- 分区容错性（Partition tolerance） : 分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。
需要注意，此处的C和A与数据库事务中的ACID中的C和A不是同一个东西，他们的C都表示一致性，但是事
务的A表示Atomicity原子性，而这里的A是Availability可用性。
C A P详细介绍
C —— Consistency 一致性
一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，所以，一致性，说的就是数据一致性。
对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。
一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。
从客户端角度，多进程并发访问时，更新过的数据在不同的进程如何获取的不同策略，决定了不同的一致性。
三种一致性策略：
- 强一致性 要求更新过的数据都能马上被后续访问看到
- 弱一致性 能容忍后续的部分或全部访问看不到更新过的数据
- 最终一致性 要求过一段时候之后能访问到更新过的数据
CAP理论中说不可能同时满足的这个C指的是强一致性
A —— Availability 可用性
可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。
对于一个可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应。所以，一般我们在衡量一个系统的可用性的时候，都是通过停机时间来计算的。
通常我们描述一个系统的可用性时，我们说淘宝的系统可用性可以达到5个9，意思就是说他的可用水平是99.999%，即全年停机时间不超过(1-0.99999)*365*24*60 = 5.256 min，这是一个极高的要求。
好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。一个分布式系统，上下游设计很多系统如负载均衡、WEB服务器、应用代码、数据库服务器等，任何一个节点的不稳定都可以影响可用性。
P —— Partition Tolerance分区容错性
分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。
分区容错性和扩展性紧密相关。在分布式应用中，可能因为一些分布式的原因导致系统无法正常运转。好的分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，或者是机器之间有网络异常，将分布式系统分隔未独立的几个部分，各个部分还能维持分布式系统的运作，这样就具有好的分区容错性。
简单点说，就是在网络中断，消息丢失的情况下，系统如果还能正常工作，就是有比较好的分区容错性。
CAP理论的证明
//to do
CAP的权衡抉择
- CAP无法同时满足，但是并不是三选二！
首先，P分区容错性是必须要满足的，如果舍弃分区容错，也就失去分布式系统的意义了。当网络分区之后P是前提，决定了P之后才有C和A的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。
1. CP
选择一致性放弃可用性，保证数据的正确牺牲用户体验。
一个保证了CP而一个舍弃了A的分布式系统，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。
设计成CP的系统其实也不少，其中最典型的就是很多分布式数据库，他们都是设计成CP的。在发生极端情况时，优先保证数据的强一致性，代价就是舍弃系统的可用性。如Redis、HBase等，还有分布式系统中常用的Zookeeper也是在CAP三者之中选择优先保证CP的。
无论是像Redis、HBase这种分布式存储系统，还是像Zookeeper这种分布式协调组件。数据的一致性是他们最最基本的要求。一个连数据一致性都保证不了的分布式存储要他有何用？
2. AP
要高可用并允许分区，则需放弃一致性。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，则每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。
这种舍弃强一致性而保证系统的分区容错性和可用性的场景和案例非常多。前面我们介绍可用性的时候说到过，很多系统在可用性方面会做很多事情来保证系统的全年可用性可以达到N个9，所以，对于很多业务系统来说，比如淘宝的购物，12306的买票。都是在可用性和一致性之间舍弃了一致性而选择可用性。
比如12306买票，在点击购票的一瞬间是有票的，但是付款的时候可能已经没了，这就是为了保证用户体验牺牲了数据的一致性，但是还是有最终一致性的保证的，在最终购票的时候还是会保证数据一致性。
总之，两种选择都没有对错，要看适用的不同场景。
对于涉及到钱财这样不能有一丝让步的场景，C必须保证。网络发生故障宁可停止服务，这是保证CA，舍弃P。比如前几年支付宝光缆被挖断的事件，在网络出现故障的时候，支付宝就在可用性和数据一致性之间选择了数据一致性，用户感受到的是支付宝系统长时间宕机，但是其实背后是无数的工程师在恢复数据，保证数数据的一致性。
对于其他场景，比较普遍的做法是选择可用性和分区容错性，舍弃强一致性，退而求其次使用最终一致性来保证数据的安全。这其实是分布式领域的另外一个理论——BASE理论。
总结和梳理CAP理论
一般我们说的分布式系统，P：分区容错性(partition-tolerance)这个是必需的，这是客观存在的。
CAP是无法完全兼顾的，从上面的例子也可以看出，我们可以选AP，也可以选CP。但是，要注意的是：不是说选了AP，C就完全抛弃了。不是说选了CP，A就完全抛弃了！
在CAP理论中，C所表示的一致性是强一致性(每个节点的数据都是最新版本)，其实一致性还有其他级别的：
弱一致性：弱一致性是相对于强一致性而言，它不保证总能得到最新的值；
最终一致性(eventual consistency)：放宽对时间的要求，在被调完成操作响应后的某个时间点，被调多个节点的数据最终达成一致
可用性的值域可以定义成0到100%的连续区间。
所以，CAP理论定义的其实是在容忍网络分区的条件下，“强一致性”和“极致可用性”无法同时达到。
