浅谈CAP+ACID+BASE理论

1. 背景

在大数据存储系统或者各类分布式系统,为了增加系统高可用性,往往会将同一数据存储多份副本。常规做法是三副本,数据复制成多份,带来了很多好处:

  1. 高可用性:即使因为机器故障、宕机等原因损失一副本,仍然有其他二个副本提供服务
  2. 增加读操作的并发性:比如对于三副本,常用选举算法选出leader-支持读写, 其他两个副本作为Follower可以支持读操作
    带来上述好处的同时,也引入了很多问题,比如:
  3. 同一数据存在多个副本,在并发的众多客户端读/写请求下,如何维护数据一致性
  4. 三副本如何复制数据?在网络分区异常情况下,如何提供服务? 在网络分区结束后,如何处理不一致的数据等等

同时在面试一些候选人过程中,往往候选人会将CAP和ACID一些概念搞混,包括NoSQL系统很流行的时候,引入了BASE理论,本文做一些总结

2. CAP

CAP是“”Consistency/Availability/Partition Tolerance”的一种简称,C:强一致性: 场景是分布式系统中的同一数据,采用多副本设计,对于数据的更新操作体现出的效果与只有单副本是一样的。即虽然是多副本,基于读写语义,我们可以证明在各种情况下,和单副本表现均一致,这是强一致性。换言之,只有能找到一种场景,和单副本表现不一致,那就不是强一致性,不满足C
A: 可用性: 客户端在任何时刻对大规模分布式数据系统的读/写操作保证在有限时间内完成,即使各种故障发生,服务能够在有限时间内提供服务,尽量可用
P: 分区容忍性:网络分区现象,即分区间的机器无法进行网络等

2.1 阶段一:1999

Eric Brewer于1999年首先提出了CAP,同时证明了:对于一个大规模分布式数据系统,CAP三要素不可兼得,含义:同一个系统至多只能实现其中的两个,而必须舍弃第3个要素来保证其他两个要素被满足。即要么AP,要么CP,抑或AC,但是不存在CAP。

证明其实很简单,比如P发生了,即网络分区,在多副本场景下,为了保证C,三副本数据强一致性,那么必然需要等待网络分区恢复,那么不能及时提供服务,不保证A;
如果为了保证A,即尽快服务,那么因为网络分区无法通信,多副本数据无法达成强一致性,即违反了C;其他证明类似

2.2 阶段二:2012

Eric Brewer2012年发表的文章中CAP Twelve Years Later: How the "Rules" Have Change.IEEE Computer Society.2012, 重新阐述了CAP理论,原因是在1999年提出CAP后,因为分布式系统天然P存在,很多设计者,就在AP或者CP选择,Eric Brewer认为系统设计不够完善,存在很多误导性,本次要点总结如下:

  1. 在实际系统中,网络分区(P)出现的概率比较小的,并不是一直存在,并不能因为小概率出现的P,就不考虑A/C, 因为A/C本身其实对于系统很重要。
  2. 分布式数据系统其实很复杂,往往包含很多子系统或者子模块,因此不应该粗粒度地在整个系统级别进行取舍,即整个系统要么取A不考虑C,要么取C不考虑A,因此设计系统更应该更细粒度,比如出现网络分区,某些子系统或者子模块还可以满足AC,或者针对某些核心数据,需要有特殊的设计和考虑
  3. CAP三者并非是二元式地有或没有,而应该是连续变量,因此CAP三个属性都是连续的值,而不是二值选项。Availability可以是0~100,Consistency也可以强弱不同,分区是否发生也并非简单的二值。

3. BASE

大数据环境下的云存储系统,特别是很多NoSQL系统则采纳往往BASE原则。BASE原则是指:
基本可用(Basically Available):大多数时间内系统处于可用状态,即不要求所有时间系统都持续提供状态,但是允许偶尔的系统不服务,比如读写请求失败
软状态或者柔性状态(Soft State): 是指系统的数据不要求在任何时刻都完全保持同步。即在数据处理过程中,允许这个过程,存在数据状态暂时不一致的情况,但是最终数据会一致。
最终一致性(Eventual Consistency)。和强一致性相比,最终一致性是一种弱一致性,不要求如何时刻数据保持一致同步,但是要求在给定的时间窗口内数据达到一致。

4. ACID

ACID是事务的基本属性:

  • 原子性(Atomicity):类似原子操作,是指一个事务全部执行,保证单个事务要不成功,要不失败。不允许一个事务只执行了一半就停止。典型场景:比如用户A给用户B转账,一定不能出现如下场景:A账户少钱了,但是B账户没有增加钱;或者A账户没有扣钱,B账户却增加钱。
  • 一致性(Consistency):事务在开始和结束时,需要始终满足一致性约束条件。比如系统要求A+B=100,那么事务如果改变了A的数值,则B的数值也要相应修改来满足这种一致性要求;
  • 隔离性(Isolation):如果有多个事务同时执行,彼此之间不需要知晓对方的存在,而且执行时互不影响,不允许出现两个事务交错、间隔执行部分任务的情形;
  • 持久性(Durability):事务运行成功以后,对系统状态的更新是永久的,不会回滚撤销,即使宕机也需要有方式恢复

5. 关系

  1. CAP和BASE是一个维度的定义,本身是集中在系统本身,比如CAP的C强一致性,和BASE的最终一致性,都属于(分布式)系统探讨的一致性模型,一致性模块定义很多,这个话题需要单独探讨
  2. ACID本身是事务的属性和基本定义,抛开事务和数据库其实本没有意义。比如ACID的C一致性,更强调数据库从一种合法的状态变迁为另外一种合法状态,需要满足各种约束,比如数据库中定义的完整性约束、Check约束、唯一约束。而CAP的C在存在单副本或者多副本,从客户端的视角来看读写的语义
  3. 但是本身ACID和CAP、BASE又有一定联系,比如目前非常流行的分布式数据库架构,当采用多副本,自然涉及到CAP的定义,而分布式数据库本身也要支持事务,即满足ACID。比如当出现网络分区(CAP的P),ACID的实现也自然受影响和考虑

你可能感兴趣的:(分布式系统与数据库理论,分布式一致性协议,并发编程,分布式)