什么是CAP原理

维基百科的描述:

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

• 一致性（Consistency） （等同于所有节点访问同一份最新的数据副本）

• 可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）

• 分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。）



CAP这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。

Consistency 一致性

Consistency , 强调数据的一致性,对于大多数WEB应用，并不需要强一致性，可以牺牲一部分一致性换取高可用，这也是目前分布式数据库的方向。牺牲一致性，并不是不管数据一致性，而是不再要求像关系型数据库中的强一致性，而是只要求系统能达到最终一致性，保障 “用户感知到一致性” 。

一致性 ，分为客户端和服务端两个不同视角。从客户端看，一致性主要指多并发访问更新过的数据如何获取的问题。服务端视角，则是单点的数据更新如何复制到整个系统，保障数据最终一致性。从并发读写的场景来分析，一致性问题可以分为 强一致性、弱一致性、最终一致性；

强一致性：客户端多进程并发访问，对于关系性数据库，更新过的数据能被后续的访问都能看到，称之为强一致性；

弱一致性：更新过的数据容忍后续部分或者全部访问不到，则为弱一致性；

最终一致性：更新数据，经过一段时间后后续的访问能够获取到，为最终一致性；



Availability 可用性

对于任何从客户端发送到分布式系统的数据读取请求，都一定会收到非错误的数据，但不保证客户端收到的数据一定是最新的数据。即指服务能正常响应请求，不会出现访问失败或者超时等用户体验不好的情况；

相关联的解决方案如:分布式数据冗余、负载均衡；



Partition Tolerance 分区容错性

即分布式系统出现某节点、网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务，这里需要对一致性和可用性进行取舍。

要么牺牲一致性，响应就的数据给客户端；要么牺牲可用性，直到服务恢复后在给用户响应最新数据；



CAP的权衡

既然无法同时满足C一致性、A可用性、P分区容错性，有以下三种模型进行取舍：

1. CA ：不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。

2. CP ：不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。

3. AP ：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。NoSQL都属于此类。



基于以上对于分布式系统而言，P是必然要求的，因此大多数情况下为CP、AP两种模型，在C和A之间镜像权衡；