CAP定理简介
C：Consistency，多台机器的数据一致性。
A：Availability，服务可用性，比如你用一个分布式事务从主同步数据到从，这时候服务不可用。
P：Partition-tolerance，分区容忍性，如果多台机器间，产生了分区，比如网络不通，服务是否可容忍。 等同于，【如果多台服务器有相同的数据，对于分区是可以容忍的】。
CA：单服务器。
CP：多服务器，数据强行同步，比如2PC，导致服务短时间不可用。
AP：多服务器，数据最终一致，比如异步消息，导致主挂了后，从可能没有完整数据。
Consistency其实就是数据库系统中提到的ACID的另一种表述：
-
一个用户请求要么成功、要么失败，不能处于中间状态（Atomic）；
-
一旦一个事务完成，将来的所有事务都必须基于这个完成后的状态（Consistent）；
-
未完成的事务不会互相影响（Isolated）；
-
一旦一个事务完成，就是持久的（Durable）。
对于Availability，其概念没有变化，指的是对于一个系统而言，所有的请求都应该‘成功’并且收到‘返回’。
对于Partition-tolerance，所指就是分布式系统的容错性。节点crash或者网络分片都不应该导致一个分布式系统停止服务。
业界方案
由于每台机器都可能挂，所以排除CA，即数据需要备多份，P必须满足。从上面可以看出，CP或者AP都有明显缺点，所以选择一个折衷的方案：2f+1台服务器，如果1是主，同步到f台备后就告诉请求方，已经成功。在可用性与一致性方面折衷。
如果备挂了，不用管，直到它自己恢复。
如果主挂了，用Raft等选举算法，选举出新的主。选举过程中，服务不可用，大概几百ms。
即采取AP，保证分布式高可用，并通过弱一致性或最终一致性来同步数据。系统可以不同时达到CAP，而是分时达到。
CAP的证明
CAP的证明很简单，假设两个节点集{G1, G2}，由于网络分片导致G1和G2之间所有的通讯都断开了，如果在G1中写，在G2中读刚写的数据， G2中返回的值不可能G1中的写值。由于A的要求，G2一定要返回这次读请求，由于P的存在，导致C一定是不可满足的。
流行解释
目前流行的、对CAP理论解释的情形是从同一数据在网络环境中存在多个副本出发为前提的。为了保证数据不会丢失，同时也是为了增加并发访问量（读写分离），在企业级的数据管理方案中，一般必须考虑数据的冗余存储问题，而这应该是通过在网络上的其他独立物理存储节点上保留另一份、或多份数据副本来实现的。因为在同一个存储节点上的数据冗余明显不能解决单点故障问题，这与通过多节点集群来提供更好的计算可用性的道理是相同的。
数据在节点A、B、C上保留了三份，如果对节点A上的数据进行了修改，然后再让客户端通过网络对该数据进行读取。那么，客户端的读取操作什么时候返回呢？
一种情况是要求节点A、B、C的三份数据完全一致后返回。也就是说，这时从任何一个网络节点读取的数据都是一样的，这就是所谓的强一致性读。很明显，这时数据读取的Latency要高一些（因为要等数据在网络中的复制），同时A、B、C三个节点中任何一个宕机，都会导致数据不可用。也就是说，要保证强一致性，网络中的副本越多，数据的可用性就越差。
另一种情况是，允许读操作立即返回，容忍B节点的读取与A节点的读取不一致的情况发生。这样一来，可用性显然得到了提高，网络中的副本也可以多一些，唯一得不到保证的是数据一致性。当然，对写操作同样也有多个节点一致性的情况，在此不再赘述。
可以看出，上述对CAP理论的解释主要是从网络上多个节点之间的读写一致性出发考虑问题的。而这一点，对于关系型数据库意味着什么呢？当然主要是指通常所说的Standby（关于分布式事务，涉及到更多考虑，随后讨论）情况。对此，在实践中我们大多已经采取了弱一致性的异步延时同步方案，以提高可用性。这种情况并不存在关系型数据库为保证C、A而放弃P的情况；而对海量数据管理的需求，关系型数据库扩展过程中所遇到的性能瓶颈，似乎也并不是CAP理论中所描述的那种原因造成的。那么，上述流行的说法中所描述的关系型数据库为保证C、A而牺牲P到底是在指什么呢？ 如果只将CAP当作分布式系统中多个数据副本之间的读写一致性问题的通用理论对待，那么就可以得出结论：CAP既适用于NoSQL数据库，也适用于关系型数据库。它是NoSQL数据库、关系型数据库，乃至一切分布式系统在设计数据多个副本之间读写一致性问题时需要遵循的共同原则。
解决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。
