MySQL 可重复读，差点就让我背上了一个 P0 事故！

最新推荐文章于 2024-08-20 15:46:16 发布

Java斗帝之路

最新推荐文章于 2024-08-20 15:46:16 发布

阅读量487

点赞数

文章标签：事务 java MySQL redis 数据库

本文链接：https://blog.csdn.net/Java0258/article/details/106522148

版权

本文通过一个真实的生产事件，讲述了在MySQL中由可重复读（RR）事务隔离级别引起的并发问题，导致余额多扣。在分析过程中，介绍了MVCC、一致性视图、当前读和快照读等概念，揭示了事务隔离等级改变对并发查询结果的影响，以及如何避免此类问题的发生。

摘要由CSDN通过智能技术生成

P0 事故：余额多扣！

这是一个真实的生产事件，事件起因如下：

现有一个交易系统，每次产生交易都会更新相应账户的余额，出账扣减余额，入账增加余额。

为了保证资金安全，余额发生扣减时，需要比较现有余额与扣减金额大小，若扣减金额大于现有余额，扣减余额不足，扣减失败。

账户表（省去其他字段）结构如下：

CREATE TABLE `account`
(
    `id`      bigint(20) NOT NULL,
    `balance` bigint(20) DEFAULT NULL,
    PRIMARY KEY (`id`)

) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4
  COLLATE = utf8mb4_bin;
复制代码

扣减余额时，sql 语序如下所示：

更新余额 sql 语序

ps:看到上面的语序，有没有个小问号？为什么相同查询了这么多次？

其实这些 SQL 语序并不在同个方法内，并且有些方法被抽出复用，所以导致一些相同查询结果没办法往下传递，所以只得再次从数据库中查询。

为了防止并发更新余额，在 t3 时刻，使用写锁锁住该行记录。若加锁成功，其他线程的若也执行到 t3,将会被阻塞，直到前一个线程事务提交。

t5 时刻，进入到下一个方法，再次获取账户余额，然后在 Java 方法内比较余额与扣减金额，若余额充足，在 t7 时刻执行更新操作。

上面的 SQL 语序看起来没有什么问题吧，实际也是这样的，账户系统已经在生产运行很久，没出现什么问题。但是这里需要说一个前提，系统数据库是 Oracle 。

但是从上面表结构，可以得知此次数据库被切换成 MySQL，系统其他任何代码以及配置都不修改（sql 存在小改动）。

就是这种情况下，并发执行发生余额多扣，即实际余额明明小于扣减金额，但是却做了余额更新操作，最后导致余额变成了负数。

下面我们来重现并发这种情况，假设有两个事务正在发执行该语序，执行顺序如图所示。

注意点：数据库使用的是 MySQL，默认事务隔离等级，

最低0.47元/天解锁文章