服务器之家:专注于服务器技术及软件下载分享
分类导航

PHP教程|ASP.NET教程|Java教程|ASP教程|编程技术|正则表达式|C/C++|IOS|C#|Swift|Android|JavaScript|易语言|

服务器之家 - 编程语言 - Java教程 - JAVA下单接口优化实战TPS性能提高10倍

JAVA下单接口优化实战TPS性能提高10倍

2021-06-19 10:48Sam哥哥 Java教程

今天小编就为大家分享一篇关于JAVA下单接口优化实战TPS性能提高10倍,小编觉得内容挺不错的,现在分享给大家,具有很好的参考价值,需要的朋友一起跟随小编来看看吧

概述

最近公司的下单接口有些慢,老板担心无法支撑双11,想让我优化一把,但是前提是不允许大改,因为下单接口太复杂了,如果改动太大,怕有风险。另外开发成本和测试成本也非常大。对于这种有挑战性的任务,我向来是非常喜欢的,因为在解决问题的过程中,可以学习到很多东西。

当时我只是知道下单接口慢,但是没人告诉我慢在哪里,也即是说,哪些瓶颈导致下单接口慢了。其实没人知道也没关系的,因为我们可以通过压测来找到具体的瓶颈。

下面会详细介绍一下,在本次压测中遇到的问题以及如何解决,期间用了什么工具。

用到的工具和环境

工具

  • jmeter
  • java自带的jvisualvm
  • jmx
  • nmon

环境

  • 腾讯云mysql
  • 腾讯云2核4g的服务器1台

找瓶颈

下单属于写接口,大部分情况下,瓶颈都出在db里,程序可能都在等待db锁的释放。为了验证这个想法,我们可以使用jmeterjvisualvm来验证一下。

为了监控服务器和服务器中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,观察线程的执行情况。

JAVA下单接口优化实战TPS性能提高10倍

JAVA下单接口优化实战TPS性能提高10倍

好了,现在我们可以使用jmeter来对下单接口进行压测了。可以先用50线程并发压,执行时间是1分钟。

JAVA下单接口优化实战TPS性能提高10倍

在压测的过程中,做一下线程dump,同时利用nmon观察应用服务器cpu的负载情况。

JAVA下单接口优化实战TPS性能提高10倍

负载很低,将线程并发调整到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)

导致锁的代码是httpclientexecute方法,该方法在执行的时候,一直在等待获取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

延伸 · 阅读

精彩推荐