CAP概述

CAP到底是什么?

在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

• 一致性（Consistency） （等同于所有节点访问同一份最新的数据副本）
• 可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）
• 分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。）

也就是著名的CAP三选二。因为这个定理有实际的理论支撑、并被学术界广泛认可，所以大家一定要记住，CAP全有的情形是不存在的。实际上，因为定理在中文的翻译下容易让人产生误解，所以很多人会以为，只要在分布式情形下，就算什么也不做，系统都可以保证至少有两个属性，或者我们可以任意选择其中两种属性。但是，其实，就算不发生分区情形，想在分布式系统内部实现CA，也是很难、很复杂的。比如，以前的Servlet都是将用户的Session存在服务器上的，这个时候如果要将单机服务器扩展到集群情形，那怎么保证用户的Session在每台机器上都是一致的呢？这个时候，要么需要应用自己去做额外的同步协调工作，要么只能想办法让用户的请求只打到同一台机器上。因为这种问题的存在，为了实现服务的扩展性，所以现在都是将服务做成无状态的。用户的Session之类的管理丢给分布式缓存（redis、memcache）等来处理，由已经实现了对CA的支持的分布式KV组件来帮忙处理这些让人难受的问题。

大白话：
分区容错性P其实就是每个服务都会有多个节点（一般都是主从），这样就可以保证此服务的一个节点挂了之后，此服务的其他节点依然可以响应，其实这就是分区容错性。
但是一个服务有多个节点之后，一个服务的 多个节点之间 的数据为了保持一致性就要进行 数据复制 ，在此过程中就会出现数据一致性C（强一致性）的问题。 (数据一致性包含强一致性，弱一致性，最终一致性，这里指的是强一致性)
如果一定要保持一致性C，可以不做分区，即每个服务都是单节点，这样就不用考虑数据一致性问题了，但是每个服务只有一个节点，此节点挂了，此服务就能不可用了，分区就不能容错了，那就不是高可用分布式系统了，所以一般分布式系统都必须满足分区容错性P。
在满足了分区容错性P后，想要满足一致性C，一个服务的多个节点之间就必须进行数据复制达到数据一致之后再返回给调用者响应，然而在多个节点数据复制的过程中，可能节点之间会出现网络等问题使得数据复制阻塞或失败导致响应超时，服务调用失败，这就失去了系统的可用性A。
如果不强制满足强一致性，那在服务被调用的时候不用管数据复制的问题，直接返回响应，这就满足了可用性，但是由于此服务的多个节点数据可能没有完成复制，节点数据可能不一致，这就失去了系统的一致性。

结论：一个高可用的分布式系统分区容错性P是一定要满足的，在此基础上，只能满足可用性A或者一致性C