详解分布式一致性ACID、CAP、BASE,以及区别

在阿里Java面试环节,经常会问CAP、BASE等相关的分布式理论,其实这些名词主要还是来自于分布式的一致性,今天主要介绍分布式一致性:强一致性、最终一致性、ACID、CAP等理论。

分布式一致性的背景

随着分布式事务的出现,传统的单机事务模型(ACID)已经无法胜任,尤其是对于一个高访问量、高并发的互联网分布式系统来说。

分布式事务的一致性,请参考:分布式事务的解决方案,以及原理、总结

如果我们要求严格一致性,很可能就需要牺牲掉系统的可用性,反之亦然。

如何构建一个兼顾可用性和一致性的分布式系统成为了无数Java工程师探讨的难题。

 

详解分布式一致性ACID、CAP、BASE,以及区别

数据一致性的由来

一致性(Consistency)一直是分布式系统里一个很重要的话题。

在存储系统中,为了避免数据丢失,我们都会对数据进行持久化。

详解分布式一致性ACID、CAP、BASE,以及区别

对数据进行持久化可以避免宕机带来的数据丢失问题,但是不能解决单机永久性故障的问题。存储系统作为基础设施,在单机上持久化是远远不够的,我们需要将数据复制到多台机器上以提升系统的可用性和可靠性。

详解分布式一致性ACID、CAP、BASE,以及区别

一旦数据被复制到多个节点,那么就产生了一致性的问题。

详解分布式一致性ACID、CAP、BASE,以及区别

分布式数据一致性的级别

1、强一致性

是最强的一致性模型,要求任何读取操作都能读取到最新的值,换句话说,要求任何写入操作立即同步给所有进程。

2、弱一致性

这种一致性级别约束了系统在写入成功后,不承诺立即可以读到写入的值,也不久承诺多久之后数据能够达到一致,但会尽可能地保证到某个时间级别(比如秒级别)后,数据能够达到一致状态。

3、最终一致性

最终一致性是弱一致性的一个特例,系统会保证在一定时间内,能够达到一个数据一致的状态。

这里之所以将最终一致性单独提出来,是因为它是弱一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上比较推崇的模型。

一致性相关的理论

关系式数据库ACID

ACID是数据库(MySQL)事务正确执行所必须满足的四个特性的首字母缩写。

1.Atomicity(原子性)

一个事务的所有操作,要么全部完成,要么全部不完成。

所谓事务,是指由一系列数据操作所组成的完整逻辑过程。比如银行转账事务由两个操作组成:从源账户扣除金额,以及向目标账户增加金额。

2.Consistency(一致性)

指事务开始之前和事务结束之后,数据的完整性约束没有被破坏。

包含两层含义:

a)数据库机制层面,事务执行前后,数据能符合设置的约束,如唯一约束、外键约束;

b)业务层面,由应用开发人员保证业务一致性。还是以银行转账为例,A、B两个账号,转账之前和之后,A、B两个账号余额总额必须一致。

3.Isolation(隔离性)

数据库能够防止由于多个并发事务交叉执行而导致数据的不一致。

4.Durability(持久性)

指事务结束后,对数据的修改是永久的,不会回滚到之前的状态。

CAP理论

在分布式系统中,也有类似数据库ACID的特性,那就是CAP,他们分别是:

1.Consistency 一致性

强调进群节点中数据一致。在分布式中一致性又包括强一致性和弱一致性,强一致性就是指在任何时刻任何节点看到的数据都是一样的;

弱一致性一般实现是最终一致性,即刚开始可能存在差异,但随着时间的推移,最终数据保持一致。

2.Availability 可用性

强调集群在任何时间内都正常使用

3.Partition Tolerance 分区容错性

即使某一部分集群坏掉,另一部分仍能正常工作。

这三个特性只能满足其中两个,牺牲另一个。大部分系统也都是如此:

一般来说分布式集群都会保证P优先,即集群部分节点坏死不影响整个集群的使用,然后再去追求C和A。因为如果放弃P——分区可用性,那不如就直接使用多个传统数据库了。事实上,很多微服务分库分表就是这个道理。

如果追求强一致性,那么势必会导致可用性下降。比如在Master-Slave的场景中,Master负责数据写入,然后分发给各个节点,所有节点都写入成功,才算写入,这样保证了强一致性,但是延迟也会随之增加,导致可用性降低。

因此在可用性和一致性之间,就出现了各种解决方案,如时序一致性、最终一致性等等。

BASE理论

BASE理论是对CAP理论的延伸,核心思想是即使无法做到强一致性(Strong Consistency,CAP的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。

BASE是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency)。

1.基本可用(Basically Available)

基本可用是指分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用。

电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务,这就是损失部分可用性的体现。

2.软状态( Soft State)

软状态是指允许系统存在中间状态,而该中间状态不会影响系统整体可用性。

分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

3.最终一致性( Eventual Consistency)

最终一致性是指系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。

弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。

BASE和ACID代表两种截然相反的设计理念,ACID注重一致性,是传统关系型数据库(MySQL)的设计思路,BASE关注高可用性。

当今大规模、跨数据中心的分布式系统(如云计算)大多同时采用这两种设计理念,并在两者之间寻求平衡。

 

作者简介

陈睿|mikechen,10年+大厂架构经验,大厂资深面试官,就职于阿里巴巴、淘宝、百度等一线互联网大厂。

以上!

关注作者「mikechen」公众号,获取更多架构面试干货!

后台回复架构,即可获取《阿里架构师进阶专题全部合集》,后台回复面试即可获取《史上最全阿里Java面试题总结

评论交流
    暂无讨论,说说你的看法吧