京东一面：接口性能优化，有哪些经验和手段

前言

大家好，我是华仔。

我们来看一道京东面试题：接口性能优化，有哪些经验和手段？

其实这种问法，最好是你结合曾经做过的优化案例来说，然后再补充一些常见的优化手段，那就比较完美啦。如果是我来回答的话，我会先结合之前转账的优化实践，在补充其他常见手段：

• 转账优化实战
• 其他常见优化手段

1. 转账优化实践

先看一下我们对外转账接口的大概流程吧：

我一共用了六种方式优化，批量操作数据入库、耗时操作异步处理、恰当使用缓存、优化程序结构、优化SQL、使用文件/MQ等方式暂存数据，异步再落地DB

1.1 批量操作数据入库

优化前。交易明细是循环遍历入库的：

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

优化后，修改为批量入库

batchInsert(transDetailList);

批量插入性能更好，更加省时间，为什么呢？

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

1.2 耗时操作考虑异步处理

耗时操作，考虑用异步处理，这样可以降低接口耗时。本次转账接口优化，匹配联行号的操作耗时有点长，所以优化过程，我把它移到异步处理啦，如下：

优化前的转账基本流程：

优化后，匹配联行号的操作放到异步处理：

1.3 恰当使用缓存

在适当的业务场景，恰当地使用缓存，是可以大大提高接口性能的。这里的缓存包括：Redis，JVM本地缓存，memcached，或者Map等。

这次转账接口，使用到缓存优化啦：

优化前的老代码，每次转账，都会根据客户账号，查询数据库，计算匹配联行号。

因为每次都查数据库，都计算匹配，比较耗时，所以使用缓存，优化后流程如下：

1.4 优化程序结构

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

老的转账接口，优化前，联行号查询了两次（检验参数一次，插入DB前查询一次），如下伪代码：

public void process(Req req){
  //检验参数,包括联行号（前端传来的payeeBankNo可以为空,但是如果后端没匹配到，会抛异常）
   checkTransParams(Req req);
   //Save DB
  saveTransDetail(req); 
}

void checkTransParams（Req req）{
    //check Amount,and so on.
    checkAmount(req.getamount)；
    //check payeebankNo
    if（Utils.isEmpty(req.getPayeeBankNo())）{
        //查询一次
        String payeebankNo = getPayeebankNo(req.getPayeeAccountNo);
        if(Utils.isEmpty(payeebankNo){
            throws Exception();
        }
    }
}

int saveTransDetail(req){
    //再查询一次
    String payeebankNo = getPayeebankNo(req.getPayeeAccountNo);
    req.setPayeeBankNo(payeebankNo);
    insert(req);
    ...
}

优化后，只在校验参数的时候插叙一次，然后设置到对象里面~ 入库前就不用再查啦，伪代码如下：

void checkTransParams（Req req）{
    //check Amount,and so on.
    checkAmount(req.getamount)；
    //check payeebankNo
    if（Utils.isEmpty(req.getPayeeBankNo())）{
        String payeebankNo = getPayeebankNo(req.getPayeeAccountNo);
        if(Utils.isEmpty(payeebankNo){
            throws Exception();
        }
    }
    //查询到有联行号，直接设置进去啦，这样等下入库不用再插入多一次
    req.setPayeeBankNo(payeebankNo);
}

int saveTransDetail(req){
    insert(req);
    ...
}

1.5 优化你的SQL

这次转账接口优化，我发现一个查询交易流水的SQL，索引加的不是很合理，就是直接查trans_status为交易中，且是半个小时之前的交易流水。原来的话，创建时间create_time和tranS_status都加了索引，我分析了其他相关的业务场景，把它重构为一个联合索引（create_time、trans_status）。

索引的优化方向主要有: SQL是否加索引、你的索引是否生效、索引建立是否合理。常见的索引不生效有这些：

其实，处了索引优化，其实SQL还有很多其他有优化的空间。比如这些：

1.6 考虑使用文件/MQ等其他方式暂存数据，异步再落地DB

如果数据太大，落地数据库实在是慢的话，就可以考虑先用文件的方式暂存。先保存文件，再异步下载文件，慢慢保存到数据库。

给大家说一下这个我的转账优化案例：

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

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

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

优化后，流程图如下：

2. 其他常见优化手段

2.1 池化思想：预分配与循环使用

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

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

如果你每次需要用到线程，都去创建，就会有增加一定的耗时，而线程池可以重复利用线程，避免不必要的耗时。池化技术不仅仅指线程池，很多场景都有池化思想的体现，它的本质就是预分配与循环使用。

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

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

2.2 预取思想：提前初始化到缓存

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

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

2.3 事件回调思想：拒绝阻塞等待。

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

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

2.4 远程调用由串行改为并行

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

其实我们可以改为并行调用，即查用户信息、查banner信息、查弹窗信息，可以同时并行发起。

2.5 深分页问题

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

深分页问题，为什么会慢？我们看下这个SQL

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

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

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

2.5.1 标签记录法

就是标记一下上次查询到哪一条了，下次再来查的时候，从该条开始往下扫描。就好像看书一样，上次看到哪里了，你就折叠一下或者夹个书签，下次来看的时候，直接就翻到啦。

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

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

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

2.5.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内连接，这样后面直接走了主键索引了，同时也减少了回表。

2.6 压缩传输内容

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

打个比喻，一匹千里马，它驮着100斤的货跑得快，还是驮着10斤的货物跑得快呢？

再举个视频网站的例子：

如果不对视频做任何压缩编码，因为带宽又是有限的。巨大的数据量在网络传输的耗时会比编码压缩后，慢好多倍。

2.7 机器问题 （fullGC、线程打满、太多IO资源没关闭等等）

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

• 之前排查过一个fullGC问题：运营小姐姐导出60多万的excel的时候，说卡死了，接着我们就收到监控告警。后面排查得出，我们老代码是Apache POI生成的excel，导出excel数据量很大时，当时JVM内存吃紧会直接Full GC了。
• 如果线程打满了，也会导致接口都在等待了。所以。如果是高并发场景，我们需要接入限流，把多余的请求拒绝掉。
• 如果IO资源没关闭，也会导致耗时增加。这个大家可以看下，平时你的电脑一直打开很多很多文件，是不是会觉得很卡。

最后