Java编程-高并发情况下接口性能优化实践-提升吞吐量TPS

本文讲述了在工作中优化下单接口性能的经历,通过Arthas工具定位到加锁方式是性能瓶颈。优化前使用悲观锁,虽然确保了数据一致性但降低了吞吐量。优化后改用乐观锁,利用SQL条件判断实现数据同步,提升了吞吐量,但在高并发下可能存在判断不准确的问题。总结指出,选择锁的粒度应根据具体场景来平衡数据同步和性能需求。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

​ 记得前段时间工作中接到一个任务是优化一个下单接口的性能提高接口的吞吐量TPS,前期通过arthas工具跟踪接口的具体方法调用链路及耗时,发现了影响此接口的性能瓶颈主要是加锁的方式,后来变更了锁的方式后性能大大提升。
程序的大致逻辑是,1.判断余额是否足够>2.保存订单信息>3.扣减钱包余额>4.记录钱包流水;现在我将优化前及优化后的代码分别通过jmeter设置100个线程1s内请求这个接口通过实验观察效果,代码的变更及压测结果大家可以往下看

优化前:采用悲观锁
该方案是将整个事务方法加锁,可以保证下单时接口成功的响应,即使余额不足也会友好的返回余额不足的提示,但是不足的是客户端用户等待的时间较长;此种方案如果是用在商品秒杀销量优先场景下也不是很合适。

代码
在这里插入图片描述在这里插入图片描述

压测结果(tps 8.4左右)
在这里插入图片描述

优化后:采用乐观锁
这种方式不会显示的给整个方法上锁,依赖的是通过sql的条件判断达到数据同步防止超卖情况发生,此种方式实际就是乐观锁的一种实现,经测试程序的吞吐量提升了很多,但是不足的是并发高的情况下扣减余额时仅仅通过数据库返回的更新结果不能准确判断是余额不足发生更新异常。

代码
在这里插入图片描述在这里插入图片描述

压测结果(tps 30左右)
在这里插入图片描述

总结
通常影响接口的吞吐量有可能就是锁的粒度的大小,在保证数据同步性的同时我们要根据具体场景具体分析评估后采用合适的锁。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

wwwyeeevip

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值