部分服务接口出现响应时间不稳定如何排查和解决

面试记录 2026-10-22

题目：部分服务接口出现响应时间不稳定如何排查和解决

难度：medium

标签：practice/debug, network/debug, microservice/tracing, difficulty/medium

评分：⭐⭐⭐⭐☆（4/5）

我的回答

服务器部分接口出现响应不稳定的时候,看监控的p99的走势,是持续升高,还是相对稳定,只是偶发性质的有波动;

然后看公司是否有链路追踪之类的监控体系,如果有skywalking,那么可以直接查看skywalking,对一段时间内的某个接口的请求情况进行检查排序,看出现超时或者访问缓慢的接口具体是什么阶段出现了问题,是什么位置出现问题,直接在skywalking上能够看到整个链路;

是出现redis长尾波动,还是mysql出现查询阻塞,或者三方出现问题;

由于是部分接口的不稳定,所以不是批量的事件,不是gc之类引起的全面问题,所以需要抓取个例的情况;

如果没有skywalking之类的链路追踪工具,就要人工手动打日志去检查每个阶段的时间进行查看了,但成本相对较高,并且不一定能抓到;

点评

优点：这题答得最扎实。先看 P99 走势区分"抖动"还是"劣化"，这是教科书级的第一步；然后用"部分是局部问题、GC 是全局问题"做排除法，逻辑很漂亮；再落到链路追踪逐段定位（Redis 长尾 / MySQL 阻塞 / 三方），并给出无 APM 时的兜底方案（分段打点），层次完整。

不足：① 少了一个关键维度——按实例/节点切分。"部分接口不稳定"经常是"部分节点不稳定"，先看每个实例的延迟与流量分布，能立刻发现是单机问题（CPU 被限流、旧版本、连接池耗尽）还是全集群问题；② 没有量化口径：要同时看 P99 与错误率、QPS，避免"流量掉了所以延迟看起来好了"的假象；③ 没提超时/重试放大：下游抖动 → 上游超时重试 → 流量翻倍 → 抖动加剧，这条正反馈是长尾的常见成因；④ 采样问题：APM 若按低比例采样，恰好抓不到那 1% 的慢请求，需要按延迟阈值强制采样。

补充：排查顺序可以固化为四步——① 定性：P99/P999、错误率、QPS 与基线对比；② 切维：按实例、接口、客户端版本、地域、参数规模切分，找差异维度；③ 归因：链路追踪定位到具体 span（自身、Redis、MySQL、RPC、网络），配合下游指标验证；④ 验证：改配置或加缓存后，用同一口径回看 P99 是否回落，避免只看平均值自欺。

完整讲解

第一部分：知识重点剖析

核心考点定位：考察统计口径意识与"先收敛、再归因"的排障纪律——能不能用有限信息把一个模糊的"不稳定"变成可定位的维度。

知识点拆解：

1. 指标口径：平均值会掩盖长尾，必须看 P95/P99/P999 与最大值；同时看错误率与 QPS，三者结合才能判断是"变慢"还是"流量变了"。时间窗口要与发布、活动、定时任务对齐。
2. 偶发 vs 持续：偶发尖刺常见于 GC、连接池瞬时耗尽、下游超时重试、定时任务、网络丢包；持续抬升常见于容量不足、慢查询、索引失效、下游劣化、内存泄漏。
3. 维度切分：实例（单机 vs 集群）、接口（部分接口说明范围有限）、客户端（版本/地域/网络）、参数（大 key、大分页）、下游依赖。差异维度往往直接指向根因。
4. 链路追踪：SkyWalking/Zipkin/Jaeger 按 trace 拆 span，看耗时分布在哪一段。注意采样策略与时钟偏移，跨机器 span 的时间要以同一时钟源为准。
5. 长尾成因：Redis 大 key/热 key 与慢命令（KEYS、HGETALL 大 hash）、MySQL 偶发锁等待或慢查询、连接池排队（HikariCP connectionTimeout）、线程池队列积压、GC 停顿、下游限流、DNS 解析、网络重传、容器 CPU throttling。
6. 重试放大：下游抖动时上游超时重试，会让流量成倍增长，形成"越抖越重"的正反馈；必须有重试预算、熔断与退避。

按「底层原理 → 设计权衡 → 工程实践」递进排列。

第二部分：考察方向与延伸递进

考察方向：

• 深度：是否理解长尾与平均值的差别，能否用采样与维度切分定位偶发问题。
• 广度：能关联到 APM/链路追踪、连接池与线程池、Redis 慢命令、MySQL 锁、容器资源限制、网络。
• 应用：给出可执行的排查顺序与验证方法，并能提出长期治理（超时预算、熔断、缓存、限流）。

延伸递进面试题：

1. P99 很高但平均值正常，说明什么？

• 解答要点：典型的少数请求严重变慢，常见于 GC 停顿、连接池排队、锁等待、下游长尾、网络重传。平均值被大量快请求稀释，必须按分位看。

1. 部分机器慢、部分机器正常，怎么定位？

• 解答要点：按实例切分 QPS/延迟，比对版本、配置、CPU throttling、GC 参数、连接池大小、所在可用区与网络质量；再抓单机线程栈与火焰图。

1. 重试为什么会让抖动更严重？怎么治？

• 解答要点：重试放大流量，下游更慢，超时更多。治法是重试预算（不超过请求量的 10%）、指数退避加抖动、只对幂等请求重试、熔断与降级、超时时间逐层递减。

第三部分：面试者参考回答（三步法口语化，300-400 字）

【一句话结论】

面试官您好，我会先定性再切维：用 P99 和错误率判断是抖动还是劣化，再按实例和链路把范围收敛到一个具体环节。

【三点展开】

第一，看指标口径。平均值会骗人，一定要看 P99、P999 加错误率和 QPS，跟基线比、跟发布和定时任务的时间点对。持续抬升和偶发尖刺，排查方向完全不同。

第二，切维度。既然是部分接口，就先按实例、接口、客户端版本、参数规模切一刀。经常一切就发现是某台机器慢——CPU 被 cgroup 限流、版本旧、连接池小；如果所有实例都慢，再往下看链路。

第三，看链路。有 SkyWalking 就直接按接口排序看慢 span，判断是自身、Redis 大 key、MySQL 锁等待还是三方超时；没有 APM 就在关键阶段打点，虽然成本高但能兜底。定位到下游抖动后，还要检查上游有没有超时重试把流量放大。

【一句边界】

当然，如果 APM 采样率很低，那 1% 的慢请求可能一条都没采到，这时候要按延迟阈值强制采样，或者直接用单机火焰图和线程栈去抓，不能只信链路面板。