CAP定理有关概念与思考

 

引言

传统的系统所有的功能集中在一个应用上。如果将其单个应用比喻成某一个人，相当于这个人单独完成了所有工作。

然而随着互联网的发展，业务功能和用户量越趋于庞大。单个应用承载能力有限，拓展性差。分布式架构逐渐流行，通俗的理解就是之前一个人做的工作，现在分给若干个人一起干。

那么问题来了，一个人的时候做事情的时候，自己明白就行了，不需要沟通成本。然而团队合作，一定会产生沟通协作问题。

而CAP理论就是为了处理分布式架构中应用之间的通信问题。

 

概述

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统应有三个指标。

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

它们的第一个字母分别是 C、A、P。

Eric Brewer 认为，这三个指标不可能同时满足，最多只能满足两个。这个结论就叫做 CAP 定理。

为什么CAP定理不能同时满足呢？我们先说下C、A、P的概念，然后在分析这个问题。

 

概念

Consistency(一致性)

分布式系统中，用户U1对A服务对某条数据VO进行写的操作之后，用户U2对B服务读取OV，应返回A系统修改过的值。

Availability(可用性)

意思是只要收到用户的请求，服务器就必须在规定时间给出回应。

Partition tolerance（分区容错）

即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。

 

CAP取舍策略

根据CAP三个特性只能满足其中两个，取舍策略便分为一下三种：

CA without P：

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

CP without A：

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

AP wihtout C：

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

 

思考

Consistency和Availability的对立问题

为了保证一致性，当U1在A应用中对VO进行写操作时，需锁定用户在B应用中对VO的读操作和写操作。只有当A系统对VO写操作提交成功后，并且B应用同步VO数据后，才能重新开放读写。

然而，在同步期间，总是存在时间消耗，甚至出现网络故障，同步失败。为了保证一致性，期间需须锁定B 应用对VO读写，从而造成B应用在此时间区间内无可用性。

如果保证B应用的可用性，那么势必不能锁定，从而在并发中无法保证VO的一致性。

 

对CAP的质疑

任何事物在发展过程中，总会存在质疑，这是一种好的表现。当很多架构师把CAP当作圣经的时候，部分研究者也对CAP提出了各种质疑。CAP的概念相对来说并不复杂，但对应到不同的场景又是模糊的，与一些实际场景并不能十分契合，它更加适合基于原子读写的NoSQL场景。

当然质疑本身不是目的，而是弄清问题的一种手段。而作为开发者，CAP三者俨然已成为系统设计中不得不考虑的问题。

 

参考资料：

CAP 定理的含义 ——阮一峰
CAP理论——纯粹的码农
CAP原则(CAP定理)、BASE理论——duanxz