Springboot 大事务和长连接

1、背景

在当前这个快速开发的环境下，很多时候我们的应用都是测试好好的，正式环境并发一高就一团糟。不了解并发相关参数，看不懂压测报告，是很多程序猿的基本状态。本文重点分享长事务以及长连接导致的并发排查和优化思路和示例。

长事务会导致长连接，长连接未必是因为长事务，因果关系先搞清楚。

主要相关技术：

• SpringBoot： 2.5.12
• mybatis-spring-boot-starter： 2.1.2
• druid-spring-boot-starter： 1.2.9
• mysql-connector-java： 8.0+
• tomcat： 9.0.54

2、主要参数释义：

2.1 tomcat主要并发参数释义

server:
  port: 8080
  compression:
    enabled: true
  tomcat:
    accept-count: 511
    max-connections: 8192
    threads:
      max: 200
    basedir: /u01/app/base/logs/tomcat
    connection-timeout: 60000
    keep-alive-timeout: 60000      

**threads.max：**表示服务器最大有多少个线程处理请求，默认200，实际上这个参数超过服务器核心数太多反而会降低服务器cpu处理速度，对于计算密集型和IO密集型应分开考虑设置该参数。

**max-connections：**表示服务器与客户端可以建立多少个连接数，即持有的连接数。tomcat缺省是8192个连接数，cpu未必有时间给你处理，但是可以保持连接。这个参数是客户感知型参数。

accept-count: 与服务器内核相关，是客户端传入给服务器内核，请求的backlog值，该值与服务器内核参数net.core.somaxconn取小后的值为最终起效的TCP内核全队列值。它表示在max-connections值达到预设的值后，服务器内核还能建立的连接数，这个连接保存在内核，还未被上层应用（tomcat）取走。该值在tomcat中默认是100，在Centos7.x版本中内核net.core.somaxconn是128。如果超过max-connections和accept-count总和，新的连接会被拒绝，即直接拒绝服务（直接返回connection refused）。

查看CentOS的net.core.somaxconn参数：sysctl -a|grep net.core.somaxconn

2.2 数据库连接池参数

  datasource:
    type: com.alibaba.druid.pool.DruidDataSource
    druid:     
      driver-class-name: com.mysql.cj.jdbc.Driver
      #连接池属性
      initial-size: 5
      max-active: 140
      min-idle: 10
      # 配置获取连接等待超时的时间
      max-wait: 30000     
      connect-properties.slowSqlMillis: 2000

max-active: 数据库连接池数据连接最大数量，即连接池物理打开数据库的最大数量。这个参数一般开发人员都会错误的设置，首先这个值不是越大越好，最起码它得小于数据库本身配置的最大连接数，如果超过后再向数据库发起连接，就会在数据库层面抛出类似"too many connection"的错误。mysql数据库默认最大连接数为151。一般配置数据库连接池应用组件的时候，不要超过这个数，并且需要留一部分连接数给维护人员使用。

2.3 数据库连接数

上文2.2已经提到数据库连接数，它决定了数据库支持的最大并发数。

查看mysql的最大连接数：

show variables like '%max_connections%';

查看mysql目前的连接数：

show global status like 'Max_used_connections';

如果你的应用配置连接数超过数据库预设的最大数，并且客户端不断并发的发起数据库连接，连接池数量就会不断创建与数据库的物理连接，如果该连接是各种原因导致的数据库长连接（例如：长事务），那么一旦超过数据库的最大值，应用就会报连接数太多的错误。

3、测试程序

两个对外暴露的url：

• 5000毫秒的长连接操作
• 100毫秒的短连接操作

Controller:

    @GetMapping("/slowGetAll")
    public Result<Object> slowGetAll(){
        return Result.ok(testUserService.queryAll());
    }

    @GetMapping("/fastGetAll")
    public Result<Object> fastGetAll(){
        return Result.ok(testUserService.fastGetAll());
    }

service: 向数据库里插入两个用户，并查询最后一个用户的信息，在两次insert操作中间加入一个耗时操作。

    @Transactional(rollbackFor = Exception.class)
    @Override
    public List<TestUser> fastGetAll() {
        TestUser user1 = getTestUser("李四", "jerry");
        this.testUserDao.insert(user1);
        slowMethod(customProperties.getFastMillis());

        TestUser user2 = getTestUser("张三", "tom");
        this.testUserDao.insert(user2);

        return this.testUserDao.queryByBlurry(user2);
    }


    @Transactional(rollbackFor = Exception.class)
    @Override
    public List<TestUser> queryAll() {
        TestUser user1 = getTestUser("王五", "jack");
        this.testUserDao.insert(user1);
        slowMethod(customProperties.getSlowMillis());

        TestUser user2 = getTestUser("赵柳", "amy");
        this.testUserDao.insert(user2);

        return this.testUserDao.queryByBlurry(user2);
    }

    private void slowMethod(int milliseconds){
        try {
            int i = globalCount.incrementAndGet();
            System.out.println("slowMethod start -->"+i);
            Thread.sleep(milliseconds);
            System.out.println("slowMethod end -->"+i);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

注意，这里的长连接使用使用Thread.sleep实现，不是真正的数据库长事务。

4、jmeter测试

开启400线程，测试10轮，分两组：

• 快速处理的短连接4000次。
• 慢速处理的长连接4000次。

4.1、快速组

druid连接池主要结果分析：

在JMeter中的吞吐量为：305.4/second

4.2、慢速组

druid连接池主要结果分析：

在JMeter中的吞吐量为：26.3/second

4.3、对照分析

事务时间分布：非数据库操作的耗时对事务时间分布是没有影响的，快速组和慢速组分布区间基本相同。

连接持有时间分布：快速组大约90%的时间分布在100ms-1s，慢速组100%分布在1-10 s，符合预期的设置。

吞吐量：快速组比慢速组快了接近10倍。

小小结论：在慢速组中，虽然事务的分别时间较短，但是发起该事务的连接一直没有被释放，导致并发能力断崖式下降。

5、问题与优化

5.1、问题

在本次测试中，影响应用并发性能主要体现在长连接持有时间，当服务器处理某个请求耗时较长会导致并发能力直线下降，这个耗时可能会因为数据库长事务、长计算、或发起对外慢速同步的API请求等等原因导致。

5.2 、排查

通过druid monitor监控可以查看很多与数据库连接的参数和实际发生状态，本例中，主要需要找到事务时间分布和连接持有时间即可初步定位问题，然后通过SQL监控找到发生的SQL语句逐步排查定位到JAVA代码块，找到代码块一般都能分析出实际的问题。

5.3、核心

在整个应用生态中，最宝贵的资源就是数据库连接，数据库相关业务密集的系统中，首先需要保证尽可能少的持有数据库连接。所以才催生出数据库连接池这些技术。第二宝贵的是磁盘IO，所有对磁盘IO的操作尽可能少，所以催生出数据库索引、缓存等技术，对于需要直接操作磁盘IO的计算来说，能用顺序读或写，就不要用随机读或写。

5.4、调优

优化并发需从几个方面出发：

• 服务器本身的参数，比如CPU核数，高性能磁盘位置等，通过服务器参数对应设置前文所述的几个应用参数，比如服务器CPU核心数为16个，一般通用业务应用下，缺省的200个线程已经足够。
• 一旦确认服务器配置等基本的参数，并拍脑袋设置了一些应用参数后，就需要启动压测测试各参数配比下最好的服务器和应用性能。
• 确认你的业务系统是计算密集型还是IO密集型，针对性的编写测试用例。
• 最后确认业务系统乃至服务器的性能瓶颈链，输出整体性能报告。在实际生产中，一旦检测到实际并发与性能报告相差太大就可以启动排查程序。

6、优化实验

6.1 手动事务

代码优化背景和目标：

• 首先长连接的事实不可改变，因为有可能这个计算或调用就是需要耗费5秒的时间，如果能减少，则属于另外的优化逻辑；
• 在这个背景下，我们改善的目标是减少数据库连接的持有时间；
• 从实例代码里，真正需要事务的操作是两个insert，slowMethod和query查询都不需要，所以启动手动事务就可以减少数据库连接的持有时间。
• 使用Springboot的手动事务模板。

6.2、优化第一组测试

代码优化如下：

	@Resource
    private TransactionTemplate transactionTemplate;

	@Override
    public List<TestUser> optimizedGetAll() {
        slowMethod(customProperties.getSlowMillis());
        TestUser user1 = getTestUser("王五", "jack");
        TestUser user2 = getTestUser("赵柳", "amy");

        transactionTemplate.execute(status -> {
            this.testUserDao.insert(user1);
            this.testUserDao.insert(user2);
            return Boolean.TRUE;
        });

        return this.testUserDao.queryByBlurry(user2);
    }

druid连接池主要结果分析：

在JMeter中的吞吐量为：37.3/second

测试分析：

• 首先连接持有时间大幅度下降，原先慢速组100%的样本数据在1-10 s区间，现在改区间只有0.98%的数据。
• 我们发现连接持有时间分布样本数据总和是8000，而不是原本慢速组的4000，并且在0-1 ms, 1-10 ms, 10-100 ms, 100ms-1s都有分布，说明一个问题，query查询单独占用了数据库连接。
• 我们知道数据库连接是宝贵资源，query单独占用连接是否有问题？从上面的测试结果分析，query虽然单独占用资源，但是时间很短，并且也是复用了连接池的资源，相当于把长事务分摊到短操作中。是否还有更优配置呢？
• 所以我们还需要做一组测试，把query放入事务中试试看。本次连接持有时间分布总样本中位数参考值是 1458262 ms。
• 最后，吞吐量有所提升，总体上这个优化方案是有效果的。

6.3、优化第二组测试

代码优化如下：

    @Override
    public List<TestUser> optimizedGetAll2() {
        slowMethod(customProperties.getSlowMillis());
        TestUser user1 = getTestUser("王五", "jack");
        TestUser user2 = getTestUser("赵柳", "amy");

        return transactionTemplate.execute(new TransactionCallback<List<TestUser>>() {
            @Override
            public List<TestUser> doInTransaction(TransactionStatus status) {
                testUserDao.insert(user1);
                testUserDao.insert(user2);
                return testUserDao.queryByBlurry(user2);
            }
        });
    }

druid连接池主要结果分析：

在JMeter中的吞吐量为：38.0/second

测试分析：

• 对比一二组，首先事务分布时间是改善的，但是并不明显；
• 本次连接持有时间分布总样本中位数参考值是 1474400 ms，对比一二组，第二组比第一组多耗费 16138 ms；
• 在该样本的情况下，第一组实际持有连接的时间更短，压力更为平均。
• 将不必要的query放入事务本身就是不推荐，本示例中query查询的数据量较小，如果数据量较大，从理论上分析，会明显影响事务的提交。
• 吞吐量基本无变化，这个是符合预期的。
• 所以这次优化，推荐使用第一组的方式。

7、总结

• 在系统初次上线前，可以考虑编写测试用例用压测的方式拿到服务器的性能指标。
• 在系统完成开发后，可以考虑对简单、中等、高复杂度的API分别进行压测摸清API的性能体现，以及对比服务器性能指标，有可能在上线前就能排查出问题。
• 在系统上线后，如果遇到应用性能下降或并发问题，可以通过观察连接池和SQL分析定位大致的java代码块，解决问题最终还是需要针对性编写测试用例再次复盘测试。
• 大部分情况下，系统缺省的参数都够你使用，任何一次参数优化调整都应该有理论支撑和实践证明，云调参张口就来谁都会。
• 并发调优一定要抓住关键目标，找到核心资源，分析并发瓶颈链路。
• 数据库连接池还有很多参数是可以帮助调优分析的，本文没有介绍，jmeter的压测的方式也是多种多样，应根据不同的场景调整。
• 并发调优是一个复杂的过程，从应用所有的关联点都可能出现问题，本文只是从开发角度，针对请求长连接以及数据库长事务做了简单的分析和推测。