后端API接口性能优化的10种方案，真有用！

后端API接口性能优化的10种方案，真有用！

 

批量思想：批量操作数据库

• 优化前：

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

• 优化后：

• batchInsert(transDetailList);

• 打个比喻：

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

异步思想：耗时操作，考虑放到异步执行

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

• 假设一个转账接口，匹配联行号，是同步执行的，但是它的操作耗时有点长，优化前的流程：

•  

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

• 

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

• 至于异步的实现方式，你可以用线程池，也可以用消息队列实现。

空间换时间思想：恰当使用缓存。

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

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

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

•  

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

•  

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

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

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

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

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

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

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

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

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

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

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

远程调用由串行改为并行

• 假设我们设计一个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();
  }

切换存储方式：文件中转暂存数据

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

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

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

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

• 

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

• 优化后，流程图如下：

• 

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

索引

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