架构 · 高频 5/5
线上接口 RT 突然升高，如何排查？
先确认影响范围和时间点，再按流量、应用、线程、GC、数据库、缓存、下游依赖和网络链路逐层缩小范围。
简短答案
先确认影响范围和时间点，再按流量、应用、线程、GC、数据库、缓存、下游依赖和网络链路逐层缩小范围。
详细解析
排查 RT 要先止血再定位。观察 QPS、错误率、P95/P99、CPU、Load、GC、线程池、连接池、慢 SQL、缓存命中率和下游调用耗时。
如果有链路追踪，应先看慢 span 集中在哪个服务或依赖。没有链路追踪时，可以从网关日志和应用日志切入。
面试回答模板
我会先看监控确认是全站、单接口还是单机问题，再看变更记录和流量波动。随后检查应用 CPU、线程池、GC、慢 SQL、Redis、MQ 和下游服务耗时，找到瓶颈后先扩容、降级或限流止血，再做根因修复。
易错点
- 只背结论，不解释原理和边界。
- 忽略真实生产环境中的容量、延迟、一致性和失败重试。
- 没有结合项目经验说明为什么这样设计。
常见追问
- 这个方案在高并发下有什么风险？
- 如果数据规模扩大十倍，你会如何调整？
- 线上出现异常时，你会先看哪些指标？