某个 API 的 p99 延迟是 3s——你如何调试并优化它？

Question

IT Interview Practice · Accepted Answer

p99 = **尾延迟（tail latency）**：最慢的 1% 请求要花 3s。第一步是**测量并拆解，而不是猜测**。对比 p50 与 p99——如果 p50 很快但 p99 是 3s，说明这条路径并非一致地慢；某些东西只在*高负载或边界情况下*才发作（连接池饱和、GC 暂停、N+1、冷缓存、一个未设超时的外部调用）。

**心智模型：**p99 是*最长的结账队列*，而不是平均等待时间——加快平均值对卡在队尾的顾客毫无帮助。

## 过程（从哪到哪）
1. **测量并拆解**——RED 指标（Rate、Errors、Duration）+ 分布式 tracing；读取 p50/p95/p99。它们之间的*差距*道出了真相。
2. **定位到具体阶段**——为每一步埋点，看慢请求把时间花在了哪里；不要凭直觉去优化。

```js
// 为每个阶段计时，看 p99 堆积在哪里（不要猜）
async function handler(req, res) {
  const t0 = process.hrtime.bigint();
  const mark = (label) =>
    req.log.info({ label, ms: Number(process.hrtime.bigint() - t0) / 1e6 });
  const user = await db.user.find(req.id);   mark('db.user');
  const courses = await loadCourses(user);   mark('loadCourses'); // 嫌疑
  res.json(courses);                         mark('total');
}
```

3. **找出尾部的嫌疑对象**——通常是*等待*，而不是计算：连接池耗尽、N+1 查询、未设超时的外部调用、GC 暂停、缺失索引、冷缓存。

```js
// 之前：N+1 —— N 次串行往返，随着 N 增长 p99 爆炸
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// 之后：合并为 1 次查询 -> 尾部下降（不再有 N 次串行往返）
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // 一次 IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

在这里，p50（N 较小）看起来没问题，但在高负载下 N 增大、连接池饱和，于是 **p99 引爆**。对于外部调用，永远要设置**超时 + 熔断器（circuit breaker）**，这样一个慢依赖就无法拖累整个端点的 p99。

4. **修一个问题 → 重新测量 p99 → 重复。**一次只改一个变量，否则你不会知道是什么起了作用。
5. **把它固定下来**——设定一个 **SLO**（例如 p99 < 300ms）+ 告警，避免回退。

## 面试视角
面试官在考察一个*有方法论的*过程，而不是撞大运的猜测：你是否区分**尾部与均值**、是否在改动前先测量、是否**先看队列/锁（等待）再看 CPU**。弱答案："加缓存 / 把服务器扩容。"强答案：测量 → 用 tracing 定位 → 修复具体的尾部原因 → 用数字验证。

## 原则
优化**尾部（p99），而不是平均值**。大多数"3s p99"来自*等待*（池/队列/锁），而不是*计算*——所以先看队列，再看 CPU。

过程（从哪到哪）

面试视角

原则

相关问题