分布式系统CAP理论

栏目: 数据库 · 发布时间: 6年前

内容简介:在单机的数据库系统之中,我们很容易实现一套满足ACID 特性的 事务处理系统, 事务的一致性不存在问题。 但是在分布式系统之中,由于数据分布在不同的主机结点上,如何对着些数据进行分布式的事务处理就具有非常大的挑战,CAP 理论的出现,让我们对于分布式事务的一致性有了另外一种看法。在计算机科学理论,CAP 理论 (也称Brewer 定理) 又有称为 CAP原则,CAP定理,是由计算机科学家Eric Brewer 在 2000 年 提出的 ,其理论观点是, 在分布式计算机系统中,不可能存在同时提供 以下全部三

在单机的数据库系统之中,我们很容易实现一套满足ACID 特性的 事务处理系统, 事务的一致性不存在问题。 但是在分布式系统之中,由于数据分布在不同的主机结点上,如何对着些数据进行分布式的事务处理就具有非常大的挑战,CAP 理论的出现,让我们对于分布式事务的一致性有了另外一种看法。

什么是CAP 理论?

在计算机科学理论,CAP 理论 (也称Brewer 定理) 又有称为 CAP原则,CAP定理,是由计算机科学家Eric Brewer 在 2000 年 提出的 ,其理论观点是, 在分布式计算机系统中,不可能存在同时提供 以下全部三个保证。

  • Consistency(一致性): 所有节点同一时间看到的是相同的数据。在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)
  •  Availability(可用性):不管是否成功,确保每一个请求都能接收到响应。在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)
  • Partition tolerance(分区容错性):系统任意分区后,在网络故障时,仍能操作。以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。

CAP原则是NOSQL数据库和分布式系统的基石。

为什么说CAP 只能三选二?

举个栗子:

下图 显示了在一个网络中,N1,N2 是两个节点,他们共享数据块V  其中一个 值V0, 运行在N1 的A 程序可以认为是安全的,无Bug,可预测的和可靠的,运行在N2 的是B 程序,在这个例子中,A 将写入V的新值。而B从V 中读取值。

分布式系统CAP理论

系统预期执行下面的操作:

  1. 写入一个V 的新值 V1 。
  2. 然后消息(M) 从N1 更新V 的副本到N2.
  3. 从B 处读取返回的V1 

分布式系统CAP理论

如果网络是分区的,当N1到N2 的消息不能传递的时候,就会出现虽然N2 能访问到V 的值(可用性),但是实际上与N1 的V 值已经不一致了。  如下图:

分布式系统CAP理论

CAP 常见模型:

既然 CAP 理论已经证明一致性,可用性和分区容错性三者不可能通知达成。 那么在实际应用中,我们可在其他某一方面来放松条件,从而达到妥协,下面是一些常用的模型。

  1.    牺牲分区 (CA  模型)

牺牲分区容错性意味着把所有机器搬到一台机器内部,或者放到一个“要死一起上死”的机架上面(机架也可能出现部分失效),这明显就违背了我们希望的可伸缩性。

常见例子:

  • 单站点数据库
  • 集群数据库
  • LDAP
  • xFS 文件系统

实现方式:

两阶段提交, 缓存验证协议。

2. 牺牲可用性(CP 模型)

牺牲可用性意味着一旦系统出现分区这样的错误, 系统就直接停止服务。

常见例子:

  • 分布式数据库
  • 分布式锁定
  • 绝大部分协议

实现方式:

悲观锁, 少数分区不可用。

3 . 牺牲一致性(AP 模型)

常见例子:

  • Coda
  • Web缓存
  • DNS

实现方式:

到期/租赁, 解决冲突, 乐观。

CAP 的意义:

在系统架构时,应该是根据具体的业务场景来权衡CAP, 比如 对于大多数互联网应用来说(如门户网站),因为 机器数量庞大,部署结点分散,网络故障是常态的,所以可用性是必须的所以只有舍弃一致性来保证服务的AP 而对于银行等需要确保一致性的场景,通常会权衡CA, 和CP 模型。

CAP 的最新发展:

Eric Brewer 在2012 年发表文章指出了CAP里面三选二的做法存在一定的误差性,主要体现在:

  • 由于分区很少发生,那么在系统中不存在分区的情况下,没有什么理由牺牲C或A 。
  • C与A 之间的取舍可以在同一系统内以非常细小的粒度反复发生,而每一次的决策可能因为具体的操作,乃至因为牵涉特定的数据或用户而有所不同。
  • 这三种性质都可以在一定程度上衡量,并不是非黑即白的有或无。可用性显然是在0% 到100% 之间连续变化的,一致性分很多级别,连分区也可以细分不同的含义,如系统内的不同部分对于是否存在分区可以有不一样的认知。

理解CAP 理论最简单的方式 是想象两个节点分处于分区两侧,允许至少一个节点更新状态会导致数据不一致,即丧失了C 性质,如果为了保证数据的一致性,将分区一侧的节点设置为不可用, 那就丧失了A 性质,除非两个节点可以相互通讯,才能既保证A 又保证C ,但这又会丧失P 性质,一般来说 跨区域的系统,设计师无法舍弃P 性质,那么就只能在数据一致性和可用性上做一个艰难选择, 不确切的说,NoSQL 运动的主题其实是创造各种可用性优先,数据一致性其次的方案,而传统数据库坚守ACID 特性,做的是相反的事情。

BASE :

BASE 来自于互联网的电子商务领域的实践,它是基于CAP 理论逐步演化而来的,核心思想是即便不能达到强一致性,但可以根据应用特点采用适当的方式来达到最终一致性的效果。BASE 是对CAP 中C和A 的延伸。 其含义如下 :

  1. Basically Available  基本可用
  2. Soft state 软状态/柔性事务,即状态可以有一段时间的不同步。
  3. Eventual consistency  最终一致性。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Clean Architecture

Clean Architecture

Robert C. Martin / Prentice Hall / 2017-9-20 / USD 34.99

Practical Software Architecture Solutions from the Legendary Robert C. Martin (“Uncle Bob”) By applying universal rules of software architecture, you can dramatically improve developer producti......一起来看看 《Clean Architecture》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

SHA 加密
SHA 加密

SHA 加密工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具