1、CAP理论

作为分布式系统的基础理论,它描述的是一个分布式系统在以下三个特性中：

一致性（Consistency）
可用性（Availability）
分区容错性（Partition tolerance）
最多满足其中的两个特性。也就是下图所描述的。分布式系统要么满足CA,要么CP，要么AP。无法同时满足CAP。

分区容错性：指的分布式系统中的某个节点或者网络分区出现了故障的时候，整个系统仍然能对外提供满足一致性和可用性的服务。也就是说部分故障不影响整体使用。
事实上我们在设计分布式系统是都会考虑到bug,硬件，网络等各种原因造成的故障，所以即使部分节点或者网络出现故障，我们要求整个系统还是要继续使用的(如果不能再继续使用,相当于只有一个分区,那么也就没有后续的一致性和可用性了)

可用性： 一直可以正常的做读写操作。简单而言就是客户端一直可以正常访问并得到系统的正常响应。用户角度来看就是不会出现系统操作失败或者访问超时等问题。

一致性：在分布式系统完成某写操作后任何读操作，都应该获取到该写操作写入的那个最新的值。相当于要求分布式系统中的各节点时时刻刻保持数据的一致性。

2、为什么没有系统能同时满足CAP?

如果我们事先保证了分区容错性，也意味着若某个节点故障了，用户还是可以继续访问。这时用户在访问过程中就会出现一致性和可用性不能同时满足的情况，参考下图

如图假设分布式系统有G1，G2两个节点，初始值都是v0。现在有一个client向系统写入了值v1，这里假设直接写的是节点G1，G1数据同步到G2的过程中出现了故障，G1节点上的数据还未同步到G2节点，因此客户端读取到的是修改之前的值v0。 这就出现了不满足一致性的情况了。相当于满足了可用性，失去了一致性。

类似的，如果系统保证了强的一致性

那么在client 写完G1节点后, 而G1向G2节点同步数据出现了问题后，client再去读取G2节点的数据时就会一直处于等待状态。这就相当于满足了一致性，而失去了可用性。

考虑多个客户端访问时，一致性和可用性还可以这么理解：假如client1 向G1 修改某个值的时候, 写操作还未完成，client2就发起来对该值的读操作，读的是G2节点，这时如果要满足一致性，那么就得让client2 暂时无法使用，如果要让client2 使用，那么获取到的数据不是最新的，系统就不满足一致性。

3、CAP三者不可兼得，该如何取舍

(1) CA: 优先保证一致性和可用性，放弃分区容错。 这也意味着放弃系统的扩展性，系统不再是分布式的，有违设计的初衷。
(2) CP: 优先保证一致性和分区容错性，放弃可用性。在数据一致性要求比较高的场合(譬如:zookeeper,Hbase) 是比较常见的做法，一旦发生网络故障或者消息丢失，就会牺牲用户体验，等恢复之后用户才逐渐能访问，例如银行微信支付宝转账，对数据准确性要求较高时要满足CP
(3) AP: 优先保证可用性和分区容错性，放弃一致性。NoSQL中的Cassandra 就是这种架构。跟CP一样，放弃一致性不是说一致性就不保证了，而是数据慢慢的更新。例如双十一某火爆商品的实时销量，要满足AP，毕竟，总不能因为实时销量更新不及时就反馈给用户一个异常界面把，那明天的新闻头条就有的写了，至于实时销量，慢慢更新也无妨！