CAP 理论

CAP 是分布式系统中典型的基础理论，它主要表达C/A/P 不存在三全其美的的选择。

CAP 是分布式系统中三个特性的英文首字母组合，分别对应：

• 一致性（Consistency）
• 可用性（Availability）
• 分区容错性（Partition tolerance）

在这个理论中，最多只能同时做到其中的两个特性，要么满足CA、要么满足CP，要么满足AP。同时满足 CAP 是不可能的。

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

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

分区容错性（P）：指分布式系统中的某个节点或者网络分区出现了故障的时候，整个系统仍然能对外提供满足一致性和可用性的服务，也就是说部分故障不影响整体使用。

CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。传统的关系型数据库RDBMS：Oracle、MySQL就是CA。

CP without A：如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

那么真的就不可能完全 CAP 了吗？我们还是要追求 CAP 的，所以在大部分业务系统中使用了策略 “Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）” 来变相的将 CAP 最大化，这就是另外一个 BASE理论。

（END）

最后

以上就是隐形故事为你收集整理的CAP 理论的全部内容，希望文章能够帮你解决CAP 理论所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。