查询接口性能优化

之前其实很困惑查询接口的性能该怎么优化。归根结底主要面临着两大现状，① 查询太多 ② 数据实时性要求高。尤其对于活动或者小任务这样的需求，业务场景的多样化也就带来了我们的条件分支判断繁多，同时前端展示内容的个性化以及丰富性，也伴随着可能更多的数据查询。有时为了达到更好的视觉效果，前端展示的内容要求是获取实时更新的数据。那么从最初的只是功能实现，到随着用户流量的递增，数据的累积，我们开始逐渐注重接口的性能。在这样的背景下，针对面临的问题，寻找相应解决的方案。通过实践学习，解决这样的查询性能，我归纳总结了下。

      一个接口里尽量将数据查询减少到最低，最好就1个或者2个查询，不超过4个。这个查询是指DB查询或者第三方依赖接口查询。减少这样的查询，无非就是为了减少接口因为过多的查询，造成接口响应时间过大。那么有以下两种场景，根据实际场景选择合适的解决方案。

• 场景1：跨库查询多，即依赖于其他项目的接口多，可以选择使用并发查询，也就是使用线程池来减少接口总共所消耗的时间。原因在于，不涉及自己项目数据库连接池资源的竞争，并发查询可以有效地提高接口的响应能力。

• 场景2：本库查询多，可以选择使用缓存查询。比如将变动小的数据存放在redis缓存中；而变动较为频繁的数据，根据评估风险，可以选择将删除缓存和查询存放缓存进行配套使用，即在数据更新的时候对应删除缓存，保证查询的时候是最新的数据；原因在于，本库的查询较多，涉及到数据库连接池资源的竞争，如果使用并发查询也必须有空闲的数据库连接可用，否则并发查询也无太大效果。因此存放进缓存是最有效也是最合适的方式。