概述
最近公司的下单接口有些慢，老板担心无法支撑双11，想让我优化一把，但是前提是不允许大改，因为下单接口太复杂了，如果改动太大，怕有风险。另外开发成本和测试成本也非常大。对于这种有挑战性的任务，我向来是非常喜欢的，因为在解决问题的过程中，可以学习到很多东西。
当时我只是知道下单接口慢，但是没人告诉我慢在哪里，也即是说，哪些瓶颈导致下单接口慢了。其实没人知道也没关系的，因为我们可以通过压测来找到具体的瓶颈。
下面会详细介绍一下，在本次压测中遇到的问题以及如何解决，期间用了什么工具。
用到的工具和环境
工具
- jmeter
- java自带的jvisualvm
- jmx
- nmon
环境
- 腾讯云mysql
- 腾讯云2核4g的服务器1台
找瓶颈
下单属于写接口，大部分情况下，瓶颈都出在db里，程序可能都在等待db锁的释放。为了验证这个想法，我们可以使用jmeter和jvisualvm来验证一下。
为了监控服务器和服务器中java进程，我们需要开启jmx，可以在java进程启动的时候，添加如下几个参数：
|
1
2
|
jmx_opts="-dcom.sun.management.jmxremote.port=7969 -dcom.sun.management.jmxremote -dcom.sun.management.jmxremote.authenticate=false -dcom.sun.management.jmxremote.ssl=false -djava.rmi.server.hostname=xx.xx.xx.xx"nohup java ${jmx_opts} -jar xxxxx.jar |
djava.rmi.server.hostname填写java进程所在服务器的ip地址，-dcom.sun.management.jmxremote.port=7969是指定jmx监控端口的，这里是7969。
重新启动进程后，打开本地的(我用的是window10)jvisualvm，添加jmx配置。配置成功后，可以点击线程那个tab，因为我们要做线程dump，观察线程的执行情况。
好了，现在我们可以使用jmeter来对下单接口进行压测了。可以先用50线程并发压，执行时间是1分钟。
在压测的过程中，做一下线程dump，同时利用nmon观察应用服务器cpu的负载情况。
负载很低，将线程并发调整到100后，cpu还是上不去，这样的话，初步可以判断，代码里有锁。
通过观察dump文件，发现如下信息：
- locked <22f6e7f3> (a com.mysql.cj.core.io.readaheadinputstream)
- at com.sun.proxy.$proxy231.reduceskustock(unknown source)
触发这个lock的业务代码是reduceskustock方法。通过阅读代码，发现reduceskustock被包在一个大事务里面。
|
1
2
3
4
5
6
7
8
9
|
@transactional(rollbackfor = {exception.class}) createorder() { //1、扣减库存 reduceskustock(); //2、创建订单 insertorder(); //3、其他写操作 。。。。} |
库存记录通常存在一张独立的库存表，由于创建订单的方法，是一个大事务，这样就会导致某条库存记录只有当整个createorder()方法执行完后，数据库行锁才会被释放，在这个期间，其他线程是无法对这条库存记录进行写操作的。因此我们可以在reduceskustock()中，再开一个事务，操作完这条库存记录后，赶紧释放锁，这样应该可以提高一些性能。为了验证是否是因为事务的原因导致下单接口慢，我们可以直接将createorder()方法的事务去掉，再压测一下。
压测结果发现，下单接口的tps提高了一倍，cpu也上去了不少，但是仍然不够理想，代码里，应该还有其他的锁。再次做线程dump，又发现了一个锁。
- locked <438be230> (a org.apache.http.pool.abstractconnpool$2)
- at org.apache.http.impl.client.closeablehttpclient.execute(closeablehttpclient.java:108)
导致锁的代码是httpclient的execute方法，该方法在执行的时候，一直在等待获取http连接，通过查看源代码，发现居然没有使用连接池，醉了。赶紧加上如下代码：
|
1
2
3
|
poolinghttpclientconnectionmanager pool = new poolinghttpclientconnectionmanager();pool.setdefaultmaxperroute(400);httpclient = httpclients.custom().setconnectionmanager(pool).build(); |
再次压测后，发现代码里已经没有锁了。tps提升了5倍。但是接下来还得做几件事情：
1、打印下单接口的所有sql，然后逐一进行explain操作，看看有没有全表扫描的语句或者没用到索引的sql语句；
2、观察下单接口执行的过程中，full gc发生的次数；
3、增加应用的mysql连接数；
好了，到了这地方，我们可以回到前面，来解决库存问题了。由于老板说，不能大改，因此我就在reduceskustock方法上，再开一个事务。
|
1
2
|
@transactional(propagation = propagation.requires_new)reduceskustock(){} |
让执行库存操作的线程执行完后，赶紧释放行锁。这样做也有个风险，就是库存扣减成功后，下单失败了。不过这种情况比较少，因为当时的下单接口中，大部分业务逻辑都在前面做好判断了，到达插入订单的代码时，就只是单独的insert了，除非数据库挂了，不然不会出现下单失败的情况。
在开发环境下，经过调优后，下单接口的tps提升了3倍左右，当然由于开发环境的数据库和应用服务器都比较差，也会对tps有影响的。当时优化完后，在生产上进行了压测，发现tps提升了10倍。
这个是下单接口的逻辑不能大改的情况下的优化方案，一般来说，库存操作应该是单独的服务，可以单独优化的。而单纯的下单逻辑也是可以优化的。
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对服务器之家的支持。如果你想了解更多相关内容请查看下面相关链接
原文链接：https://blog.csdn.net/linsongbin1/article/details/82656887
