简单说说分布式系统的CAP理论
一、CAP理论概述
一个分布式系统最多只能同时满足一致性（Consistency），可用性（Avaliability）和分区容错性（Partition tolerance）这三项中的两项。
二、CAP的定义
Consistency 一致性
一致性是指“all node see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，即数据一致性。一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。
三种一致性策略
* 对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。
* 如果能容忍后续的部分或者全部访问不到，则是弱一致性。
* 如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。
按CAP中说，不可能同时满足的这个一致性是强一致性。
Avalability可用性
可用性是指“Reads and writes always succeed”,即服务一直可用，而且是正常响应时间。对于一个可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应。所以，一般我们在衡量一个系统可用性的适合，都是通过停机时间来计算的。比如我们说淘宝的系统可用性可以达到5个9，即可用水平是99.999%，即全年停机时间不超过（1-0.99999）*365*24*60=5.256min，这是一个极高的要求。
Partition tolerance分区容错性
分区容错性是指“the system continues to operate despite arbitrary message loss or falilure of part of the system”,即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。简单的说，就是在网络中断，消息丢失的情况下，系统如果还能正常工作，就是有比较好的分区容错性。
CAP的证明
举个例子，比如有两台服务器，第一台上面有A1应用和B1数据库，第二台有A2应用和B2数据库。CAP的定义如下：
* 一致性，即无论访问A1或者A2，都能得到一样的结果
* 可用性，无论访问A1还是A2，都能立刻得到返回
* 分区容错性，无论哪台服务器挂掉，系统都能正常运行
这时候，加入两个服务器直接网络不同了，应该每台都能访问，才能满足分区容错，那么这个时候，要么等待网络通了，才能有一致性，要么直接返回不一致的数据，保证可用性。三者不可兼得。
CAP的权衡
通过CAP理论及前面的证明，我们知道无法同时满足一致性，可用性和分区容错性这三个特性，那要舍弃哪个呢？
我们分三种情况来阐述一下。
* CA without P
* 这种情况在分布式系统中几乎是不存在的。首先，在分布式环境下，网络分区是一个自然的事实。因为分区是必然的，所以如果舍弃P，意味着要舍弃分布式系统。那也就没有必要讨论CAP理论了。这也就是为什么在前面的CAP证明中，我们以满足P微前提论述了无法同时满足C和A。
* 比如我们熟知的关系型数据库，如mysql和Oracle就是保证了可用性和数据一致性，但是他并不是一个分布式系统。一旦关系型数据库要考虑主备同步，集群部署等就要把P也考虑进来。
* 其实，在CAP理论中。C，A，P三者并不是平等的。从Google的经验中可以得到的结论是，无法通过降低CA来提示P。要想提高系统的分区容错性，需要通过提升基础设施的稳定性来保障。所以，对于一个分布式系统来说，P是一个基本要求，CAP三者中，只能在CA两者之间权衡，并且要想办法提升P。
* CP without A
* 如果一个分布式系统不要求强的可用性，即容许系统停机或者长时间无响应的话，就可以在CAP三者中保障CP而舍弃A。设计称CP的系统其实也不少，其中最典型的就是很多分布式数据库，他们都是设计成CP的。在发生极端情况下，优先保证数据的强一致性，代价就是舍弃系统的可用性。如Redis，HBase等，还有分布式系统常用的Zookeeper也是在CAP三者中选择优先保证CP的（任何时刻对Zookeeper 请求都能得到一直的数据结果）。
* 无论是像Redis，HBase这种分布式存储系统，还是像Zookeeper这种分布式协调组件。数据的一致性是他们最最基本的要求。一个连数据一致性都保证不了的分布式存储要他何用？
* AP without C
* 要高可用并允许分区，则需放弃一致性。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，则每个节点只能用本地数据提供服务，而这样会导致全局数据不一致。例如，淘宝购物，12306买票，都是在可用性和一致性之间舍弃了一致性而选择了可用性（但其实保证了最终一致性，只是影响了客户体验）。