小工具      在线工具  汉语词典  css  js  c++  java

实战总结,18种接口优化方案的总结

Java,缓存,redis,java 额外说明

收录于:42天前

之前工作中,遇到一个504超时问题。原因是因为接口耗时过长,超过nginx配置的10秒。然后 真枪实弹搞了一次接口性能优化,最后接口从11.3s降为170ms。本文将跟小伙伴们分享接口优化的一些一般的方案。

1.批量思维:数据库的批量操作

优化前:

//for循环单笔入库
for(TransDetail detail:transDetailList){
  insert(detail);  
}

优化:

batchInsert(transDetailList);

打个比方:

打个比喻:假如你需要搬一万块砖到楼顶,你有一个电梯,电梯一次可以放适量的砖(最多放500), 你可以选择一次运送一块砖,也可以一次运送500,你觉得哪种方式更方便,时间消耗更少?

2、异步思想:耗时的操作应该异步执行。

耗时操作,考虑用异步处理,这样可以降低接口耗时。

假设一个转账接口,匹配联行号,是同步执行的,但其操作时间有点长,优化前的流程:

为了降低接口耗时,更快返回,你可以把匹配行号移到异步处理,优化后:

  • 除了转账这个例子,日常工作中还有很多这种例子。比如:用户成功注册后,还可以异步处理短信和电子邮件通知。~

  • 至于异步的实现方式,您可以使用线程池或消息队列。

3.以空间换时间的思想:适当使用缓存。

在适当的业务场景,恰当地使用缓存,是可以大大提高接口性能的。缓存其实就是一种以空间换时间的想法,就是你把要查的数据,提前放好到缓存里面,需要时,直接检查缓存,而不是检查数据库或计算过程

这里的缓存包括:Redis缓存,JVM本地缓存,memcached,或者Map等等。我举个我工作中,一次使用缓存优化的设计吧,比较简单,但是思路很有借鉴的意义。

那是一次转账接口的优化,旧代码,每次转账,都会根据客户账号,查询数据库,计算匹配联行号。

因为每次检查所有数据库并计算匹配项,这是相当耗时的。,所以使用缓存,优化后流程如下:

4.预取思想:提前初始化到缓存

预取思想很容易理解,就是提前将需要计算、查询的数据初始化到缓存中。如果你在未来某个时间需要用到某个经过复杂计算的数据,如果实时计算的话,可能会花费很多时间。。这时候,我们可以采取预取思想,提前计算出以后可能需要的数据,放入缓存中,等需要的时候,去缓存取就行。这将大幅度提高接口性能。

我记得以前在第一个公司做视频直播的时候,看到我们的直播列表就是用到这种优化方案。就是启动个任务,提前初始化直播用户、积分等相关信息到缓存

5.池化思想:预分配和回收

大家应该都记得,为什么我们需要使用线程池

线程池可以帮助我们管理线程,避免增加创建和销毁线程的资源消耗。

如果每次需要使用的时候都创建一个线程,那么会花费一定的时间。线程池可以复用线程,避免不必要的时间消耗。 池化技术不仅仅指线程池,很多场景都有池化思想的体现,它的本质就是预分配和回收

比如TCP三次握手,大家都很熟悉吧,它为了减少性能损耗,引入了Keep-Alive长连接,避免频繁的创建和销毁连接。当然,类似的例子还有很多,如数据库连接池、HttpClient连接池。

我们写代码的过程中,学会集中思考,最直接相关的就是使用线程池而不是去new一个线程。

6.事件回调思想:拒绝阻塞等待。

如果你调用一个系统B的接口,但是它处理业务逻辑,耗时需要10s甚至更多。然后你是一直阻塞等待系统B下游接口返回,再继续你的下一步操作吗?这样显然不合理

我们参考IO复用模型。即我们不用阻塞等待系统B的接口,而是先去做别的操作。等系统B的接口处理完,通过事件回调通知,我们接口收到通知再进行对应的业务操作即可。

7.远程调用由串行改为并行

假设我们设计一个APP首页的接口,它需要查用户信息、需要查banner信息、需要查弹窗信息等等。如果是串行一个一个查,比如查用户信息200ms,查banner信息100ms、查弹窗信息50ms,那一共就耗时350ms了,如果还查其他信息,那耗时就更大了。

其实我们可以改为并行调用,即查用户信息、查banner信息、查弹窗信息,可以同时并行启动

最后,界面时间将大大减少。有些小伙伴说,不知道如何使用并行优化接口?

8.避免锁粒度过大

在高并发场景,为了防止超卖等,我们经常需要锁定以保护共享资源。但是,如果加锁的粒度过粗,是很影响接口性能的。

什么是锁定粒度?

其实就是就是你要锁住的范围是多大。比如说你在家上厕所,你只要把浴室锁上就可以了,对吧?,不需要将整个家都锁起来不让家人进门吧,卫生间就是你的加锁粒度。

不管你是synchronized加锁还是redis分布式锁,只需要在共享临界资源加锁即可,不涉及共享资源的,就不必要加锁。就好像你去卫生间的时候,不需要锁整个房子,只要锁上卫生间的门就可以了。

比如,在业务代码中,有一个ArrayList因为涉及到多线程操作,所以需要加锁操作,假设刚好又有一段比较耗时的操作(代码中的slowNotShare方法)不涉及线程安全问题。反例锁定意味着一次性锁定所有内容。:

//不涉及共享资源的慢方法
private void slowNotShare() {
    try {
        TimeUnit.MILLISECONDS.sleep(100);
    } catch (InterruptedException e) {
    }
}

//错误的加锁方法
public int wrong() {
    long beginTime = System.currentTimeMillis();
    IntStream.rangeClosed(1, 10000).parallel().forEach(i -> {
        //加锁粒度太粗了,slowNotShare其实不涉及共享资源
        synchronized (this) {
            slowNotShare();
            data.add(i);
        }
    });
    log.info("cosume time:{}", System.currentTimeMillis() - beginTime);
    return data.size();
}

正面例子:

public int right() {
    long beginTime = System.currentTimeMillis();
    IntStream.rangeClosed(1, 10000).parallel().forEach(i -> {
        slowNotShare();//可以不加锁
        //只对List这部分加锁
        synchronized (data) {
            data.add(i);
        }
    });
    log.info("cosume time:{}", System.currentTimeMillis() - beginTime);
    return data.size();
}

9.切换存储方式:文件传输和临时数据存储

如果数据太大,落地数据库实在是慢的话,您可以考虑先暂时保存为文件。。先保存文件,再异步下载文件并慢慢保存到数据库

这里可能会有点抽象,给大家分享一个,我之前的一个真实优化案例吧。

之前开发了一个转账接口。如果是并发开启,10个并发度,每个批次1000笔转账明细数据,数据库插入会特别耗时,约6秒;这个跟我们公司的数据库同步机制有关,并发情况下,因为优先保证同步,所以并行的插入变成串行啦,就很耗时。

优化前1000笔明细转账数据,先落地DB数据库,返回处理中给用户,再异步转账。如图:

记得当时压测的时候,高并发情况,这1000笔明细入库,耗时都比较大。所以我转换了一下思路,将批量的详细传输记录保存在文件服务器上,然后将总的传输记录记录到数据库中。。接着异步再把明细下载下来,进行转账和明细入库。最后优化后,性能提升了十次以上

优化,流程图如下:

如果你的接口耗时瓶颈就此处插入数据库操作,用来批量操作等,还是效果还不理想,就可以考虑用文件或者MQ等暂存。有时候批量数据放到文件,会比插入数据库效率更高。

10. 索引

提到接口优化,很多小伙伴都会想到添加索引。没错,添加索引是成本最低的优化,而且一般优化效果都很不错。

说到索引优化,我们一般会从这几个维度来思考:

  • 您是否已在 SQL 中添加了索引?

  • 你的索引真的有效吗?

  • 您的索引是否正确完成?

10.1 SQL不添加索引

我们开发的时候,容易疏忽而忘记给SQL添加索引。所以我们在写完SQL的时候,就顺手查看一下 explain执行计划。

explain select * from user_info where userId like '%123';

你也可以通过命令show create table ,整张表的索引情况。

show create table user_info;

如果某个表忘记添加某个索引,可以通过alter table add index命令添加索引

alter table user_info add index idx_name (name);

一般就是:SQLwhere条件的字段,或者是order by 、group by后面的字段需需要添加索引。

10.2 索引不生效

有时候,即使你添加了索引,但是索引会失效的。天罗哥整理了索引失效的常见原因

10.3 指标设计不合理

我们的索引越多越好。它们需要适当设计。例如:

  • 删除冗余和重复的索引。

  • 索引一般不能超过5

  • 索引不适合建立在有大量重复数据的字段上,比如性别字段。

  • 适当使用覆盖索引

  • 如果需要使用force index强制走某个索引,那就需要思考你的索引设计是否真的合理了

11.优化SQL

索引优化之后,SQL其实还有很大的优化空间。例如这些:

12.避免大的商业问题

为了保证数据库数据的一致性,在涉及到多个数据库修改操作时,我们经常需要用到事务。而使用spring声明式事务,又非常简单,只需要用一个注解就行@Transactional,如下面的例子:

@Transactional
public int createUser(User user){
    //保存用户信息
    userDao.save(user);
    passCertDao.updateFlag(user.getPassId());
    return user.getUserId();
}

这块代码主要逻辑就是创建个用户,然后更新一个通行证pass的标记。如果现在新增一个需求,创建完用户,调用远程接口发送一个email消息通知,很多小伙伴会这么写:

@Transactional
public int createUser(User user){
    //保存用户信息
    userDao.save(user);
    passCertDao.updateFlag(user.getPassId());
    sendEmailRpc(user.getEmail());
    return user.getUserId();
}

这样实现可能会有坑,事务中嵌套RPC远程调用,即事务嵌套了一些非DB操作。如果这些非DB操作耗时比较大的话,可能会出现大企业问题

所谓大事务问题就是,就是长时间运行的事务。由于事务一致不提交,就会导致数据库连接被占用,即并发场景下,数据库连接池被占满,影响到别的请求访问数据库,影响其他接口的性能

大事务引发的问题主要有:接口超时、死锁、主从延时等等。因此,为了优化接口,我们要规避大事务问题。我们可以通过这些方案来规避大事务:

  • 不要将 RPC 远程调用放入事务中

  • 一些与查询相关的操作应尽可能放在事务之外

  • 避免在事务中处理过多数据

13.深度分页问题

在以前公司分析过几个接口耗时长的问题,最终结论都是因为深度分页问题

深度分页问题,​​为什么慢?我们来看看这个SQL

select id,name,balance from account where create_time> '2020-09-19' limit 100000,10;

limit 100000,10意味着会扫描100010行,丢弃掉前100000行,最后返回10行。即使create_time,也会回表很多次。

我们可以通过标签记录法和延迟关联法来优化深分页问题。

13.1 标签记录方法

只需标记您上次检查的项目,下次检查时,就从该项目开始向下扫描。就像读一本书一样。您只需将其折叠或在上次看到的位置添加书签即可。下次你读它的时候,你可以直接翻到它。

假设上一次记录到100000,则SQL可以修改为:

select  id,name,balance FROM account where id > 100000 limit 10;

这样的话,后面无论翻多少页,性能都会不错的,因为命中了id主键索引。但是这种方式有局限性:需要一个类似连续自增的字段。

13.2 延迟相关法

延迟关联方法是将条件传递到主键索引树,然后将数量减少回表。优化后的SQL如下:

select  acct1.id,acct1.name,acct1.balance FROM account acct1 INNER JOIN (SELECT a.id FROM account a WHERE a.create_time > '2020-09-19' limit 100000, 10) AS acct2 on acct1.id= acct2.id;

优化思路是,先通过idx_create_time二级索引树查询到满足条件的主键ID,再与原表通过主键ID内连接,这样后面直接走了主键索引了,同时也减少了回表。

14、优化程序结构

优化程序逻辑、程序代码,是可以节省耗时的。比如,你的程序创建了太多不必要的对象,或者程序逻辑混乱,反复检查数据库,或者你的实现逻辑算法不是最高效的。,等等。

我举个简单的例子:对于复杂的逻辑条件,有时调整顺序可以让你的程序更加高效。

假设业务需求如下:如果用户是会员,首次登录时需要发送感谢短信。如果你不考虑的话,代码就直接这样写

if(isUserVip && isFirstLogin){
    sendSmsMsg();
}

假设有5个请求过来,isUserVip判断通过的有3个请求,isFirstLogin通过的只有1个请求。那么以上代码,isUserVip执行的次数为5次,isFirstLogin执行的次数也是3次,如下:

如果调整一下isUserVipisFirstLogin的顺序:

if(isFirstLogin && isUserVip ){
    sendMsg();
}

isFirstLogin执行的次数是5次,isUserVip执行的次数是1次:

酱紫程序变得更有效率了吗?

15.压缩传输内容

压缩传输内容,传输报文变得更小,因此传输会更快啦。10M带宽,传输10k的报文,一般比传输1M的会快呀。

打个比方,千里马驮100公斤货物跑得快,还是驮10公斤货物跑得快?

我们再举一个视频网站的例子:

如果不对视频做任何压缩编码,因为带宽又是有限的。通过网络传输大量数据所花费的时间将比编码和压缩后慢许多倍。

16.对于海量数据处理,考虑NoSQL

之前看过几个慢SQL,都是跟深分页问题有关的。发现标签记录法和延迟相关法的效果不是很明显。,原因是要统计和模糊搜索,并且统计的数据是真的大。最后跟组长对齐方案,就把数据同步到Elasticsearch,然后这些模糊搜索需求,都走Elasticsearch去查询了。

我想表达的就是,如果数据量过大,一定要用关系型数据库存储的话,就可以分库分表。但是有时候,我们也可以使用NoSQL,如Elasticsearch、Hbase等。

17.线程池设计必须合理

我们使用线程池,就是让任务并行处理,更高效地完成任务。但是有时候,如果线程池设计不合理,接口执行效率则不太理想。

一般我们需要关注线程池的这几个参数:核心线程、最大线程数、阻塞队列

  • 如果核心线程太小,将无法实现良好的并行性。

  • 如果阻塞队列不合理,不仅仅是阻塞的问题,甚至可能会OOM

  • 如果线程池不区分业务隔离,核心业务可能会受到外围业务的拖累

你可以阅读我之前两篇关于线程池的文章:

18.机器问题(full GC、线程满、太多IO资源没有关闭等)。

有时候,我们的接口慢,就是机器处理问题。主要有fullGC、线程打满、太多IO资源没关闭等等。

  • 之前排查过一个fullGC问题:运营小姐姐导出60多万excel的时候,说卡住了,接着我们就收到监控告警。后面排查得出,我们老代码是Apache POI生成的excel,导出excel数据量很大时,当时JVM内存吃紧会直接Full GC了。

  • 如果线程打满了,也会导致接口都在等待了。所以。如果是高并发场景,我们需要限制访问并拒绝多余的请求。

  • 如果如果不关闭IO资源,也会增加时间消耗。。这个大家可以看下,平时你的电脑一直打开很多很多文件,是不是会觉得很卡。

. . .

相关推荐

额外说明

Midjourney|文心一格 Prompt:完整参数列表、风格汇总、文生图词典合集

Midjourney|文心一格 Prompt:完整参数列表、风格汇总、文生图词典合集 1.Midjourney 完整参数列表 参数名称 调用方法 使用案例 注意事项 V5 V4 V3 niji 版本 在关键词后加空格,然后带上版本参数: --v 或者 —

额外说明

Android——UI主框架搭建-实现主页Tab框架

QQ 1285575001 Wechat M010527 技术交流 QQ群599020441 纪年科技aming 系统组件 + id (规范) Tab 属性

额外说明

[Eigen中文文档] 稠密矩阵分解函数对比

文档总目录 英文原文(Benchmark of dense decompositions) 本页介绍了 Eigen 为各种方阵和过约束问题提供的稠密矩阵分解的速度比较。 有关线性求解器、分解的特征和数值鲁棒性的更一般概述,请查看 此表。 该基准测试已在配

额外说明

fatal error C1083: 无法打开包括文件: “opencv2/objdetect/objdetect.hpp”: No such file or directory

错误描述 ObjectDetection.cpp(20): fatal error C1083: 无法打开包括文件: “opencv2/objdetect/objdetect.hpp”: No such file or directory 问题分析 提示

额外说明

PASCAL、_stdcall、_cdecl等调用方式说明

调用一个函数时,参数的传递是由堆栈来完成的,PASCAL的惯例是参数从左向右压入堆栈,堆占的指针的还原可由被掉用的程序本身来负责,这样还原堆栈指针的代码在被调用的函数中,此代码(还原指针)只有一份。而C的惯例是参数入栈是从右向左,堆占的指针的还原可由调用

额外说明

关于VueX的理解

Vuex 是一个专为 Vue.js 应用程序开发的状态管理模式。 Vuex 是一个专为 Vue.js 应用程序开发的状态管理模式 + 库。它采用集中式存储管理应用的所有组件的状态,并以相应的规则保证状态以一种可预测的方式发生变化 状态管理模式。 把组件的

额外说明

Windows下Release版本Qt程序生成日志和dump文件(用于程序异常崩溃检测)

文章目录 前言 一、基于qInstallMessageHandler生成输出日志 二、基于qBreakpad生成dump文件 三、基于DbgHelp和SetUnhandledExceptionFilter生成dump文件 四、示例完整代码 五、下载链接

额外说明

html中怎么纵向布局,HTML怎么布局

页面布局: 标题:前端的一部分,用于页面顶部。标签用于在网页中添加标题部分。 导航栏:导航栏与菜单列表相同。它用于使用超链接显示内容信息。 索引/侧边栏:它包含其他信息或广告,并不总是需要添加到页面中。 内容部分:内容部分是显示内容的主要部分。 页脚:页

额外说明

wordpress端口更改_如何在外发WordPress电子邮件中更改发件人名称

WordPress 端口更改 您想要更改外发 WordPress 电子邮件的默认发件人姓名和电子邮件地址吗? 想要更改外发 WordPress 电子邮件的默认发件人姓名和电子邮件地址吗? 默认情况下,WordPress 使用“WordPress”作为所有

额外说明

wordpress上传限制_如何在WordPress中为帖子标题添加字符数限制

wordpress上传限制 您是否知道最佳标题长度在 55 到 60 个字符之间?运行多作者博客时,管理标题长度变得很困难。在本文中,我们将向您展示如何在 WordPress 中为帖子标题添加字符限制。 您是否知道最佳标题长度在 55 到 60 个字符之

ads via 小工具