返回

后端接口性能差,该从哪些方面进行优化?

发布时间:2022-09-23 05:43:22 19
# 后端# redis# 数据库# sql# 数据

前言

作为一个后端开发工程师,我们大部分时间都是在开发业务接口,作为一个资深开发,我们不仅仅是要保证能用就行,更重要的是要保证接口的性能。那么如果接口慢,我们应该从哪些方面对接口进行优化呢?

一:善于使用异步编程

  1. 利用多线程实现异步

比较推荐的方式是自定义TreadPool来实现多线程,在Java 8以及8以上的版本,我们也可以使用CompletableFuture来实现异步编程。

  1. 使用mq中间件实现异步

现在市面上比较流行的分布式消息中间件有rocketmMq,rabbitMq,kafka等,在Springboot的环境中引入相关的消息中间件也比较简单,这里就不再赘述了。

二:数据量大的时候使用批量与分批操作

1.在查询数据库的时候我们要尽量避免在for循环中操作数据库,尽量使用批量处理来对数据库进行操作。在Mybatis中我们可以使用批量处理器来对数据库进行操作,MybatisPlus甚至为我们封装好了批量处理的API。

2.避免在for循环中进行rpc调用,尽量使用批量查询。

3.如果操作的数据量很大,那么我们可以进行分批处理,这样可以避免一次交互的数据量过大,从而导致接口响应过慢。

三:避免大事务

大事务会带来什么危害?

1.并发情况下,数据库连接池容易被撑爆

2.锁定太多的数据,造成大量的阻塞和锁超时

3.执行时间长,容易造成主从延迟

4.回滚所需要的时间比较长

如何解决大事务问题?

尽量少使用​​@Transactional​​注解,虽然它真的很方便,但是声明式事务很难控制好事务的粒度,推荐使用编程式事务来帮助我们更好的控制事务的粒度。Spring给我们提供了​​TransactionTemplate​​来帮助我们实现编程式事务。

TransactionTemplate的简单使用:

 @Resource
private TransactionTemplate transactionTemplate;

@Test
public void test1(){
transactionTemplate.execute(action->{
//执行数据库事务操作
return null;
});
}

四:优化sql慢查询

导致慢查询的原因

1.关键的字段缺少索引

我们可以根据Explain分析慢SQL,如果没有建立索引的话,创建索引即可。

2.有索引,但是却没有用上索引

我们通过Explain分析慢SQL,发现没有使用到索引,但是发现已经创建了索引,那么这种情况就是索引失效了。

这里我举例一些索引失效的一些场景:

①.字段类型不匹配

②.索引列使用了函数

③.like使用了左模糊

④.使用了联合索引,但是却不满足最左匹配原则

索引失效的原因还有很多,这里就不一一列出来了

3.SQL比较复杂,很慢,但是不好优化

如果你的SQL比较复杂,那么建议利用Java代码逻辑来实现对应的逻辑,我们毕竟不是SQL开发,而是后端Java开发,复杂的SQL不仅可能导致慢查询,也不利用后期代码的维护工作。

4.数据表数据很多

①:如果旧数据用户访问的比较少,我们可以对数据进行冷热分离

②:对数据进行分库分表

如果表的数据量已经很大了,那么我们可能就需要进行分库分表的处理了。我们可以使用ShardingJDBC,Mycat等成熟的中间件或者代理来帮助我们完成大数据表的分库分表。

五:善于利用缓存

对于并发比较高的系统,缓存是非常有必要的。我们可以将一些查询较多,但是修改不频繁的数据放入到缓存中,这样可以帮助我们减少对数据库的访问。这样不仅可以减轻数据库的压力,而且接口的响应速度也可以得到很大的提升。

使用Redis作分布式缓存

通常我们会利用Redis作为分布式缓存中间件,但是在使用Redis的时候,我们对key的设计要合理,不然出现Big Key,很有可能影响到我们接口的响应速度。

使用Caffeine作为本地缓存

很多时候我们不仅仅会利用Redis做分布式缓存,同时我们也会做一个本地缓存,减轻redis的压力。这里我以caffeine为例,当然还有很多本地缓存的实现,我这里就不一一介绍了.

注:我们生产上的服务都是部署多台机器的,那么当数据修改时,我们如何让本地缓存失效呢?我的一个思路是可以通过Redis的事件发布机制,只要我们所有的服务都订阅Redis的某个事件,一旦数据进行了改动,那么就发布事件,所有订阅了相关事件的服务就可以接收到消息并将对应的缓存删除。另外如果数据的实时性要求不高,我们甚至可以不用删除缓存,只需要过期时间设置短一点即可(例如5s,10s)。

六:控制好锁的粒度

在并发场景下,很多时候我们都需要使用到锁来帮助我们保证数据的安全性,包括像数据的幂等性处理都需要用到锁。但是如果不管我们使用Sysnchrnoized关键字,jdk的lock锁,还是分布式锁,我们都需要控制好锁的粒度,如果锁的粒度很大,显然会影响到我们系统的吞吐量。

最后

如果你的接口性能比较差,不妨尝试按照以上几点进行优化吧

特别声明:以上内容(图片及文字)均为互联网收集或者用户上传发布,本站仅提供信息存储服务!如有侵权或有涉及法律问题请联系我们。
举报
评论区(0)
按点赞数排序
用户头像
精选文章
thumb 中国研究员首次曝光美国国安局顶级后门—“方程式组织”
thumb 俄乌线上战争,网络攻击弥漫着数字硝烟
thumb 从网络安全角度了解俄罗斯入侵乌克兰的相关事件时间线
下一篇
非关系型数据库Redis核心内容 2022-09-23 05:23:49