架构师训练营第 6 周——简述 CAP 原理

发布于: 2020 年 07 月 13 日

1. CAP 原理

1998年,加州大学的计算机科学家 Eric Brewer 提出,分布式系统有三个指标:Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性)。它们的第一个字母分别是 C、A、P,Eric Brewer 说,这三个指标不可能同时做到。这个结论就叫做 CAP 定理

  • Consistency(一致性):读操作一定能读到最新的值。

  • Availability(可用性):一个用户请求一定能收到响应。

  • Partition tolerance(分区容错性):分布式系统分布在多个子网络中,当部分子网络出现故障时,分布式系统依然能提供最初设计的一致性或者可用性服务。

任何分布式系统只可同时满足二点,没法三者兼顾。

2. CAP 原理证明

如下图所示,在网络中有两个节点分别为G1和G2,这两个节点上存储着同一数据的不同副本,现在数据是一致的,两个副本的值都为V0,A、B分别是运行在G1、G2上与数据交互的应用程序。

网络节点及数据分布图

在正常情况下,操作过程如下(如下图所示):

  • (1)A将V0更新,数据值为V1;

  • (2)G1发送消息m给G2,数据V0更新为V1;

  • (3)B读取到G2中的数据V1。

正常情况

如果发生网络分区故障,那么在操作的步骤(2)将发生错误:G1发送的消息不能传送到G2上。这样数据就处于不一致的状态,B读取到的就不是最新的数据,如下图所示。

网络分区故障

如果我们采用一些技术如阻塞、加锁、集中控制等来保证数据的一致,那么必然会影响到系统的可用性和分区容错性。

3. 常见 NoSQL 的 CAP 归类

CAP三个特性只能满足其中两个,那么取舍的策略就共有三种:

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

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

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

4. 参考资料

发布于: 2020 年 07 月 13 日 阅读数: 7
用户头像

在野

关注

还未添加个人签名 2012.03.11 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第 6 周——简述 CAP 原理