无论是在工作还是学习途中我们必然会接触到分布式系统，例如：zookeeper就是使用CP原则，eureka使用AP原则，那么CAP原则是必然需要了解的知识之一。
接下来我们先了解一下什么是CAP，CAP即CAP定理或叫做CAP原则，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。
1、理论
分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳：
● 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
● 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
● 分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
2、为何不可三者兼得
现在我们就来证明一下，为什么不能同时满足三个特性？
假设有两台服务器，一台放着应用A和数据库V，一台放着应用B和数据库V，他们之间的网络可以互通，也就相当于分布式系统的两个部分。
在满足一致性的时候，两台服务器 N1和N2，一开始两台服务器的数据是一样的，DB0=DB0。在满足可用性的时候，用户不管是请求N1或者N2，都会得到立即响应。在满足分区容错性的情况下，N1和N2有任何一方宕机，或者网络不通的时候，都不会影响N1和N2彼此之间的正常运作。
当用户通过N1中的A应用请求数据更新到服务器DB0后，这时N1中的服务器DB0变为DB1，通过分布式系统的数据同步更新操作，N2服务器中的数据库V0也更新为了DB1，这时，用户通过B向数据库发起请求得到的数据就是即时更新后的数据DB1。
上面是正常运作的情况，但分布式系统中，最大的问题就是网络传输问题，现在假设一种极端情况，N1和N2之间的网络断开了，但我们仍要支持这种网络异常，也就是满足分区容错性，那么这样能不能同时满足一致性和可用性呢？
假设N1和N2之间通信的时候网络突然出现故障，有用户向N1发送数据更新请求，那N1中的数据DB0将被更新为DB1，由于网络是断开的，N2中的数据库仍旧是DB0；
如果这个时候，有用户向N2发送数据读取请求，由于数据还没有进行同步，应用程序没办法立即给用户返回最新的数据DB1，怎么办呢？有二种选择，第一，牺牲数据一致性，响应旧的数据DB0给用户；第二，牺牲可用性，阻塞等待，直到网络连接恢复，数据更新操作完成之后，再给用户响应最新的数据DB1。
上面的过程比较简单，但也说明了要满足分区容错性的分布式系统，只能在一致性和可用性两者中，选择其中一个。也就是说分布式系统不可能同时满足三个特性。这就需要我们在搭建系统时进行取舍了，那么，怎么取舍才是更好的策略呢?
3、取舍策略
CAP三个特性只能满足其中两个，那么取舍的策略就共有三种：
CA 舍弃P
假设不考虑分区（P）的情况下，只有一个分区（副本），副本的一致性自不必说，自然是一致的；可用性方面，一个节点的写入不需要同步到其他节点，可以高效完成。如果增加多个分区（提高分区容错性），数据的写入需要同步到多个节点（强一致性，所有节点同步成功后再返回用户），增加了同步时间和同步失败的可能性，降低了可用性；如果采用弱一致性，即写入操作在主节点成功后即返回用户结果，再通过异步方式同步到多个分区，那么会增加同步失败和数据丢失的几率，降低了一致性。
CP 舍弃A
假设不考虑可用性（A）的情况下，多个分区之间可以采用强一致性的机制，保证数据的高度一致性（要么都成功要么都失败）。比如某个分区出现了故障或者分隔，分区没有了响应，由于放弃了可用性，所以可以无限等待并不断重试直到网络恢复，分区可用后将副本数据同步到所有节点。
AP 舍弃C
假设不考虑一致性（C)的情况下，多个分区和副本可以提供高可用性。分区越多，用户越能就近访问，提供响应速度；放弃了一致性后，副本的写入操作可以写入主节点成功后即可返回成功，获得搞可用性，然后通过异步的方式将副本同步到多个分区节点上。
由此可见，CAP三者确实不能同时满足，只能根据具体的分布式业务场景做取舍和折中；比如银行系统可以牺牲可用性从而保障CP，响应慢一点（甚至网络故障暂停服务）总比账户资金出现错误更优。而很多提供互联网服务可以一定程度牺牲一致性来保障AP，因为互联网竞争激烈，追求的是用户体验和效率，希望用户随时随地能够高效获得服务，而一致性则通过一系列的措施做到最终一致性即可。
参考文章：