网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
如果大家忘记了IO模型,可以复习一下我的文章:看一遍就理解:IO模型详解
假设我们设计一个APP首页的接口,它需要查用户信息、需要查banner信息、需要查弹窗信息等等。如果是串行一个一个查,比如查用户信息200ms
,查banner信息100ms
、查弹窗信息50ms
,那一共就耗时350ms
了,如果还查其他信息,那耗时就更大了。
其实我们可以改为并行调用,即查用户信息、查banner信息、查弹窗信息,可以同时并行发起。
最后接口耗时将大大降低。有些小伙伴说,不知道如何使用并行优化接口?
我之前写过一篇文章并行优化接口的文章,保姆级别的!大家可以看一下,看完会有用的:后端思维篇,手把手教你写一个并行调用模板
在高并发场景,为了防止超卖等情况,我们经常需要加锁来保护共享资源。但是,如果加锁的粒度过粗,是很影响接口性能的。
什么是加锁粒度呢?
其实就是就是你要锁住的范围是多大。比如你在家上卫生间,你只要锁住卫生间就可以了吧,不需要将整个家都锁起来不让家人进门吧,卫生间就是你的加锁粒度。
不管你是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);
一般就是:SQL
的where
条件的字段,或者是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
次,如下:
如果调整一下isUserVip
和isFirstLogin
的顺序:
if(isFirstLogin && isUserVip ){
sendMsg();
}
isFirstLogin
执行的次数是5
次,isUserVip
执行的次数是1
次:
酱紫程序是不是变得更高效了呢?
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
是不是变得更高效了呢?
[外链图片转存中…(img-eXCrdepJ-1715387657889)]
[外链图片转存中…(img-YRn6lz5n-1715387657889)]
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!