高并发架构系列:详解分布式一致性ACID、CAP、BASE及区别

简介: 在面试环节,经常会问CAP、BASE等相关的分布式理论,其实这些名词主要还是来自于分布式的一致性,今天主要介绍分布式一致性:强一致性、最终一致性、ACID、CAP等理论。 分布式一致性的背景 随着分布式事务的出现,传统的单机事务模型(ACID)已经无法胜任,尤其是对于一个高访问量、高并发的互联网分布式系统来说。

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

分布式一致性的背景

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

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

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

数据一致性的由来

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

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

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

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

分布式数据一致性的级别

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关注高可用性。

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

以上就是分布式一致性理论的介绍,更多分布式架构设计:Redis缓存、Dubbo、Kafka、秒杀专题,请参考往期博文:阿里架构师进阶23期精讲:Redis、Kafka、Dubbo、Docker等。欢迎留言交流,专用于学习交流技术、分享面试机会,拒绝广告,我也会在群内不定期答题、探讨。

觉得有用请点赞支持。

相关文章
|
18天前
|
存储 前端开发 调度
Flux 与传统的 MVC 架构模式区别
Flux是一种用于构建用户界面的架构模式,与传统的MVC架构不同,它采用单向数据流,通过Dispatcher统一管理数据的分发,Store负责存储数据和业务逻辑,View只负责展示数据,使得应用状态更加可预测和易于维护。
|
19天前
|
缓存 关系型数据库 MySQL
高并发架构系列:数据库主从同步的 3 种方案
本文详解高并发场景下数据库主从同步的三种解决方案:数据主从同步、数据库半同步复制、数据库中间件同步和缓存记录写key同步,旨在帮助解决数据一致性问题。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
高并发架构系列:数据库主从同步的 3 种方案
|
12天前
|
缓存 负载均衡 网络协议
高并发架构的CDN知识介绍
本文详细介绍了网络请求过程,特别是大型网站架构中DNS和CDN的作用。通过一张常用架构图,文章解释了从客户端请求到服务器响应的全过程,包括DNS解析、负载均衡、CDN加速等关键环节,帮助读者深入了解高并发架构的设计原理和优化方法。
39 1
|
17天前
|
前端开发 测试技术 数据库
DDD架构中assembler和converter的区别
在 DDD 四层架构模式中,assembler 和 converter 常用于对象转换,但两者在实际项目中的使用较为随意。本文从英文释义、语义区分和模型层区分三个方面探讨了两者的区别,建议按模型层区分,即 Interface 和 Application 层使用 assembler,Infrastructure 层使用 converter,以避免混淆和随意使用。此外,将转换代码抽离为独立方法有助于保持代码整洁和可测试性。
52 1
|
25天前
|
存储 分布式计算 负载均衡
分布式计算模型和集群计算模型的区别
【10月更文挑战第18天】分布式计算模型和集群计算模型各有特点和优势,在实际应用中需要根据具体的需求和条件选择合适的计算架构模式,以达到最佳的计算效果和性能。
53 2
|
26天前
|
存储 JavaScript 前端开发
Flux 架构模式和 Redux 区别
Flux架构模式和Redux都是前端状态管理工具,Flux强调单向数据流,通过Dispatcher分发Action到Store,再由View更新;Redux则简化了这一流程,使用单一的全局Store,通过Reducer纯函数处理状态变更,使状态管理更加集中和可预测。
|
1月前
|
NoSQL Java Redis
京东双十一高并发场景下的分布式锁性能优化
【10月更文挑战第20天】在电商领域,尤其是像京东双十一这样的大促活动,系统需要处理极高的并发请求。这些请求往往涉及库存的查询和更新,如果处理不当,很容易出现库存超卖、数据不一致等问题。
47 1
|
1月前
|
缓存 NoSQL Java
秒杀圣经:10Wqps高并发秒杀,16大架构杀招,帮你秒变架构师 (1)
高并发下,如何设计秒杀系统?这是一个高频面试题。40岁老架构师尼恩的读者交流群中,近期有小伙伴在面试Shopee时遇到了这个问题,未能很好地回答,导致面试失败。为此,尼恩进行了系统化、体系化的梳理,帮助大家提升“技术肌肉”,让面试官刮目相看。秒杀系统设计涉及16个架构要点,涵盖业务架构、流量架构、异步架构、分层架构、缓存架构、库存扣减、MQ异步处理、限流、熔断、降级、存储架构等多个方面。掌握这些要点,可以有效应对高并发场景下的秒杀系统设计挑战。
秒杀圣经:10Wqps高并发秒杀,16大架构杀招,帮你秒变架构师 (1)
|
1月前
|
缓存 NoSQL Ubuntu
大数据-39 Redis 高并发分布式缓存 Ubuntu源码编译安装 云服务器 启动并测试 redis-server redis-cli
大数据-39 Redis 高并发分布式缓存 Ubuntu源码编译安装 云服务器 启动并测试 redis-server redis-cli
56 3
|
1月前
|
缓存 Java 数据库
JAVA分布式CAP原则
JAVA分布式CAP原则
61 0