日期：2026-07-11
标签：#面试 #八股 #后端 #线上问题排查 #场景题
一句话答案
按“现象量化—链路拆分—资源与依赖定位—变更关联—止损验证”排查，用 Trace 和指标找出耗时发生在哪一层，再针对瓶颈处理。
面试口语版
先确认是平均延迟还是 P99、全部请求还是特定参数、单机还是全局，并看开始时间是否对应发布或流量变化。然后通过链路追踪拆分网关、应用、数据库、缓存和下游 RPC 耗时。应用层看 CPU、GC、线程池和锁；数据库看慢 SQL、执行计划、索引、连接池和锁等待；缓存看热点、穿透和大 Key；下游看超时、重试和网络。应急可回滚、限流、降级、扩容或熔断，修复后对比指标并补充监控和回归测试。
常见原因与处理
| 原因 | 证据 | 处理思路 |
|---|---|---|
| 慢 SQL/索引失效 | 慢日志、执行计划、扫描行数 | 改写 SQL、补索引、控制返回量 |
| 线程池耗尽 | 活跃数满、队列增长 | 消除慢任务、隔离线程池、合理背压 |
| Full GC | GC 日志、停顿与延迟对齐 | 降低分配、修复泄漏、调整内存 |
| 下游变慢 | Trace 慢 Span、超时上升 | 熔断、降级、缓存、推动下游修复 |
| 大请求/大响应 | 网络与序列化耗时 | 分页、压缩、异步导出 |
关键细节
- 不要一开始就扩线程池；下游容量不变时只会积压更多请求。
- P99 变慢可能由少量慢 SQL、锁竞争、GC 停顿或网络尾延迟造成。
- 诊断动作要控制生产开销，并在止损前保留必要现场。
面试官追问
- 没有链路追踪怎么定位？
- 只有某类参数慢如何处理？
- 数据库连接池满了为什么不能只扩池？
- 如何制定接口延迟 SLO？
面试官追问参考答案
1. 没有链路追踪怎么定位？
利用统一 requestId 串联网关、应用和下游日志，分别记录入口总耗时、SQL、RPC 和线程池等待；结合访问日志、慢查询、主机指标按时间对齐。也可临时对单实例增加低开销分段计时或采样 profiler，再逐层二分排查。
2. 只有某类参数慢如何处理？
对快慢请求按参数维度、数据规模、租户和执行计划做对比，常见是数据倾斜、深分页、未命中索引或大结果集。不要直接记录敏感原始参数，可打脱敏标签；修复可采用联合索引、游标分页、分区、缓存或大任务异步化。
3. 数据库连接池满了为什么不能只扩池？
数据库可并发执行能力有限，连接增多会增加上下文切换、锁竞争和内存，并把更多请求推入已经过载的数据库。应先找出长事务、慢 SQL、连接泄漏和流量增长，再按数据库容量设置有界池与获取超时。
4. 如何制定接口延迟 SLO？
从用户体验和业务目标定义统计周期、成功条件和分位数，例如“30 天内 99.9% 成功请求低于 300ms”，并排除或单列客户端取消。再给依赖分配预算，建立 SLI、错误预算、告警和发布门槛，不能只设平均延迟。
学习清单
- 能按层次说出至少十个慢接口原因。
- 能说明止损、根因修复和验证闭环。
维护与整理 · Yihui在 GitHub 上编辑