分布式事务

本文详细介绍了事务的ACID特性,特别是原子性、一致性、隔离性和持久性,并以MySQL为例阐述了如何通过回滚日志和重做日志实现这些特性。此外,讨论了事务并发可能引发的问题,如脏读、不可重复读和幻读,以及MySQL的隔离级别。最后,文章探讨了2PC两阶段提交协议及其存在的问题,并提到了基于XA协议的分布式事务解决方案。
摘要由CSDN通过智能技术生成

分布式事务

一、什么是分布式事务

1.1 事务是什么?

事务:指作为单个逻辑工作单元执行一系列操作,要么完全地执行,要么完全地不执行

1.2 本地事务

本地事务也称为数据库事务,在操作前开启事务在操作完提交事务,出现异常就回滚,一次事务只连接一个数据库

1.3 事务的四大特性

ACID

原子性:一组操作要么全部成功,要么全部失败

一致性:保证数据的安全,数据的修改和预期一致

隔离性:事务之间相互隔离,不会互相影响

持久性:事务提交后,数据就持久到磁盘上,就不会改变了(当前事务就不会再去改变数据了)

1.3.1 Atomicity 原子性
Mysql如何实现原子性的?

利用Innodb的undo log ,undo log名为回滚日志,是实现原子性的关键,当食物回滚时能够撤销所有已经成功执行的SQL语句,它需要记录你要回滚的相应日志信息

例如,当你delete一条数据时候,如果回滚就会insert一条数据

1.3.2 Consistency 一致性

是数据库从一个有效状态切换到另一个有效状态,要求任何写到数据库的数据必须满足预先定义的额规则,就是在任何时间点都不能出现违反了一致性的要求状态

1.3.3 durability 持久性

持久性属性保证一旦事务提交,即是在断电 崩溃等清空下数据也不会丢失,undolog实现了原子性,redolog实现了事务的持久性

redoLog记录的新数据的备份,在事务提交之前,只要将redolog持久化即可,不需要数据持久化,当系统崩溃时,虽然数据没有持久化,但是redolog已经持久了,系统可以根据redolog的内容,将所有数据恢复到最新的状态

undolog+redolog事务的简化过程,例如:

需求:A:1—–>3 B:2—–>4

  • 开启事务
  • 将原来数据记录到redolog中
  • 将操作记录到undolog中
  • 执行操作
  • 提交事务
1.3.4 Isolation 隔离性

隔离性确保数据的并发执行,要求如果两个事务修改同一个数据,必须按照顺序执行,并且前一个事务如果未完成,那么未完成的中间状态对另一个事务不可见.

SQL标准定义了四种隔离级别Mysql全部都支持

  • 读未提交(read uncommit):读取其他事务的未提交数据
  • 读提交(read commit):读取其他事务已经提交的数据
  • 可重复读:
  • 串行化:是隔离级别中的最好的,可以解决并发问题,但是效率低

事务并发带来的问题

  • 脏读

读取到了其他事务未提交的数据,未提交意味着数据可能回滚,也可能是最终不会修改到数据库中,也就是读取到了不存在的数据,这就是脏读.

如果我们的隔离级别为读未提交就可能发生脏读

我们可以改为读提交,就可以解决脏读问题

  • 幻读

事务A按照一定的条件进行数据读取,期间事务B插入了相同搜索条件的新数据,事务A再次按照原先条件进行读取时,发现了事务B插入的数据称为幻读, 即事务的两次读取相同条件的数据读取到数据数量可能不一样

Mysql的可重复度隔离级别做了间隙锁,避免了幻读

  • 不可重复读

可重复读是指在一个事务内,最开始读到的数据和事务结束前的任意时刻读到的数据都是一致的

反之,不可重复度就是一个事务多次读取到的数据是不一致的,通常针对数据更新操作

将隔离级别设置为可重复度,这是mysql的默认隔离级别

小结:

隔离级别脏读不可重复度幻读
读未提交可能可能可能
读提交不可能可能可能
可重复读不可能不可能可能
串行化不可能不可能不可能

Mysql的事务隔离其实是通过锁来实现的,加锁自然会造成性能的损失,读未提交是不加锁,所以它的性能是最好的,但是安全性也是最低

锁和MVCC机制

MVCC的全称是多版本并发控制,这项技术使得InnoDB的事务隔离级别下执行一致性操作有了保证,一个行记录数据有多个版本快照数据,每个事务操作的是自己的快照版本,通过不同的粒度进行快照就可以实现 读提交 可重复读隔离级别

二、常见分布式事务分解决方案

2.1 什么是2pc?

2PC即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段和提交阶段,

在第一阶段,事务管理器与资源管理器先发送准备请求,大家都OK了就进入第二阶段,统一提交

缺陷

  • 如果在第一阶段 不回应协调者就会阻塞

  • 如果协调器宕机了,事务就阻塞了

2.1.2 基于XA协议的两阶段提交方案

2PC的传统方案是在数据库层面实现的,如Oracle,Mysql都支持2PC协议

DTP模型定义

  • AP:即应用程序,

  • TM:事务管理器:负责协调和管理事务

  • RM:资源管理器

  • 全局事务是指分布式事务处理环境中,需要操作多个数据库共同完成一个工作,这个工作室一个全局的事务

  • DTP模型定义TM和RM之间通信的接口规范就是XA,简单来说数据库的提供2PC接口协议,基于数据库的XA协议来是实现XA方案

三个角色之间的交互方式

TM向AP提供应用程序编程接口,Ap通过TM提交及回滚事务

TM交易中间件通过XA接口

例如 注册功能:往用户库insert用户 在积分库insert积分信息

使用TM通知用户RMinsert数据,通知积分RMinsert数据,两种都成功之后,锁定资源,返回结果给TM,最后再统一提交数据

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值