线上某核心接口的 P99 从 200ms 涨到 2s，用户开始投诉，P50 基本没变。你手上只有监控指标、日志和链路追踪三样东西。请说明：你第一步看什么、按什么顺序排查，以及你打算怎么在十几分钟内把问题收敛到某一个环节？

面试官在考什么

考察是否理解 P99 与均值的差异意味着什么、能否用指标体系而不是靠翻日志定位问题，以及是否有成本意识（采样率、指标基数）。

可观测性

回答框架 · 前两步

1. P99 涨而 P50 不动，说明大部分请求是正常的，只有一小撮请求被拖慢：优先怀疑尾部因素，比如下游某个分片/某台机器慢、连接池被少数慢请求占满、GC 停顿、锁竞争、个别大 key 或慢 SQL，而不是全链路整体劣化
2. 排查顺序是自外向内、逐层二分：先看入口 QPS 和错误率有没有变化（RED 指标），再看本服务的 RT 分解（各下游调用耗时）、线程池/连接池饱和度、以及宿主机资源（CPU、内存、GC、网络），最后才落到具体日志

同一能力域的其他题

• 一个下单接口要扛峰值 2 万 QPS，库存只有 1000 件且不能超卖，MySQL 单实例写入大约只能承受 3000 TPS，Redis 可用。你会按什么顺序做改造？每一步解决的是哪一段瓶颈，做完之后怎么验证它确实有效？
• 一个限时抢购活动：商品库存 500 件，预计开抢后 1 秒内涌入 10 万个下单请求。硬性要求是绝对不能超卖，成功下单的响应时间要在 200ms 内，没抢到的用户也要在 1 秒内收到明确的失败提示（不能一直转圈）。请给出你的整体链路设计，并说明每一层分别在挡什么、为什么放在那一层。
• 假设你负责一个核心交易 API，日常峰值 1 万 QPS，大促峰值是日常的 20 倍（约 20 万 QPS），P99 要求 <200ms，可用性 99.95%。现有架构是单体应用 + MySQL 主从 + Redis 缓存，团队 8 人，大促预算只能覆盖当前机器成本的 1.5 倍。请你给出从大促前 3 个月到当天的完整方案：容量怎么估算、瓶颈怎么定位、哪些环节做异步/削峰、降级预案怎么定、成本怎么控制。
• 某活动接口预估峰值 3 万 QPS。压测结果：单台 4C8G 服务处理该接口的极限约 2000 QPS（平均响应 200ms，接口无状态，每次请求查一次数据库）。现在有 20 台同规格机器。问：(1) 这 20 台能不能扛住？(2) 如果只能做一件事来提升承载能力，你先做什么？
• 商品详情用 Redis 缓存，key 是商品 ID，TTL 统一 10 分钟。运营改了价格后最坏要 10 分钟才生效，同时线上偶发用户看到旧价格（已排除浏览器缓存）。现在 Redis 内存使用率 90%，缓存命中率 92%。你打算怎么调整？更新策略、TTL、淘汰策略分别怎么定，依据是什么？
• 商品详情页读多写少，峰值 5 万 QPS，缓存命中率 99%，底层是 MySQL。现在运营做一次批量调价，一次要改 2000 个商品的价格。请说明你的缓存更新方案：删缓存还是更新缓存、先动 DB 还是先动缓存、批量改价时怎么避免缓存集中失效把 DB 打穿。