参考：
CAP定理，https://en.wikipedia.org/wiki/CAP_theorem
http://www.cnblogs.com/hxsyl/p/4381980.html
http://www.hollischuang.com/archives/666
[1]http://www.infoq.com/cn/articles/cap-twelve-years-later-how-the-rules-have-changed/
[2]http://blog.csdn.net/it_man/article/details/8574201
[3]http://www.cnblogs.com/mmjx/archive/2011/12/19/2290540.html
[4]http://blog.csdn.net/zhangzhebjut/article/details/22977977
定义
一个分布式系统最多只能同时满足 一致性（Consistency），可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
CAP理论主张任何基于网络的数据共享系统，都最多只能拥有以下三条中的两条：
- 数据一致性（C），等同于所有节点访问同一份最新的数据副本；
- 对数据更新具备高可用性（A）；
- 能容忍网络分区（P）。
CAP的定义如下：
| Guarantees | Definition |
|---|---|
| Consistency | Every read receives the most recent write or an error |
| Availability | Every request receives a response, without guarantee that it contains the most recent version of the information |
| Partition tolerance | The system continues to operate despite an arbitrary number of messages being dropped by the network between nodes |
理解CAP，要先记住它的对象，是分布式系统。
一致性（Consistency）
一致性（Consistency），说的是每一个更新成功后，分布式系统中的所有节点，都能读到最新的信息。即所有节点相当于访问同一份内容，这样的系统就被认为是强一致性的。
可用性（Availability）
可用性（Availability），是每一个请求，都能得到响应。请求只需要在一定时间内返回即可，结果可以是成功或者失败，也不需要确保返回的是最新版本的信息。
分区容错性（Partition tolerance）
分区容错性（Partition tolerance），是说在网络中断，消息丢失的情况下，系统照样能够工作。这里的网络分区是指由于某种原因，网络被分成若干个孤立的区域，而区域之间互不相通。
这里可以初亏出，如果要满足P，就很难同时满足C和A。
CAP权衡
例1
对于互联网应用，主机多，数据大，部署分散。所以节点故障，网络故障是常态。这种情况下，要保证A和P。舍弃C虽然会影响客户体验，但保证AP，才能不影响用户使用流程。
例2
对于金融领域，必须要保证C和A，舍弃P。所以金融领域的网络设备故障，可能会造成用户无法使用。
其实就是数据库系统中提到的ACID的另一种表述：
一个用户请求要么成功、要么失败，不能处于中间状态（Atomic）；
一旦一个事务完成，将来的所有事务都必须基于这个完成后的状态（Consistent）；
未完成的事务不会互相影响（Isolated）；
一旦一个事务完成，就是持久的（Durable）。
对于Availability，其概念没有变化，指的是对于一个系统而言，所有的请求都应该‘成功’并且收到‘返回’。
对于Partition-tolerance，所指就是分布式系统的容错性。节点crash或者网络分片都不应该导致一个分布式系统停止服务。
2.1 强一致性
强一致性：系统在执行过某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读到最新的值，这样的系统被认为是具有强一致性的。 等同于所有节点访问同一份最新的数据副本；
All clients always have the same view of the data。
2.2 可用性
可用性：每一个操作总是能够在一定的时间内返回结果，这里需要注意的是"一定时间内"和"返回结果"。一定时间指的是，在可以容忍的范围内返回结果，结果可以是成功或者失败。 对数据更新具备高可用性（A）；
Each client can alwa read and write。
2.3 分区容错性
分区容错性：理解为在存在网络分区的情况下，仍然可以接受请求（满足一致性和可用性)。这里的网络分区是指由于某种原因，网络被分成若干个孤立的区域，而区域之间互不相通。还有一些人将分区容错性理解为系统对节点动态加入和离开的能力，因为节点的加入和离开可以认为是集群内部的网络分区。
Partition Tolerance的意思是，在网络中断，消息丢失的情况下，系统照样能够工作。 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择
2.4 放弃C.A.P
放弃P：如果想避免分区容错性问题的发生，一种做法是将所有的数据（与事务相关的）都放在一台机器上。虽然无法100%保证系统不会出错，但不会碰到由分区带来的负面效果。当然这个选择会严重的影响系统的扩展性。
放弃A:相对于放弃“分区容错性“来说，其反面就是放弃可用性。一旦遇到分区容错故障，那么受到影响的服务需要等待一定的时间，因此在等待期间系统无法对外提供服务。
放弃C：这里所说的放弃一致性，并不是完全放弃数据一致性，而是放弃数据的强一致性，而保留数据的最终一致性。以网络购物为例，对只剩下一件库存的商品，如果同时接受到了两份订单，那么较晚的订单将被告知商品告罄。
一致性与可用性的决择： 而CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定 会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用 性之间进行权衡。
CAP的证明很简单，假设两个节点集{G1, G2}，由于网络分片导致G1和G2之间所有的通讯都断开了，如果在G1中写，在G2中读刚写的数据， G2中返回的值不可能G1中的写值。由于A的要求，G2一定要返回这次读请求，由于P的存在，导致C一定是不可满足的。
五.一致性分类
对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数WEB应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是多数分布式数据库产品的方向。
当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。
对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。
7.2 解决CAP
根据一些专家的分析，CAP并不是一个严谨的定律，并不是牺牲了Consistency，就一定能同时获得Availability和Partition Tolerance。还有一个很重要的因素是Latency，在CAP中并没有体现。在现在NoSQL以及其他一些大规模设计时，A和P并不是牺牲C或部分牺牲C的借口，因为即使牺牲了C，也不一定A和P，并且C不一定必须要牺牲。
淘宝一天就处理了1亿零580万，而12306一天处理的交易仅仅166万条 ，如果从并发性上来说，淘宝的并发量远比12306大，但天猫的商品信息，促销数据都可以做缓存，做CDN，而12306的“商品”是一个个座位，这些座位必须通过后端数据库即时查询出来，状态的一致性要求很高。
从这点上看，12306的商品信息很难利用到缓存，因此12306查看“商品”的代价是比较大的，涉及到一系列的后端数据库操作，从这个角度讲，12306的复杂度是高于天猫的。 淘宝的商品相对独立，而12306商品之间的关联性很大，由于CAP定律限制，如果其商品的一致性要求过高，必然对可用性和分区容错性造成影响。
因此，业务设计上，如果找到一条降低一致性要求时，还能保证业务的正确性的业务分拆之路。举个例子，火车票查询时，不要显示多少张，而是显示“有”或“无”，或者显示>100张，50~100,小于50等，这样就可以减小状态的更新频率，充分使用缓存数据。
CAP 理论说在一个系统中对某个数据不存在一个算法同时满足 Consistency, Availability, Partition-tolerance。注意，这里边最重要和最容易被人忽视的是限定词“对某个数据不存在一个算法”。这就是说在一个系统中，可以对某些数据做到 CP, 对另一些数据做到 AP，就算是对同一个数据，调用者可以指定不同的算法，某些算法可以做到 CP，某些算法可以做到 AP。
Consistency 一致性
一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，所以，一致性，说的就是数据一致性。分布式的一致性
对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。
一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。
从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。
三种一致性策略
对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。
如果能容忍后续的部分或者全部访问不到，则是弱一致性。
如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。
CAP中说，不可能同时满足的这个一致性指的是强一致性。