分享5个Java接口性能提升的通用技巧

目录
  • 前言
  • 1. 并发调用
  • 2. 避免大事务
  • 3. 添加合适的索引
  • 4. 返回更少的数据
  • 5. 使用缓存

前言

作为后端开发人员,我们总是在编写各种API,无论是为前端web提供数据支持的HTTP REST API ,还是提供内部使用的RPC API。这些API在服务初期可能表现不错,但随着用户数量的增长,一开始响应很快的API越来越慢,直到用户抱怨:“你的系统太糟糕了。” 我只是浏览网页。为什么这么慢?”。这时候你就需要考虑如何优化你的API性能了。

要想提高你的API的性能,我们首先要知道哪些问题会导致接口响应慢。API设计需要考虑很多方面。开发语言层面只占一小部分。哪个部分设计不好就会成为性能瓶颈。影响API性能的因素有很多,总结如下:

  • 数据库慢查询
  • 复杂的业务逻辑
  • 糟糕的代码
  • 资源不足
  • ........

在这篇文章中,我总结了一些行之有效的API性能优化技巧,希望能给有需要的朋友一些帮助。

1. 并发调用

假设我们现在有一个电子商务系统需要提交订单。该功能需要调用库存系统进行库存查扣,还需要获取用户地址信息。最后调用风控系统判断本次交易无风险。这个接口的设计大部分可能会把接口设计成一个顺序执行的接口。毕竟我们需要获取到用户地址信息,完成库存扣减,才能进行下一步。伪代码如下:

public Boolean submitOrder(orderInfo orderInfo) {

	//check stock
	stockService.check();
	//invoke addressService
	addressService.getByUser();
	//risk control
	riskControlSerivce.check();

	return doSubmitOrder(orderInfo);
}

如果我们仔细分析这个函数,就会发现几个方法调用之间并没有很强的依赖关系。而且这三个系统的调用都比较耗时。假设这些系统的调用耗时分布如下

  • stockService.check()需要 150 毫秒。
  • addressService.getByUser()需要 200 毫秒。
  • riskControlSerivce.check()需要 300 毫秒。

如果顺序调用此API,则整个API的执行时间为650ms(150ms+200ms+300ms)。如果能转化为并行调用,API的执行时间为300ms,性能直接提升50%。使用并行调用,大致代码如下:

public Boolean submitOrder(orderInfo orderInfo) {

	//check stock
	CompletableFuture<Void> stockFuture = CompletableFuture.supplyAsync(() -> {
        return stockService.check();
    }, executor);
	//invoke addressService
	CompletableFuture<Address> addressFuture = CompletableFuture.supplyAsync(() -> {
        return addressService.getByUser();
    }, executor);
	//risk control
	CompletableFuture<Void> riskFuture = CompletableFuture.supplyAsync(() -> {
        return 	riskControlSerivce.check();
    }, executor);

	CompletableFuture.allOf(stockFuture, addressFuture, riskFuture);
	stockFuture.get();
	addressFuture.get();
	riskFuture.get();
	return doSubmitOrder(orderInfo);
}

2. 避免大事务

所谓大事务,就是历经时间很长的事务。如果使用Spring @Transaction管理事务,需要注意是否不小心启动了大事务。因为Spring的事务管理原理是将多个事务合并到一个执行中,如果一个API里面有多个数据库读写,而且这个API的并发访问量比较高,很可能大事务会导致太大大量数据锁在数据库中,造成大量阻塞,数据库连接池连接耗尽。

@Transactional(rollbackFor=Exception.class)
public Boolean submitOrder(orderInfo orderInfo) {

    //check stock
    stockService.check();
    //invoke addressService
    addressService.getByUser();
    //risk control
    riskControlRpcApi.check();

    orderService.insertOrder(orderInfo);
    orderDetailService.insertOrderDetail(orderInfo);

    return true;
}

相信在很多人写的业务中都出现过这种代码,远程调用操作,一个非DB操作,混合在持久层代码中,这种代码绝对是一个大事务。它不仅需要查询用户地址和扣除库存,还需要插入订单数据和订单明细。这一系列操作需要合并到同一个事务中。如果RPC响应慢,当前线程会一直占用数据库连接,导致并发场景下数据库连接耗尽。不仅如此,如果事务需要回滚,你的API响应也会因为回滚慢而变慢。

这个时候就需要考虑减小事务了,我们可以把非事务操作和事务操作分开,像这样:

@Autowired
private OrderDaoService orderDaoService;

public Boolean submitOrder(OrderInfo orderInfo) {

    //invoke addressService
    addressService.getByUser();
    //risk control
    riskControlRpcApi.check();
    return orderDaoService.doSubmitOrder(orderInfo);
}

@Service
public class OrderDaoService{

    @Transactional(rollbackFor=Exception.class)
    public Boolean doSubmitOrder(OrderInfo orderInfo) {
        //check stock
        stockService.check();
        orderService.insertOrder(orderInfo);
        orderDetailService.insertOrderDetail(orderInfo);
        return true;
    }
}

或者,您可以使用 spring 的编程事务TransactionTemplate

@Autowired
private TransactionTemplate transactionTemplate;

public void submitOrder(OrderInfo orderInfo) {

	//invoke addressService
	addressService.getByUser();
	//risk control
	riskControlRpcApi.check();
	return transactionTemplate.execute(()->{
		return doSubmitOrder(orderInfo);
	})
}

public Boolean doSubmitOrder(OrderInfo orderInfo) {
		//check stock
		stockService.check();
		orderService.insertOrder(orderInfo);
		orderDetailService.insertOrderDetail(orderInfo);
		return true;
	}

3. 添加合适的索引

我们的服务在运行初期,系统需要存储的数据量很小,可能是数据库没有加索引来快速存储和访问数据。但是随着业务的增长,单表数据量不断增加,数据库的查询性能变差。这时候我们应该给你的数据库表添加适当的索引。可以通过命令查看表的索引(这里以MySQL为例)。

show index from `your_table_name`;

ALTER TABLE通过命令添加索引。

ALTER TABLE `your_table_name` ADD INDEX index_name(username);

有时候,即使加了一些索引,数据查询还是很慢。这时候你可以使用explain命令查看执行计划来判断你的SQL语句是否命中了索引。例如:

explain select * from product_info where type=0;

你会得到一个分析结果:

一般来说,索引失效有几种情况:

  • 不满足最左前缀原则。例如,您创建一个组合索引idx(a,b,c)。但是你的SQL语句是这样写的select * from tb1 where b='xxx' and c='xxxx';
  • 索引列使用算术运算。select * from tb1 where a%10=0;
  • 索引列使用函数。select * from tb1 where date_format(a,'%m-%d-%Y')='2023-01-02';
  • like使用关键字的模糊查询。select * from tb1 where a like '%aaa';
  • 使用not innot exist关键字。
  • 等等

4. 返回更少的数据

如果我们查询大量符合条件的数据,我们不需要返回所有数据。我们可以通过分页的方式增量提供数据。这样,我们需要通过网络传输的数据更少,编码和解码数据的时间更短,API 响应更快。

但是,传统的limit offset方法用于 paging( select * from product limit 10000,20)。当页面数量很大时,查询会越来越慢。这是因为使用的原理limit offset是找出10000条数据,然后丢弃前面的9980条数据。我们可以使用延迟关联来优化此 SQL。

select * from product where id in (select id from product limit 10000,20);

5. 使用缓存

缓存是一种以空间换时间的解决方案。一些用户经常访问的数据直接缓存在内存中。因为内存的读取速度远快于磁盘IO,所以我们也可以通过适当的缓存来提高API的性能。简单的,我们可以使用Java的HashMapConcurrentHashMap,或者caffeine等本地缓存,或者MemcachedRedis等分布式缓存中间件。

到此这篇关于分享5个Java接口性能提升的通用技巧的文章就介绍到这了,更多相关Java接口性能提升技巧内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

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

    概述 最近公司的下单接口有些慢,老板担心无法支撑双11,想让我优化一把,但是前提是不允许大改,因为下单接口太复杂了,如果改动太大,怕有风险.另外开发成本和测试成本也非常大.对于这种有挑战性的任务,我向来是非常喜欢的,因为在解决问题的过程中,可以学习到很多东西. 当时我只是知道下单接口慢,但是没人告诉我慢在哪里,也即是说,哪些瓶颈导致下单接口慢了.其实没人知道也没关系的,因为我们可以通过压测来找到具体的瓶颈. 下面会详细介绍一下,在本次压测中遇到的问题以及如何解决,期间用了什么工具. 用到的工具和

  • java接口性能从20s优化到500ms示例详解

    目录 前言 1. 案发现场 2. 现状 3. 第一次优化 4. 第二次优化 5. 第三次优化 5.1 前端做分页 5.2 分批调用接口 前言 接口性能问题,对于从事后端开发的同学来说,是一个绕不开的话题.想要优化一个接口的性能,需要从多个方面着手. 其实,我之前也写过一篇接口性能优化相关的文章<java接口性能优化小技巧>,发表之后在全网广受好评,感兴趣的小伙们可以仔细看看. 本文将会接着接口性能优化这个话题,从实战的角度出发,聊聊我是如何优化一个慢查询接口的. 上周我优化了一下线上的批量评分

  • java接口性能优化技巧

    目录 背景 哪些问题会引起接口性能问题 问题解决 慢查询(基于 mysql) ①深度分页 ②未加索引 ③索引失效 ④join 过多 or 子查询过多 ⑤in 的元素过多 ⑥单纯的数据量过大 业务逻辑复杂 ①循环调用 ②顺序调用 线程池设计不合理 锁设计不合理 机器问题(fullGC,机器重启,线程打满) 万金油解决方式 ①缓存 ②回调 or 反查 背景 我负责的系统在去年初就完成了功能上的建设,然后开始进入到推广阶段.随着推广的逐步深入,收到了很多好评的同时也收到了很多对性能的吐槽. 刚刚收到吐

  • 分享5个Java接口性能提升的通用技巧

    目录 前言 1. 并发调用 2. 避免大事务 3. 添加合适的索引 4. 返回更少的数据 5. 使用缓存 前言 作为后端开发人员,我们总是在编写各种API,无论是为前端web提供数据支持的HTTP REST API ,还是提供内部使用的RPC API.这些API在服务初期可能表现不错,但随着用户数量的增长,一开始响应很快的API越来越慢,直到用户抱怨:“你的系统太糟糕了.” 我只是浏览网页.为什么这么慢?”.这时候你就需要考虑如何优化你的API性能了. 要想提高你的API的性能,我们首先要知道哪

  • 分享几个Java工作中实用的代码优化技巧

    目录 1.类成员与方法的可见性最小化 2.使用位移操作替代乘除法 3.尽量减少对变量的重复计算 4.不要捕捉RuntimeException 5.使用局部变量可避免在堆上分配 6.减少变量的作用范围 7.懒加载策略 8.访问静态变量直接使用类名 9.字符串拼接使用StringBuilder 10.重写对象的HashCode 11.HashMap等集合初始化 12.循环内创建对象引用 13.遍历Map 使用 EntrySet 方法 14.不要在多线程下使用同一个 Random 15.自增推荐使用L

  • Java 中的5个代码性能提升技巧

    目录 1.预先分配 HashMap 的大小 2.优化 HashMap 的 key 3.不使用 Enum.values() 遍历 4.使用 Enum 代替 String 常量 5.使用高版本 JDK 前言: 提示:我们不应该为了优化而优化,这有时会增加代码的复杂度. 这篇文章中的代码都在以下环境中进行性能测试. JMH version: 1.33(Java 基准测试框架) VM version: JDK 17, OpenJDK 64-Bit Server VM, 17+35-2724 通过这篇文章

  • java开发接口吞吐量提升10多倍技巧

    目录 背景 分析过程 定位“慢”原因 继续定位“慢”的原因 定位CPU使用率高的原因 总结 TODO 背景 公司的一个ToB系统,因为客户使用的也不多,没啥并发要求,就一直没有经过压测.这两天来了一个“大客户”,对并发量提出了要求:核心接口与几个重点使用场景单节点吞吐量要满足最低500/s的要求. 当时一想,500/s吞吐量还不简单.Tomcat按照100个线程,那就是单线程1S内处理5个请求,200ms处理一个请求即可.这个没有问题,平时接口响应时间大部分都100ms左右,还不是分分钟满足的事

  • Spring Boot 2.2 正式发布,大幅性能提升 + Java 13 支持

    之前 Spring Boot 2.2没能按时发布,是由于 Spring Framework 5.2 的发布受阻而推迟.这次随着 Spring Framework 5.2.0 成功发布之后,Spring Boot 2.2 也紧跟其后,发布了第一个版本:2.2.0.下面就来一起来看看这个版本都更新了些什么值得我们关注的内容. 组件版本更新 这些Spring框架组件更新了依赖版本: Spring AMQP 2.2 Spring Batch 4.2 Spring Data Moore Spring Fr

  • Java接口RandomAccess全面了解

    在jdk文档中对RandomAccess接口的定义如下:  public interface RandomAccess 下面是jdk的注解翻译 List 实现所使用的标记接口,用来表明其支持快速(通常是固定时间)随机访问.此接口的主要目的是允许一般的算法更改其行为,从而在将其应用到随机或连续访问列表时能提供良好的性能. 将操作随机访问列表的最佳算法(如 ArrayList )应用到连续访问列表(如 LinkedList )时,可产生二次项的行为.如果将某个算法应用到连续访问列表,那么在应用可能提

  • 一次 Java 服务性能优化实例详解

    背景 前段时间我们的服务遇到了性能瓶颈,由于前期需求太急没有注意这方面的优化,到了要还技术债的时候就非常痛苦了. 在很低的 QPS 压力下服务器 load 就能达到 10-20,CPU 使用率 60% 以上,而且在每次流量峰值时接口都会大量报错,虽然使用了服务熔断框架 Hystrix,但熔断后服务却迟迟不能恢复.每次变更上线更是提心吊胆,担心会成为压死骆驼的最后一根稻草,导致服务雪崩. 在需求终于缓下来后,leader 给我们定下目标,限我们在两周内把服务性能问题彻底解决.近两周的排查和梳理中,

  • php使用yield对性能提升的测试实例分析

    本文实例讲述了php使用yield对性能提升的测试.分享给大家供大家参考,具体如下: 生成器提供了一种更容易的方法来实现简单的对象迭代,相比较定义类实现 Iterator 接口的方式,性能开销和复杂性大大降低.生成器允许你在 foreach 代码块中写代码来迭代一组数据而不需要在内存中创建一个数组, 那会使你的内存达到上限,或者会占据可观的处理时间.相反,你可以写一个生成器函数,就像一个普通的自定义函数一样, 和普通函数只返回一次不同的是, 生成器可以根据需要 yield 多次,以便生成需要迭代

随机推荐