【问题排查】记一次慢接口排查优化

最近做项目的一个接口查询总是很慢，有时要用好几秒，甚至十几秒，底层用的是Tidb数据库，而且是多线程查，一次请求也就两个sql，按理说这是不应该的，本着刨根问底的心态，我对该慢接口进行了分析排查。

接口名称：查询店铺评价详情列表

接口URL：http://127.0.0.1:8890/ads/api/v1/app/xxxxxx/xxxxxxx

接口响应时间（测试环境）：

① 第一次：24.77s

② 第二次：15.09s

③ 第三次：16.79

通过测试我们可以发现，平均每次调用都在15s左右，甚至更高，这还只是测试环境，线上环境可见更慢。

排查思路：分段定位，逐段分析

我在代码中增加了近10个时间戳锚点，分别分析每段代码调用时长。

从锚点结果计算得出，第四段代码耗时最为严重。顺藤摸瓜，我找到了这段代码。

通过分析，这行代码尤其严重。

其主要问题是在for循环中调用redis，这样造成的后果就是，如果集合有100个，就要请求redis100次，如果有10000个，就要请求10000次。

这是及其可怕的！

我们来优化一下它吧！

以前是在遍历中一次一次查redis，现在改成：把所有需要遍历查询的key提取成集合，一次查询多个key对应的值。

现在测试一下优化效果：

① 第一次：2.21s

② 第二次：2.23s

③ 第三次：1.97s

果然不出所料，效率有了显著的提升。

但是还不够快，通过分析，发现还有在for循环中调用redis的情况。

继续优化一下！

最终优化效果（单个请求被控制在ms级）：

① 第一次：598ms

② 第二次：719ms

③ 第三次：497ms

总结：非必要勿在for循环中调用redis