第11课:Spring

第11课:Spring Boot 中的事务配置管理

企业应用中的数据操作在顺序执行的过程中,往往存在各种无法预知的问题。任何一步操作都有可能发生异常,而异常则会导致后续的操作无法完成。业务逻辑没有正确完成,之前操作数据库的动作也就不可靠,这种情况下,我们需要进行数据的回滚。

事务的作用就是保证用户的每一个操作都是可靠的,保证事务中的每一步操作都可成功执行。只要有异常发生,数据便会回退到事务进行任务操作之前的状态。这很好理解,比如转账、购票等业务,只有整个业务流程全部执行完毕才能认为相应事件执行成功,不能钱转到一半,或票款刚付出去,结果系统死了,导致付款人钱没了,而收款人也没能收到这笔钱。

事务管理是 Spring Boot 框架中最为常用的功能之一,实际应用开发时,我们基本上都会在 Service 层处理业务逻辑时加上事务。当然了,有时候由于场景的需要,也可不加事务,比如往一个表里插入数据,数据之间互不影响,这时不能因为某条数据挂了,而把之前插入的数据全部回滚。

Spring Boot 事务配置

接下来,带大家具体了解下 Spring Boot 事务的配置过程,主要包括依赖注入、事务测试两大步骤。

依赖导入

在 Spring Boot 中使用事务,需要导入 MySQL 依赖:

<dependency>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot-starter</artifactId>
    <version>1.3.2</version>
</dependency>

导入了 MySQL 依赖后,Spring Boot 会自动注入 DataSourceTransactionManager,我们不需要其他的任何配置,就可以通过注解 @Transactional 使用事务。关于 MyBatis 的配置,上一篇中已经做了说明,这里使用上一篇中介绍的 MyBatis 配置即可。

事务测试

我们首先在数据库表中插入一条数据:

id user_name password
1 倪升武 123456

然后,我们写一个插入 mapper:

public interface UserMapper {

    @Insert("insert into user (user_name, password) values (#{username}, #{password})")
    Integer insertUser(User user);
}

OK,接下来我们测试一下 Spring Boot 中的事务处理,在 Service 层,我们手动抛出一个异常,来模拟实际中出现的异常。然后,观察一下事务有没有回滚,如果数据库中没有新的记录,则说明事务回滚成功。手动抛出异常的代码如下所示:

@Service
public class UserServiceImpl implements UserService {

    @Resource
    private UserMapper userMapper;

    @Override
    @Transactional
    public void isertUser(User user) {
        // 插入用户信息
        userMapper.insertUser(user);
        // 手动抛出异常
        throw new RuntimeException();
    }
}

我们来测试一下:

@RestController
public class TestController {

    @Resource
    private UserService userService;

    @PostMapping("/adduser")
    public String addUser(@RequestBody User user) throws Exception {
        if (null != user) {
            userService.isertUser(user);
            return "success";
        } else {
            return "false";
        }
    }
}

我们使用 Postman 调用该接口,而程序中抛出的异常,会造成事务回滚。我们刷新一下数据库,发现并没有新增的记录,说明事务生效了。

事务很简单,我们平时使用时,一般也很少出问题,但事实上似乎并非如此……

常见问题总结

从上面的解析可以看出,在 Spring Boot 中使用事务非常简单,一个 @Transactional 注解即可解决问题。话虽如些,但在实际项目中,却有很多小坑在等着我们,这些小坑是我们写代码时不曾注意到的,而且在正常情况下也很难发现它们。可随着项目的扩大,它们一旦引发问题,又是很难排查到的。

这一节,我专门针对实际项目中经常出现的、和事务相关的技术细节做个总结,希望读者读完之后,能够落实到自己的项目中,有所受益。

异常并没有被“捕获”到

首要说的是,异常没有被“捕获”到,而导致事务没有回滚。

我们在编写业务层代码时,或许已经考虑到了异常的存在,也或者编辑器已经提示我们需要抛出异常,但有一点需要注意:并不是说我们把异常抛出来,有了异常事务就会回滚。

@Service
public class UserServiceImpl implements UserService {

    @Resource
    private UserMapper userMapper;

    @Override
    @Transactional
    public void isertUser2(User user) throws Exception {
        // 插入用户信息
        userMapper.insertUser(user);
        // 手动抛出异常
        throw new SQLException("数据库异常");
    }
}

我们看上面这段代码,其实并没有什么问题,手动抛出一个 SQLException 来模拟实际运行中操作数据库发生的异常。在这个方法中,既然抛出了异常,那么事务应该回滚,实际并非如此。读者可以使用我源码中 Controller 接口,通过 Postman 测试一下,就会发现,仍然插入了一条用户数据。

问题出在哪呢?这是因为 Spring Boot 默认的事务规则是遇到运行异常(RuntimeException)和程序错误(Error)才会回滚。比如上面例子中抛出的 RuntimeException,可完成回滚,而抛出 SQLException,则无法回滚。针对非检测异常,如果要进行事务回滚,可以在 @Transactional 注解中使用 rollbackFor 属性指定异常,比如 @Transactional(rollbackFor = Exception.class),这样就没有问题了。这也在告诉我们,实际项目开发中,一定要指定异常。

异常被“吃”掉

这个标题很搞笑,异常怎么会被吃掉呢?还是回归到现实项目中,我们在处理异常时,有两种方式,要么抛出去,让上一层来捕获处理;要么把异常 “try catch” 掉,在异常出现的地方进行处理。而正是这个 try...catch,导致异常被 ”吃“ 掉,事务无法回滚。我们还是看上面那个例子,简单修改一下代码:

@Service
public class UserServiceImpl implements UserService {

    @Resource
    private UserMapper userMapper;

    @Override
    @Transactional(rollbackFor = Exception.class)
    public void isertUser3(User user) {
        try {
            // 插入用户信息
            userMapper.insertUser(user);
            // 手动抛出异常
            throw new SQLException("数据库异常");
        } catch (Exception e) {
            // 异常处理逻辑
        }
    }
}

读者可以使用我源码中 Controller 接口,通过 Postman 测试一下,就会发现,仍然可以插入一条用户数据,这就说明事务并没有因为抛出异常而回滚。

这个细节往往比上面那个坑更难以发现,因为我们的开发思维很容易导致 try...catch 代码的产生,一旦出现这种问题,排查起来往往比较费劲。所以在平时写代码时,一定要多思考,多注意这种细节,尽量避免给自己挖坑。

那面对该问题怎么解决呢?直接往上抛,给上一层处理即可,千万不要在事务中把异常自己 “吃” 掉。

事务范围

事务范围这个坑,比上面两个坑埋得都要深!我曾在实际项目中遇到过这种情况,实际场景在本课中就不模拟了,我写了一个 Demo,大家可以看下。把这个坑记住即可,以后写代码时,遇到并发问题时,能注意到这个坑,那么这节课也就有价值了。

我写的 Demo,如下所示:

@Service
public class UserServiceImpl implements UserService {

    @Resource
    private UserMapper userMapper;

    @Override
    @Transactional(rollbackFor = Exception.class)
    public synchronized void isertUser4(User user) {
        // 实际中的具体业务……
        userMapper.insertUser(user);
    }
}

从上面代码可以看到,因为要考虑并发问题,我在业务层代码的方法上加了个 synchronized 关键字。

我先举个实际场景中的例子,比如一个数据库中,针对某个用户,只有一条记录,下一个插入动作过来,会先判断该数据库中有没有相同的用户,如果有就不插入,而是更新,如果没有才会插入。理论上,数据库中一个用户永远只有一条用户信息,不会出现同一数据库中插入了两条相同用户的信息。
但在压力测试时,就会出现上面问题。数据库中确实有两条同一用户的信息,分析其原因,问题出在了事务的范围和锁的范围上。

从上面方法中可以看到,方法上加了事务,也就意味着,该方法开始执行时,事务启动,执行完了后,事务关闭。但 synchronized 并没有起作用,根本原因是事务的范围比锁的范围大。也就是说,在加锁的那部分代码执行完之后,锁释放掉了,但是事务还没结束。此时如果另一个线程进来,数据库的状态和第一个线程刚进来时是一样的。即由于 MySQL Innodb 引擎的默认隔离级别是可重复读(在同一个事务里,Select 的结果是事务开始时时间点的状态)的,线程二事务开始的时候,线程一还没提交完成,导致读取的数据还没更新。第二个线程也做了插入动作,从而导致了脏数据。

这个问题可以避免,第一,把事务去掉即可(不推荐);第二,在调用该 Service 的地方加锁,保证锁的范围比事务的范围大即可。

总结

本文主要总结了 Spring Boot 使用事务的方法,即只需一个 @Transactional 注解即可,非常简单方便。

除此之外,文中还着重总结了实际项目中可能遇到的三个坑点,对大家来说非常有意义,事务不出问题还好,出了问题往往难以排查。这里总结的三点注意事项,希望能帮助到开发中的朋友。

课程源代码下载地址:

戳我下载

上一篇
下一篇
目录