项目中如何排查解决慢接口问题

在项目中排查和解决慢接口问题，需要结合监控工具定位瓶颈 、分层分析原因 、针对性优化三个步骤，结合秒杀项目的技术栈（SpringBoot、MySQL、Redis、Kafka等），具体操作如下：

首先通过工具明确"哪个接口慢""慢在哪个环节"，避免盲目优化：

全链路追踪定位接口

集成SkyWalking或Pinpoint等APM工具，监控接口的响应时间（RT）、QPS、错误率。例如在秒杀项目中，发现/seckill/createOrder接口平均RT达3000ms（正常应<500ms），通过调用链详情发现耗时主要集中在"MySQL订单插入"和"Redis库存校验"两个步骤。
日志埋点细化环节

在接口关键步骤（如参数校验、缓存查询、DB操作、消息发送）添加耗时日志（用System.currentTimeMillis()记录开始/结束时间），例如：
java 复制代码
```
long start = System.currentTimeMillis();
// Redis库存校验
boolean check = redisService.checkStock(goodsId, userId);
log.info("Redis库存校验耗时: {}ms", System.currentTimeMillis() - start);
```
日志输出显示：Redis校验耗时20ms，但MySQL插入订单耗时2800ms，初步锁定DB环节。
服务器资源监控

用top（CPU）、free（内存）、iostat（磁盘IO）、iftop（网络）检查服务器状态：
- 若CPU使用率>80%，可能是代码有循环计算或频繁GC；
- 若内存占用飙升，可能是缓存未释放或对象创建过多；
- 若磁盘IO高，可能是MySQL频繁刷盘或日志打印过多；
- 若网络带宽占满，可能是Redis/MySQL跨机房调用或大对象传输。

针对定位到的瓶颈环节，按"代码逻辑→缓存→数据库→外部依赖"逐层拆解：

问题场景 ：例如秒杀下单接口中，为了校验用户是否有未支付订单，循环查询订单表（for循环调用orderMapper.getByUserId(userId)），导致多次DB交互。
排查方法 ：通过IDEA的"Profile"功能分析方法调用链路，查看是否有重复调用、嵌套循环等耗时操作；或用jstack打印线程栈，检查是否有线程阻塞（如synchronized锁竞争）。

问题场景 ：
- 缓存未命中：例如商品详情接口未正确设置Redis缓存，导致每次请求都查DB；
- 缓存穿透：恶意请求不存在的商品ID，缓存空值未生效，频繁打向DB；
- Redis响应慢：Redis集群主从同步延迟，或Key过期策略不合理导致内存碎片率高（用redis-cli info memory查看mem_fragmentation_ratio，>1.5说明碎片严重）。
排查方法 ：
- 用redis-cli monitor实时查看缓存命令执行耗时；
- 监控Redis命中率（keyspace_hits / (keyspace_hits + keyspace_misses)，目标≥90%）；
- 检查缓存Key的TTL设置和序列化方式（如用JSON比Java序列化更轻量）。

问题场景 ：
- 慢查询：订单表插入时未建索引（如user_id+goods_id联合索引），导致插入后触发全表扫描的校验；
- 锁竞争：秒杀高并发下，MySQL的行锁/表锁竞争（如update goods set stock=stock-1时，若未命中索引会升级为表锁）；
- 连接池耗尽：Druid连接池配置过小（如maxActive=10），高并发时线程等待获取连接。
排查方法 ：
- 开启MySQL慢查询日志（slow_query_log=1，long_query_time=1），定位执行时间>1s的SQL；
- 用explain分析SQL执行计划，查看是否有type=ALL（全表扫描）、rows过大等问题；
- 监控数据库连接池状态（如Druid的activeCount是否达到maxActive，等待数waitCount是否过高）。

问题场景 ：
- Kafka同步发送消息：秒杀下单后，用kafkaTemplate.send().get()同步等待消息发送结果，阻塞接口；
- 第三方服务超时：调用短信通知接口未设置超时时间（默认30s），导致接口卡住。
排查方法 ：
- 检查消息队列监控（如Kafka的under_replicated_partitions是否有分区同步延迟，consumer_lag是否堆积）；
- 查看外部接口调用的超时配置（如RestTemplate的connectTimeout和readTimeout是否设置，建议≤300ms）。

根据排查结果，分场景优化：

异步化：Kafka消息发送改为异步（kafkaTemplate.send().addCallback(...)），避免阻塞；
超时控制：第三方接口调用设置超时（如RestTemplate配置HttpClient超时时间为500ms），失败后降级（如秒杀成功后短信通知失败，记录日志后续补偿）。

项目中曾发现/seckill/createOrder接口在高并发下RT达3s，排查后发现：

数据库层面：订单表插入后，有一个"查询用户近30天订单数"的校验，SQL为select count(*) from order where user_id=? and create_time > ?，未建user_id+create_time索引，导致全表扫描（耗时2.5s）；
缓存层面：Redis库存校验时，用了hgetall获取大Key（包含商品所有信息），序列化耗时高（500ms）。

优化措施：

排查慢接口的核心是"用工具定位瓶颈，按分层拆解原因，针对性优化瓶颈点"，同时需结合压测（JMeter模拟高并发）验证优化效果，避免"优化后反而更差"。对于秒杀等高并发场景，优先优化"数据库和缓存"这两个最易成为瓶颈的环节，同时通过异步化、限流等手段减少接口阻塞。