分布式事务?咱先弄明白本地事务再说 - ACID

过去一段时间面试的同学,对于数据库事务,可以按照配置正常使用,但很多都无法讲清楚和理解数据库事务这个东西真正的意义,以及互联网兴起以后,当今数据库在ACID面前面临怎样的问题和抉择。

事务,是各大单机SQL数据库厂商包括Oracle、IBM DB2等,早在上世纪80年代提出的一个解决 数据并发操作处理的模型 ,旨在满足多用户(多线程、进程)对数据操作的场景下,依然能保证逻辑正确执行,状体持久,且各大厂商提出,并在事务实现上都遵循事务的 ACID 4个特性。

回顾ACID

一个模块,是多个独立的功能逻辑的组合,每个功能包含多个操作步骤,包括IO、计算、数据库等操作,必须保证每一步都被执行,且执行正确,这个功能和模块才是可用,可交付的。

那么,如何保证这些操作的完整性,就是Atomic,定义为一个原子操作,全部执行且成功,或者全部失败都不执行(回滚),原子操作如果成功,那状态就必须持久,被称为数据库的Durability,持久性。

原子性A、持久性D,这俩个都比较好理解,定义了事务的边界,行为的开始和行为的结束。

A、D定义了事务的边界,那一致性C、隔离性I,就是对事务中间状态的管理,

一致性,也可以理解为是数据的完整性,数据的有效性,我们举例来说明什么是一致性,以及事务是如何保证一致性的,

  • 一个账户减100,另一个账户加100的时候,程序异常crash了,这时候就出现数据的不一致情况,破坏了有效性,这个问题可以由Atomic来保证;
  • 一个原子操作在执行的过程中,涉及多个数据变更的中间状态的保护,例如把A账户减100,在加到B账户完成这个原子操作之前,此时,其他线程对A读的操作就有可能获取到A少100的这个中间状态,这种情况是否允许发生,由Isolation来保证;
  • 数据库延迟约束,例如数据字段的类型、空值、关系、数据范围、主键唯一性等这些合法性的检查都是由Durability来保证,在事务commit时,发现数据不合法,是无法提交成功的。

所以,综上所述,一致性C,是数据状态的正确变换的保证,AID,是实现C的手段,也是我们真正要追求的目标。

而,隔离性I的设定,就是对一致性C不同程度的破坏,事实上,如果我们顺序对数据进行读写,ACD是完全可用保证的,但这样效率会非常的低下,那,我们是要严格的一致性,还是更高的效率,数据库专家们把这个决定权交给了用户,所以,我们看到,ACID当中,只有隔离性I是用户可以选择的,可以自定义的。
隔离性包括 串行读、读已提交、重复读、读未提交 等几种策略,性能由低到高,让用户在不同的使用场景,选择合适的隔离策略,在一致性和性能之间平衡,取得最好的综合表现。

小结

本文主要介绍了事务和事务的几个特性,解释了ACID的由来和之间的关系,

总的来说,ACID的核心是C,大家其实都是为得到C而提出的不同纬度的限制和规范,A确定一个功能的完整性,D对状态负责,I可以说是C的等级系数,不同的I的策略,会出现不同的级别的C,AID是数据库本身的功能特性,C由业务层把控,要严格的C,就设置完整的数据库约束和串行隔离,反之,要宽松的C,就放开数据库的约束,使用读未提交的隔离策略,存在即合理,后者更适用于互联网高并发对一致性要求不高的场景,例如分布式的AP系统,可以保证服务整体的响应时间和服务的可用性。

原文地址:https://www.cnblogs.com/xguo/p/10582648.html

时间: 2024-07-28 19:53:07

分布式事务?咱先弄明白本地事务再说 - ACID的相关文章

本地事务和分布式事务工作实践 【转】

一:从事务的历史说起 知已知彼,百战不败.想了解事务,我们从事务的历史说起. 在Windows平台上,事务的概念最开始出现在关系型数据库中,但是随着.net平台的发展,事务包括的的范围也越来越宽,先一睹为快, 在关系型数据库中的事务是通过begin transaction,rollback transaction, commit 等关键字来实现事务的. BEGIN TRANSACTION  UPDATE [dbo].[T_ACCOUNT] SET BALANCE = BALANCE + @amo

本地事务和分布式事务工作实践

一:从事务的历史说起 知已知彼,百战不败.想了解事务,我们从事务的历史说起. 在Windows平台上,事务的概念最开始出现在关系型数据库中,但是随着.net平台的发展,事务包括的的范围也越来越宽,先一睹为快, 在关系型数据库中的事务是通过begin transaction,rollback transaction, commit 等关键字来实现事务的. BEGIN TRANSACTION  UPDATE [dbo].[T_ACCOUNT] SET BALANCE = BALANCE + @amo

本地事务和分布式事务工作实践 [转]

一:从事务的历史说起 知已知彼,百战不败.想了解事务,我们从事务的历史说起. 在Windows平台上,事务的概念最开始出现在关系型数据库中,但是随着.net平台的发展,事务包括的的范围也越来越宽,先一睹为快, 在关系型数据库中的事务是通过begin transaction,rollback transaction, commit 等关键字来实现事务的. BEGIN TRANSACTION  UPDATE [dbo].[T_ACCOUNT] SET BALANCE = BALANCE + @amo

SQL Server 分布式事务与本地事务

SQL Server 分布式事务与本地事务 @(SQL Server) 背景:之前有项目中出现大量死锁,进行排查后最终发现很多死锁都是由于序列化隔离级别导致,开发针对业务和SQL进行优化后,死锁减少,但是没进行后续研究.最近又有很多项目出现死锁及超时,特别是工作流和待办这块,同样发现都是存在序列化,于是针对这一点进行相关资料查阅及解答. 一. 为什么会出现serializable(序列化) 如果我们程序中定义事务类调用了分布式事务,那么事务的隔离级别默认就是serializable,数据库中即会

终于有人把“TCC分布式事务”实现原理讲明白了!

之前网上看到很多写分布式事务的文章,不过大多都是将分布式事务各种技术方案简单介绍一下.很多朋友看了还是不知道分布式事务到底怎么回事,在项目里到底如何使用. 所以这篇文章,就用大白话+手工绘图,并结合一个电商系统的案例实践,来给大家讲清楚到底什么是 TCC 分布式事务. 首先说一下,这里可能会牵扯到一些 Spring Cloud 的原理,如果有不太清楚的同学,可以参考之前的文章:<拜托,面试请不要再问我Spring Cloud底层原理!>. 业务场景介绍 咱们先来看看业务场景,假设你现在有一个电

从本地事务到分布式事务到微服务下事务

从本地事务到分布式事务到微服务下事务 一.传统本地事务 传统单服务器,单关系型数据库下事务比较简单,完全可用很简单的实现ACID,实际中我们实现一个业务时只需要:开启一个事务-操作数据库-提交/回滚这个事务,这样就完美的实现了一次事务操作,更简单点我们通常会通过spring集成事务直接指定在哪些服务什么样的方法执行什么样的事务即可,更甚至我们业务实现基本都忽略了事务,具体图如下: 二.传统分布式事务 在传统一服务,一个关系数据库架构基础上,随着访问量的增大,单机很明显已满足不了现状,于是我们顺其

java事务——本地事务

本地事务 事务类型 事务可以分为本地事务和分布式事务两种类型.这两种事务类型是根据访问并更新的数据资源的多少来进行区分的.本地事务是在单个数据源上进行数据的访问和更新,而分布式事务是跨越多个数据源来进行数据的访问和更新.在这里要说的事务是基于数据库这种数据源的. JDBC事务 在JAVA中,我们使用JDBC来连接数据库,访问和更新数据.那么在JDBC中是如何实现事务的,事务是被谁来管理的?这个答案当然是数据库,JDBC本身并没有处理事务的能力,而是依赖于底层数据库,底层数据库来提供事务的服务.在

事务-本地事务和全局事务

全局事务:资源管理器管理和协调的事务,可以跨越多个数据库和进程.资源管理器一般使用 XA 二阶段提交协议与“企业信息系统”(EIS) 或数据库进行交互.  本地事务:在单个 EIS 或数据库的本地并且限制在单个进程内的事务.本地事务不涉及多个数据来源.  在Hibernate配置文件中有这么两种配置方式: 1.如果使用的是本地事务(jdbc事务) <property name="hibernate.current_session_context_class">thread&

Reflex框架新特性-本地事务,再也不用担心程序崩溃了!

我们知道程序的可用性或者说健壮性非常重要,如果在用户使用的过程中,出现了程序崩溃,或者数据错误都是灾难性的. 为了最小化出错的概率,我们想各种办法来减错.容错.纠错.不管怎么减错,比如说提高代码质量.测试驱动开发.大量测试等等,但仍不可避免,还是有各式各样的错误出现.尤其是有UI,需要用户参与的话,错误会更多,因为你不知道用户到底是怎么使用应用程序的.所以容错不可避免! 在Java中,错误有两种类型,Error和Exception.我们能处理的主要是Exception.如果要容错,首先需要把错误