漫谈事务与分布式事务(1)- 理解 ACID

简介: 最近看了一点资料,准备写一个大话题。   事务,是所有数据库讲义中最核心的话题。它本质上是一系列连续的,逻辑相关的数据库操作的组合。随便翻开一本书,都会告诉你,事务必须满足下面四个属性:   ACID(Atomic,Consistency,Isolation,Durability)   按照属性即实体的观点:数据库事务就是 ACID,符合 ACID 的就是数据库事务。

最近看了一点资料,准备写一个大话题。

 
事务,是所有数据库讲义中最核心的话题。它本质上是一系列连续的,逻辑相关的数据库操作的组合。随便翻开一本书,都会告诉你,事务必须满足下面四个属性:
 
ACID(Atomic,Consistency,Isolation,Durability)
 
按照属性即实体的观点:数据库事务就是 ACID,符合 ACID 的就是数据库事务。因此我们可以得出一个公式:
 
数据库事务 = ACID
 
抛开课本上那些苦涩难懂的定义,如何理解 ACID ? 
 
首先,我们不用去读 Jim Gray 的《Transaction Processing: Concepts and Techniques》。——为什么数据库能在半个世纪内如此受欢迎,以至于取代了其他的数据存储方式? 显然是因为它能够满足业务的需要。那么业务最需要什么? 
 
数据的可靠性
 
用学术的语言说是数据的“ 完整性约束”——可靠的数据一定是符合“ 完整性约束”的数据。而“ 完整性约束”是什么? 学术语言说“ 完整性约束”是建立在业务数据集上的“ 不变式(Invariant)”。那“ 不变式(Invariant)”又是什么?... 
 
呃。抛开这些学术概念,业务上的数据可靠性可以从两方面理解: 数据首先必须可靠的存储,然后必须可靠的更新。
 
记住,可靠的意义是符合数据的  完整性约束 ——可以简单的看做业务规则。例如,账户金额不能为负,入出账必须平衡都是规则。
 
接下来, ACID 的含义 已经不难理解了:
 
A - 原子化更新。业务操作要么全部完成, 要么全都不做, 不容忍中间状态。
 
C - 事务开始前和结束后,数据的完整性(约束)不会被破坏。注意了,ACID 定义的 Consistency 跟现在大家常说的一致性(数据在分布式节点的一致)不一样,这里采用学术界的原始定义。
 
    这儿再一次提到了  完整性约束。区别是,ACID 把 C 限制在一个事务单元内,强调事务必须保证数据从一个一致性状态进入另一个一致性状态,事务的结束和数据的一致性之间没有时差。
 
I - 事务隔离是业务选择的。数据库定义了 4 种隔离级别:
 
     Read committed
 
    业务的中间状态对外不可见。很容易找到的一个例子是:甲向乙转账,银行先向乙的账户转入 100 元,再从甲的账户扣除 100 元。在银行扣款前,甲、乙的账户里都有 100 元。如果这一中间状态对外可见——甲和乙就有机会都花掉这 100 元,让银行扣款失败,而且没有办法追回。
 
     Repeatable reads / Serializable
 
    这两个级别都在限制事务执行时,其他事务提交的更新是否可见。但是程度不同。Repeatable reads 只限制行,而 Serializable 限制整个数据集。
 
    举个简单的例子来理解:生成业务报表,过程先查询订单明细数据,再查询汇总数据。如果业务在处理完明细数据后,又读到了其他业务修改的订单金额 (这会违反 Repeatable reads),或者又读到了新的订单 (这会违反 Serializable),那么最终得到的汇总数据就会与明细数据不一致,这对于商业敏感的报表是无法接受的。
 
     Read uncommitted
 
    业务的中间状态对外可见,不需要事务隔离。这样看似危险,但不一定会产生业务问题。例如,在一个真实的转账里:银行会先从甲的账户扣除 100 元,再向乙的账户转入 100 元。这样,在乙账户到账前,甲的账户已经扣掉了 100 元。显然,即使这个中间状态对外可见,甲、乙也没有任何机会造成银行转账失败。
 
D - 业务数据不会丢失。事务结束后,除非数据被其他业务更新,否则不应该有变化。
 
理解 ACID
 
在 ACID 里,数据的可靠性是业务的根本需求。
 
如果不满足 A,则业务的一组操作并没有全部完成。比如写入了订单,但是没有写入订单明细,一定会违反业务的数据完整性。
 
而不满足 D,则数据是易变的。昨天写的订单今天也许就找不到了,业务的数据可靠性得不到保证。
 
C 保护数据在事务前后的完整性。这不是必须的,有些业务可以允许时差。继续用上面的转账作为例子:甲向乙转入 100 元,银行先从甲的账户扣除 100 元,承诺明天到账。甲信任银行,认为这是合理的。第二天,银行向乙的账户转入 100 元,结束这笔业务。
 
用户(甲)可以容忍账务临时的不一致。因此,从这个意义来看 C 是场景相关的。
 
最后,I 根据业务场景的需要定义了 4 个隔离级别。有些业务场景需要强 Serializable 的事务隔离,有些场景完全不需要事务隔离。很明显,I 也是场景相关的。
 
结论是 :在 ACID 里,A / D 是基础,而 C / I 看业务场景。
 
最后梳理一下全文的线索:
 
1. 数据库事务 = ACID
2. ACID 的需求是数据可靠性。
3. 保护数据可靠性,A / D 是基础,而 C / I 看业务场景。
 
理解 ACID 就写到这里,下一篇准备开讲数据库 ACID 的实现,敬请期待。

 

目录
相关文章
|
13天前
|
运维 监控 Java
Spring Cloud Alibaba分布式事务问题之事务commit失败如何解决
Spring Cloud Alibaba提供了一套在Spring Cloud框架基础上构建的微服务解决方案,旨在简化分布式系统的开发和管理;本合集将探讨Spring Cloud Alibaba在实际应用中的部署和使用技巧,以及该框架常见问题的诊断方法和解决步骤。
|
8月前
|
Oracle 关系型数据库 分布式数据库
OBCP第五章 分布式事务高级技术-分布式两阶段提交
OBCP第五章 分布式事务高级技术-分布式两阶段提交
74 0
|
8月前
|
Oracle 关系型数据库 MySQL
第四章:OceanBase集群技术架构(分布式事务、MVCC、事务隔离级别)
第四章:OceanBase集群技术架构(分布式事务、MVCC、事务隔离级别)
290 0
|
8月前
|
消息中间件 存储 中间件
常用本地事务和分布式事务解决方案模型 2
常用本地事务和分布式事务解决方案模型
54 1
|
8月前
|
算法 关系型数据库 API
常用本地事务和分布式事务解决方案模型 1
常用本地事务和分布式事务解决方案模型
46 1
|
13天前
|
消息中间件 Dubbo 应用服务中间件
分布式事物【Hmily实现TCC分布式事务、Hmily实现TCC事务、最终一致性分布式事务解决方案】(七)-全面详解(学习总结---从入门到深化)
分布式事物【Hmily实现TCC分布式事务、Hmily实现TCC事务、最终一致性分布式事务解决方案】(七)-全面详解(学习总结---从入门到深化)
94 0
|
8月前
|
SQL OceanBase Python
OBCP第五章 分布式事务高级技术-分布式两阶段提交
OBCP第五章 分布式事务高级技术-分布式两阶段提交
143 0
|
13天前
|
Dubbo 应用服务中间件 微服务
分布式事物【Hmily实现TCC分布式事务、Hmily实现TCC事务、最终一致性分布式事务解决方案】(七)-全面详解(学习总结---从入门到深化)(上)
分布式事物【Hmily实现TCC分布式事务、Hmily实现TCC事务、最终一致性分布式事务解决方案】(七)-全面详解(学习总结---从入门到深化)
57 1
|
13天前
|
消息中间件 Java 关系型数据库
Spring事务与分布式事务
这篇文档介绍了事务的概念和数据库事务的ACID特性:原子性、一致性、隔离性和持久性。在并发环境下,事务可能出现更新丢失、脏读和不可重复读等问题,这些问题通过设置事务隔离级别(如读未提交、读已提交、可重复读和序列化)来解决。Spring事务传播行为有七种模式,影响嵌套事务的执行方式。`@Transactional`注解用于管理事务,其属性包括传播行为、隔离级别、超时和只读等。最后提到了分布式事务,分为跨库和跨服务两种情况,跨服务的分布式事务通常通过最终一致性策略,如消息队列实现。
|
13天前
|
消息中间件 RocketMQ Docker
分布式事物【RocketMQ事务消息、Docker安装 RocketMQ、实现订单微服务、订单微服务业务层实现】(八)-全面详解(学习总结---从入门到深化)
分布式事物【RocketMQ事务消息、Docker安装 RocketMQ、实现订单微服务、订单微服务业务层实现】(八)-全面详解(学习总结---从入门到深化)
58 0