CAP 关键细节点与ACID、BASE的比较

极客时间:《从 0 开始学架构》:想成为架构师,你必须掌握的CAP细节

1、CAP 关键细节点

埃里克·布鲁尔(Eric Brewer)在《CAP 理论十二年回顾:“规则”变了》(http://www.infoq.com/cn/articles/cap-twelve-years-later-how-the-rules-have-changed)一文中详细地阐述了理解和应用 CAP 的一些细节点,提炼如下:

  • CAP 关注的粒度是数据,而不是整个系统。
    在实际设计过程中,每个系统不可能只处理一种数据,而是包含多种类型的数据,有的数据必须选择 CP,有的数据必须选择 AP
    所以在 CAP 理论落地实践时,我们需要将系统内的数据按照不同的应用场景和要求进行分类,每类数据选择不同的策略(CP 还是 AP),而不是直接限定整个系统所有数据都是同一策略。

  • CAP 是忽略网络延迟的。
    布鲁尔在定义一致性时,并没有将延迟考虑进去。也就是说,当事务提交时,数据能够瞬间复制到所有节点,即事物提交时,数据能够瞬间复制到所有节点,但实际情况并非如此。

  • 正常运行情况下,不存在 CP 和 AP 的选择,可以同时满足 CA。
    CAP 理论告诉我们分布式系统只能选择 CP 或者 AP,但其实这里的前提是系统发生了“分区”现象。如果系统没有发生分区现象,也就是说 P 不存在的时候(节点间的网络连接一切正常),我们没有必要放弃 C 或者 A,应该 C 和 A 都可以保证,这就要求架构设计的时候既要考虑分区发生时选择 CP 还是 AP,也要考虑分区没有发生时如何保证 CA。

  • 放弃并不等于什么都不做,需要为分区恢复后做准备。

2、ACID

ACID 是数据库管理系统为了保证事务的正确性而提出来的一个理论,ACID 包含四个约束,分别是:

1.Atomicity(原子性)
一个事务中的所有操作,要么全部完成,要么全部不完成,不会在中间某个环节结束。事务在执行过程中发生错误,会被回滚到事务开始前的状态,就像这个事务从来没有执行过一样。

2.Consistency(一致性)
在事务开始之前和事务结束以后,数据库的完整性没有被破坏。

3.Isolation(隔离性)
数据库允许多个并发事务同时对数据进行读写和修改的能力。隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别,包括读未提交(Read uncommitted)、读提交(read committed)、可重复读(repeatable read)和串行化(Serializable)。

4.Durability(持久性)
事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。

ACID 中的 C 是指数据库的数据完整性,而 CAP 中的 C 是指分布式节点中的数据一致性。ACID 的应用场景是数据库事务,CAP 关注的是分布式系统数据读写。

3、BASE

BASE 是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency),核心思想是即使无法做到强一致性(CAP 的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性。

1. 基本可用(Basically Available)
分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。

2. 软状态(Soft State)
允许系统存在中间状态,而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。

3. 最终一致性(Eventual Consistency)
系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。
BASE 理论本质上是对 CAP 的延伸和补充,更具体地说,是对 CAP 中 AP 方案的一个补充。前面在剖析 CAP 理论时,提到了其实和 BASE 相关的两点:

  • CAP 理论是忽略延时的,而实际应用中延时是无法避免的。
  • AP 方案中牺牲一致性只是指分区期间,而不是永远放弃一致性。

综合上面的分析,ACID 是数据库事务完整性的理论,CAP 是分布式系统设计理论,BASE 是 CAP 理论中 AP 方案的延伸。

原文地址:https://www.cnblogs.com/whiteBear/p/15773436.html