接口优化通用方案

批量

1. 批量思想：批量操作数据库
   优化前：

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

batchInsert(transDetailList);

异步、回调

异步思想：耗时操作，考虑放到异步执行
耗时操作，考虑用异步处理，这样可以降低接口耗时。
将接口的耗时操作或IO操作改为异步执行，可以让接口在等待耗时操作完成的同时继续处理其他请求，提高并发处理能力。可以使用 CompletableFuture、CompletableFuture、@Async 注解等方式实现异步调用。

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

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

缓存

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

这里的缓存包括：Redis缓存，JVM本地缓存，memcached，或者Map等等。

预取

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

池化

池化思想：预分配与循环使用
大家应该都记得，我们为什么需要使用线程池？

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

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

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

以下是一些常见的应用池化思想的应用场景和实践方法：
连接池：数据库连接池是应用池化思想的一个典型应用。在项目中使用连接池可以避免频繁地创建和销毁数据库连接，提高数据库访问的性能。常见的连接池实现有 Apache Commons DBCP、HikariCP 等。
线程池：线程池是管理和复用线程资源的一种机制。在项目中使用线程池可以避免频繁地创建和销毁线程，提高线程的利用率和性能。Java 提供了 ThreadPoolExecutor 类来实现线程池，可以根据具体需求进行配置和使用。
对象池：对象池是管理和复用对象资源的一种机制。在项目中使用对象池可以避免频繁地创建和销毁对象，提高对象的利用率和性能。常见的对象池实现有 Apache Commons Pool 等。
缓存池：缓存池是将数据或计算结果缓存起来供后续使用的一种机制。在项目中使用缓存池可以减少重复计算的开销，提高系统的响应速度。常见的缓存池实现有 Redis、Ehcache 等。
资源池：除了上述具体的池化实现外，还可以根据项目的需求创建其他类型的资源池，如连接资源池、文件资源池等。通过池化思想可以有效地管理和复用资源，提高系统的性能和稳定性。

并行

远程调用由串行改为并行
假设我们设计一个APP首页的接口，它需要查用户信息、需要查banner信息、需要查弹窗信息等等。如果是串行一个一个查，比如查用户信息200ms，查banner信息100ms、查弹窗信息50ms，那一共就耗时350ms了，如果还查其他信息，那耗时就更大了。其实我们可以改为并行调用，即查用户信息、查banner信息、查弹窗信息，可以同时并行发起。

锁粒度

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

下面是一些常见的方法来限制锁的粒度：
细粒度锁：使用更小的锁范围来减少锁竞争。例如，可以将锁粒度从整个对象降低到对象的某个字段或方法上。
分离锁：将数据结构拆分成多个部分，并为每个部分使用独立的锁。这样不同部分之间的操作可以并行执行，减少锁竞争。
读写分离锁：对于读多写少的场景，可以使用读写锁（ReadWriteLock）来实现。读操作可以共享锁，而写操作需要独占锁。这样可以提高并发性能，因为多个读操作可以同时进行，而写操作会互斥。
锁分段：对于数据结构较大且操作并发较高的情况，可以将数据结构分成多个段，并为每个段使用独立的锁。这样不同段之间的操作可以并行执行，减少锁竞争。
无锁算法：对于特定的场景，可以使用无锁算法来替代锁。无锁算法利用原子操作和无锁数据结构，实现线程安全的并发访问。
乐观锁：在某些情况下，可以使用乐观锁机制，避免使用独占锁。乐观锁假设并发冲突较少，通过版本号或时间戳等机制来检测和解决并发冲突。
减少锁持有时间：尽量减少在锁内的操作时间，将非必要的操作移到锁外。这样可以缩小锁的范围，减少锁竞争。

索引

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

索引优化这块的话，一般从这几个维度去思考：

你的SQL加索引了没？
你的索引是否真的生效？
你的索引建立是否合理？
关于索引原理可以参考：索引原理

大事务

避免大事务问题
为了保证数据库数据的一致性，在涉及到多个数据库修改操作时，我们经常需要用到事务。而使用spring声明式事务，又非常简单，只需要用一个注解就行@Transactional
所谓大事务问题就是，就是运行时间长的事务。由于事务一致不提交，就会导致数据库连接被占用，即并发场景下，数据库连接池被占满，影响到别的请求访问数据库，影响别的接口性能。

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

RPC远程调用不要放到事务里面
一些查询相关的操作，尽量放到事务之外
事务中避免处理太多数据

海量数据

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

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