初识分布式事务

本文介绍了分布式事务的基础概念,包括事务的ACID属性、本地事务和分布式事务的差异。分布式事务因网络环境的复杂性而变得更加困难,需要处理跨JVM进程和跨数据库实例的情景。CAP理论作为分布式事务的基础理论,阐述了在一致性、可用性和分区容忍性之间必须作出的权衡。在分布式系统设计中,通常会选择牺牲强一致性以保证可用性和分区容忍性,实现最终一致性。
摘要由CSDN通过智能技术生成

在这里插入图片描述

一、基础概念

1.1 事务简介

  事务可以看做是一次大的活动,它由不同的小活动组成,这些活动要么全部执行成功,要么全部执行失败。事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元,组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交,只要其中任一操作执行失败,都将导致整个事务的回滚。简单地说,事务提供一种“ 要么什么都不做,要么做全套(All or Nothing)”机制。
在这里插入图片描述

1.2 事务的特性

  事务是基于数据进行操作,需要保证事务的数据通常存储在数据库中,所以介绍到事务,就不得不介绍数据库事务的特性。事务的特性(通常被称为ACID属性)以及隔离性是数据库管理系统(DBMS)中非常重要的概念,它们确保了数据的一致性和完整性。其中,事务的特性如下表所示:

特性 说明
原子性(Atomicity) 事务是一个原子操作单元,其对数据的所有操作要么全都执行,要么全都不执行。
这意味着,如果事务中的某个操作失败,那么整个事务都会回滚到初始状态,就像没有执行过一样。
一致性(Consistency) 事务必须使数据库数据从一个一致性状态变换到另一个一致性状态。
这意味着,在事务开始之前和结束之后,数据库的完整性约束必须被满足。
隔离性(Isolation) 多个事务并发执行时,一个事务的执行不应影响其他事务。
也就是说,每个事务都应该在自己的独立空间中执行,并且不受其他并发事务的干扰。
持久性(Durability) 事务完成之后,该事务对数据的更改会持久到数据库,且不会被回滚。
一旦事务提交,则其结果就是永久性的,即使系统崩溃也不会丢失。

  而事务的隔离性是确保并发事务不会相互干扰的关键属性。在数据库系统中,多个事务可能同时运行,如果不进行适当的隔离,它们可能会互相影响,导致数据不一致或其他问题。隔离性通常通过锁(locking)和多版本并发控制(MVCC)等技术实现,锁可以确保在事务访问数据期间,其他事务不能修改这些数据。而MVCC则允许每个事务看到数据的一个一致的快照,即使其他事务正在修改数据。
  为了解决数据库中事务并发所产生的问题,在标准SQL规范中,定义了事务隔离级别,每一种级别都规定了一个事务中所做的修改,哪些在事务内和事务间是可见的,哪些是不可见的。隔离级别决定了事务在多大程度上被隔离,不同的数据库管理系统提供了不同的隔离级别,包括:

隔离级别 说明
读未提交(ReadUncommitted) 是最低的隔离级别,一个事务可以读取另一个未提交事务的修改,这可能导致脏读、不可重复读和幻读。
读已提交(ReadCommitted) 这是大多数数据库系统的默认隔离级别。
它只能读取已经提交的数据。这可以防止脏读,但可能出现不可重复读和幻读。
可重复读(RepeatableRead) 在同一事务内,多次读取同一数据返回的结果是一样的。这可以防止脏读和不可重复读,但可能出现幻读。
串行化(Serializable) 这是最高的隔离级别。
它通过对事务进行排序,使之不可能相互冲突,从而解决脏读、不可重复读和幻读问题,但这也可能导致性能下降。

  低级别的隔离级一般支持更高的并发处理,并拥有更低的系统开销。选择合适的隔离级别需要权衡并发性能和数据一致性的需求,不同的应用场景可能需要不同的隔离级别。

1.3 本地事务

  在计算机系统中,更多的是通过关系型数据库来控制事务,这是利用数据库本身的事务特性来实现的,因此叫数据库事务。由于应用主要靠关系数据库来控制事务,而数据库通常和应用在同一个服务器,所以基于关系型数据库的事务又被称为本地事务。尤其对于数据库而言,为了数据安全,提供了以下的几个步骤来完成本地事务的提交以及回滚:

transaction begin
-- insert/delete/update
-- insert/delete/update
-- ...

-- 成功,则提交
transaction commit
-- 失败,则回滚
transaction rollback

  传统的单体应用通常会将数据全部存储在一个数据库中,会借助关系型数据库来完成事务控制。尤其某些业务之间存在强依赖性、强耦合性,数据需要保持特别严苛的强一致性。比如购买功能:我们购买对应的商品,一部分需要扣除我们的余额,余额扣减后商家就安排相应的发货。如果不使用事务,比如第一步扣减余额出现问题,后面商家就直接发货了。再或者余额扣了,商家发货执行失败。无论哪种情况出现,都会造成巨大的缺陷,要不就是客户付钱不发货,要不就是客户不付钱却收到了货,这两种无论出现哪种问题后果都将会是致命的。所以我们需要事务控制,把两者作为一个整体,要不两者同时成功,要不全部失败;不可能出现一个成功,一个失败的情况。

1.4 分布式事务

  随着互联网的快速发展,软件系统由原来的单体应用转变为分布式应用,分布式系统会把一个应用系统拆分为可独立部署的多个服务,因此需要服务与服务之间远程协作才能完成事务操作,这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务。例如电商项目中用户下单,此时就需要订单系统和库存系统协同来完成整个下单操作,即首先调用订单系统添加订单,然后调用库存系统扣减库存。
  这里强调的是多个系统通过网络协同完成一个事务的过程,并不强调多个系统访问了不同的数据库,即使多个系统访问的是同一个数据库也是分布式事务。 如下图两种形式都属于分布式事务:

创建订单
订单系统
订单数据库
库存系统
库存数据库
创建订单
订单系统
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

独泪了无痕

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值