数据库之事务并发访问引起的问题以及如何避免


事务并发访问引起的问题有如下常见的:

  • 更新丢失——mysql所有事务隔离级别在数据库层面上均可避免
  • 脏读——脏读就是允许读取其他事务未提交的数据,READ-COMMITTED事务隔离级别以上可避免(RC级别)。
  • 不可重复读——不可重复读就是事务A多次读取事务B,过程中事务B有更新操作,导致事务A读取的数据不一样,REPEATABLE-READ事务隔离级别以上可避免(RR级别)。
  • 幻读——指的是一个事务在前后两次查询同一个范围的时候,后一次查询看到了前一次查询没有看到过的数据行,就好像发生了幻觉一样,破坏了事务的一致性SERIALIZABLE事务隔离级别可避免,但是会降低事务并发能力。在可重复读隔离级别下(RR),也是可以解决幻读的(但是他的根本职能是解决不可重复读)

一、更新丢失

注:文中的事务就是会话,也是查询,两个事务就开两个查询即可

对于更新丢失的情况我们用一张图表示
在这里插入图片描述
可以看到事务A期望的结果应该是1100元,但是实际结果却是1000元,也就是说事务B的更新丢失了。
但是MySQL所有的隔离级别都能避免更新丢失情况。我们用一个测试说明,建表如下:
在这里插入图片描述
开启两个查询模拟两个事务,这两个事务在操作前需要关闭自动提交:set autocommit = 0;;将隔离级别开到最低的RU级别:set session transaction isolation level read uncommitted;两个都要开始事务:start TRANSACTION;
先是事务1的操作:

# 查询一号的余额,结果为1000
SELECT balance FROM account_innodb where id = 1;

然后事务2开始查询,并操作余额

# 查询一号的余额,结果为1000
SELECT balance FROM account_innodb where id = 1;
# 将一号的余额+100
update account_innodb set balance=1000+100 where id = 1;
# 再次查询余额为1100
SELECT balance FROM account_innodb where id = 1;
# 提交事务
COMMIT;

然后事务1进行操作:

update account_innodb set balance=balance-100 where id = 1;

结果:
在这里插入图片描述
此时并没有提交事务,我们撤销操作,进行回滚,然后查询1号的余额

# 事务回滚,即关闭事务
ROLLBACK;
# 查询余额
SELECT balance FROM account_innodb where id = 1;

在这里插入图片描述
可以看到结果是事务2存入钱后的余额,其他的隔离级别下的更新丢失不再演示

二、脏读

  • 开头我们仍然以上边的两个会话设置为基础,即隔离级别最低,我们看看是不是会发生读取到未提交的事务数据
  • 首先之前两个会话都要commit,保证事务已经结束。下边开始

两个会话开启事务:start TRANSACTION;
然后update account_innodb set balance = balance -100 where id = 1;,更改后的结果为1000,但是我们没有提交,数据库里面并没有真正进行更改,未提交的数据存在redo log文件中,另一个事务查询的话,我们期望的是还是数据库中那个没有变动的数据,我们来测试会话2:

# start TRANSACTION;没有开启事务的记得开启
SELECT balance FROM account_innodb where id = 1;

在这里插入图片描述
可以看到结果为1000,发生脏读了。

如何避免呢?开启RC级别及以上就可以了

# 设置成能防止脏读的read COMMITTED,再按照之前步骤进行测试
set session transaction isolation level read committed;

按照之前来一次
在这里插入图片描述
结果显示正常了

三、不可重复读

  • mysql的默认隔离级别为 repeatable read(RR),该级别就能避免不可重复读。事务1对某一行记录会多次读取,在这些过程中,事务2进来修改了该记录,但是事务1并没有结束事务,然后,事务1再次读取,读到的是事务2提交的结果,这明显不利于当前事务的执行。

我们先基于脏读测试的基础上进行测试,即隔离级别为RC,之前的事务都提交,然后重新开启事务
事务1开启 事务之后执行以下语句

SELECT balance FROM account_innodb where id = 1;

然后事务2执行如下

update account_innodb set balance = balance +200 where id = 1;
# 并提交
commit;

回到事务1

# 再次查询,期望为1100
SELECT balance FROM account_innodb where id = 1;

结果
在这里插入图片描述
说明RC及以下无法避免不可重复读
我们将隔离级别切换到repeatable read级别,将两个会话都切换成RR级别:

set session transaction isolation level repeatable read;

然后再按照上边的步骤测试,上边的结果是1300,那么这次事务1最终结果应该是1300,测试结果为:1300
在这里插入图片描述
说明避免了

四、幻读

基于上边的测试的基础,隔离级别改变read uncommitted,保证事务都已经提交
事务1

# 开启事务后执行范围操作,并上共享锁,锁住查询到的记录行
SELECT balance FROM account_innodb lock in share mode;

在这里插入图片描述

事务2在其之后插入一条数据(可以插入,锁住4行都是行锁,不影响新添数据行)

# 开启事务后执行
insert into account_innodb values ('test5',1200);
# 提交
commit;

在这里插入图片描述
查看account_innodb
在这里插入图片描述

然后我们用事务1进行全范围更新

# 将工资全部改为1000
update account_innodb set balance=1000;
# 查询是否是4条1000的记录
SELECT balance FROM account_innodb;

在这里插入图片描述
很匪夷所思吧,五条记录都被更新(对于事务1来说,不是应该是4条吗?),跟产生幻觉一样,说明在RC级别下产生了幻读。

4.1、RR级别下测试

我们将两个会话隔离级别切换为RR:set session transaction isolation level read COMMITTED;
然后按照之前的方法测试,也是事务1线进行查询,然后事务2进行添加操作,奇怪的事发生了
在这里插入图片描述
被阻塞了,说明RR级别可以避免幻读,这是因为mysql采用了gap lock,详情请见数据库之InnoDB可重复读隔离级别下如何避免幻读

4.2、SERIALIZABLE级别下测试

切换级别set session transaction isolation level SERIALIZABLE;,回滚之前事务ROLLBACK;,按照RR级别下的测试来一遍,到了事务2进行插入的时候:
在这里插入图片描述

五、具体对比图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oAahu7SI-1587702400298)(C:\Users\Taogege\AppData\Roaming\Typora\typora-user-images\image-20200422182835697.png)]

如有问题,请及时指出

  • 2
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
如果两个独立的Spring Boot 应用程序同时访问同一个数据库,可能会出现并发问题并发问题主要包括以下几个方面: 1. 数据一致性问题:当两个应用程序同时对同一条数据进行修改时,可能会导致数据不一致的情况。例如,一个应用程序进行了更新操作,而另一个应用程序也对同一条数据进行了更新,最终只有一个更新操作能够成功,可能会导致数据丢失或冲突。 2. 并发读写问题:当一个应用程序正在对某个数据进行写操作时,另一个应用程序可能同时对同一条数据进行读操作,可能会读取到未完成的写操作的中间状态的数据,导致数据的不准确性。 3. 竞态条件问题:当多个应用程序同时对同一个数据进行操作,并且操作的顺序和时序不确定时,可能会导致意外的结果。例如,两个应用程序同时检查某个资源是否可用,并且根据结果进行操作,但由于时序问题,最终可能导致资源被重复使用或冲突。 为了避免这些并发问题,可以采取以下措施: 1. 数据库事务:使用数据库事务来保证数据的一致性和隔离性。通过对相关操作进行事务管理,可以确保在同一时间只有一个应用程序能够对数据进行修改,并且保证事务的原子性、一致性、隔离性和持久性。 2. 数据库锁机制:使用数据库的锁机制来控制并发访问。可以使用悲观锁或乐观锁来避免并发写入问题,或者使用行级锁或表级锁来保证数据的一致性和隔离性。 3. 缓存机制:使用缓存来减少对数据库并发访问。可以使用缓存来存储常用的数据,减少对数据库的读取操作,从而降低并发读取的问题。 4. 同步机制:在需要同步访问的代码块中使用同步机制,如 synchronized 关键字或 Lock 接口的实现类,确保同一时间只有一个线程能够访问关键代码块,避免并发冲突。 5. 消息队列:使用消息队列来解耦应用程序之间的数据交互。可以将需要同时访问数据库的操作放入消息队列中,由消息队列按序处理,避免并发访问数据库引起问题。 综上所述,虽然Spring Boot应用程序可以同时访问同一个数据库,但需要采取适当的并发控制措施,以避免并发问题的发生。具体选择哪种措施取决于具体的业务需求和场景。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值