高并发架构系列:详解分布式一致性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等。欢迎留言交流,专用于学习交流技术、分享面试机会,拒绝广告,我也会在群内不定期答题、探讨。

觉得有用请点赞支持。

相关文章
|
6月前
|
关系型数据库 Apache 微服务
《聊聊分布式》分布式系统基石:深入理解CAP理论及其工程实践
CAP理论指出分布式系统中一致性、可用性、分区容错性三者不可兼得,必须根据业务需求进行权衡。实际应用中,不同场景选择不同策略:金融系统重一致(CP),社交应用重可用(AP),内网系统可选CA。现代架构更趋向动态调整与混合策略,灵活应对复杂需求。
|
9月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
158 2
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
8月前
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
1207 3
|
6月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
6月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
452 1
|
7月前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
10月前
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
491 61
|
10月前
|
关系型数据库 MySQL 分布式数据库
Super MySQL|揭秘PolarDB全异步执行架构,高并发场景性能利器
阿里云瑶池旗下的云原生数据库PolarDB MySQL版设计了基于协程的全异步执行架构,实现鉴权、事务提交、锁等待等核心逻辑的异步化执行,这是业界首个真正意义上实现全异步执行架构的MySQL数据库产品,显著提升了PolarDB MySQL的高并发处理能力,其中通用写入性能提升超过70%,长尾延迟降低60%以上。
|
10月前
|
缓存 NoSQL 算法
高并发秒杀系统实战(Redis+Lua分布式锁防超卖与库存扣减优化)
秒杀系统面临瞬时高并发、资源竞争和数据一致性挑战。传统方案如数据库锁或应用层锁存在性能瓶颈或分布式问题,而基于Redis的分布式锁与Lua脚本原子操作成为高效解决方案。通过Redis的`SETNX`实现分布式锁,结合Lua脚本完成库存扣减,确保操作原子性并大幅提升性能(QPS从120提升至8,200)。此外,分段库存策略、多级限流及服务降级机制进一步优化系统稳定性。最佳实践包括分层防控、黄金扣减法则与容灾设计,强调根据业务特性灵活组合技术手段以应对高并发场景。
2649 7

热门文章

最新文章