接口突然变慢别急着看数据库，这篇复盘把排查路径讲透了

一次真实线上接口 RT 飙升的排查复盘从慢 SQL、线程池堆积到下游超时最后怎么定位根因大家好我是一名有 4 年工作经验的 Java 后端开发。很多时候面试官真正想听的不是你会不会背概念而是你有没有真实排过线上问题。这篇文章我就用一篇偏复盘风格的内容带你完整走一遍“接口 RT 飙升”的线上排查路径。个人主页文章目录一次真实线上接口 RT 飙升的排查复盘从慢 SQL、线程池堆积到下游超时最后怎么定位根因一、事故背景二、第一步先确认问题是持续的还是抖动型三、第二步先看调用链不要上来就盯数据库四、第三步看线程池是不是被拖住了五、第四步慢 SQL 有没有参与放大六、第五步为什么问题会放大成主链路事故七、最终治理怎么做7.1 优惠券 SQL 优化7.2 优惠券服务加超时和熔断7.3 订单确认页对非核心依赖做降级7.4 线程池隔离7.5 限制前端高频刷新八、这次复盘最值得记住的点8.1 先看链路再看局部8.2 问题常常不是单点而是放大链路8.3 非核心依赖一定要可降级8.4 监控一定要能串起来九、面试中怎么讲这种复盘十、总结十一、结尾一、事故背景某次大促期间订单确认页接口在高峰时段突然出现明显抖动平均 RT 从80ms上升到1.2sTP99 从300ms飙到4s用户侧开始大量投诉页面卡顿应用实例 CPU 没有完全打满但线程池活跃线程数明显上升这个时候最重要的不是猜而是快速缩小问题范围。二、第一步先确认问题是持续的还是抖动型先看监控时我重点观察了这些指标订单确认页 RT错误率应用线程池活跃数Redis RTMySQL 慢查询数下游优惠券服务 RT观察下来有两个明显现象RT 是周期性抖高不是一直高每次 RT 抖高时优惠券服务调用耗时也明显升高这说明问题可能不是单纯应用本身而更像某个下游变慢或者线程池 / 数据库链路被带慢三、第二步先看调用链不要上来就盯数据库很多人这时候第一反应是查慢 SQL但真实排障更稳的方式通常是先看链路再看局部。因为接口 RT 飙升不一定就是 SQL 慢也可能是下游 HTTP 慢Redis 热点线程池排队Full GC链路追踪里很快看出一个关键现象确认页接口有多个下游依赖商品服务和库存服务基本正常优惠券服务调用耗时明显偏高这一步已经把范围收缩了很多。四、第三步看线程池是不是被拖住了再看应用线程池监控发现处理确认页的业务线程池活跃线程数接近上限队列长度持续上升部分请求开始排队这说明问题已经不只是“某次调用变慢”而是下游慢调用把线程池逐渐拖满排队导致 RT 继续放大这个时候如果不及时做隔离或熔断故障很容易继续扩散。五、第四步慢 SQL 有没有参与放大虽然主因已经更像是下游超时但数据库层还是要确认。查了慢日志后发现订单确认页本身核心 SQL 没有明显恶化但优惠券服务里有一条查询用户可用优惠券的 SQL 在高峰期慢了很多继续 Explain 后发现这条 SQL 过滤条件较多深分页和排序一起走扫描行数明显偏高也就是说优惠券服务之所以慢不只是服务抖了而是内部慢 SQL 把自己拖慢了。六、第五步为什么问题会放大成主链路事故这一步特别关键。根因链路大概是这样的优惠券服务内部一条 SQL 在高峰期变慢优惠券接口 RT 上升订单确认页同步调用优惠券服务被阻塞确认页线程池开始堆积更多请求排队RT 继续放大用户刷新重试又带来更多请求也就是说真正的事故不是一个点而是一条完整放大链路。七、最终治理怎么做最终治理不是只做一件事而是多点一起补。7.1 优惠券 SQL 优化改索引去掉不必要的深分页补充覆盖索引7.2 优惠券服务加超时和熔断避免持续拖慢主链路超时后快速 fallback7.3 订单确认页对非核心依赖做降级优惠券展示不是绝对核心所以高峰期允许不返回最优优惠券只返回基础价格信息7.4 线程池隔离不要让慢依赖把主线程池全部拖死。7.5 限制前端高频刷新用户高频刷新本身也会继续放大问题。八、这次复盘最值得记住的点8.1 先看链路再看局部不要一上来就盯某一个组件。8.2 问题常常不是单点而是放大链路慢 SQL 只是起点线程池、重试、同步依赖才是放大器。8.3 非核心依赖一定要可降级不然很容易把主链路拖死。8.4 监控一定要能串起来如果没有RT下游耗时线程池SQL这些联合视角排障会慢很多。九、面试中怎么讲这种复盘如果面试官问你有没有排查过线上接口 RT 飙升的问题你可以这样答第一我会先判断 RT 飙升是持续型还是抖动型并结合错误率、线程池、数据库、Redis、下游依赖的监控一起看先缩小范围而不是上来就猜。第二如果系统有链路追踪我会优先看调用链快速判断是应用内部慢、数据库慢还是某个下游依赖变慢因为接口 RT 问题很多时候是链路放大不是单点问题。第三我会重点关注线程池和下游超时因为很多慢调用最后都会放大成线程堆积和请求排队。真正的根因链路通常是“某个依赖先慢 - 上游同步阻塞 - 线程池堆积 - 整体 RT 飙升”。第四治理时我不会只盯着某一层而是同时补根因和放大器比如 SQL 优化、超时熔断、降级、线程池隔离和重试收敛一起做。十、总结线上接口 RT 飙升这类问题真正难的不是看懂某一张图而是把链路下游线程池SQL重试这些因素真正串起来。如果只记一句结论我觉得可以记住这句线上 RT 问题最怕拍脑袋猜最稳的方式永远是“先看链路、再看放大器、最后做组合治理”。十一、结尾如果你觉得这篇文章对你有帮助欢迎点赞、收藏、关注。后面我会继续整理一些更偏实战的 Java 后端和线上排障文章。