基于本文回答

播面 播面

刷题像听歌，多听自然懂
0
评论
请从左侧选择一个分类

如果一个接口 QPS 突然暴涨 100 倍，你会从哪些方面排查和优化？

知识点图片

面对接口 QPS 突然暴涨 100 倍的情况，这通常属于P0 级生产事故。处理思路必须遵循“先止损，后排查，再优化”的原则。

以下是详细的排查与优化方案：

第一阶段：紧急止损（保命）

当流量暴涨 100 倍时，系统极大概率扛不住，数据库可能已经打满。首要目标是保证核心业务可用，防止系统雪崩。

  1. 限流（Rate Limiting）：

    • 网关层限流： 在 Nginx 或 API Gateway（如 Kong, Spring Cloud Gateway）层面直接开启限流。
    • 应用层限流： 使用 Sentinel 或 Hystrix 对该接口进行单机或集群限流。
    • 策略： 优先丢弃多余请求，直接返回 HTTP 429 或友好提示，保护后端资源。

  2. 熔断与降级（Circuit Breaking & Downgrade）：

    • 如果该接口依赖下游服务（如数据库、第三方 API）且已出现超时或报错，立即触发熔断。
    • 非核心业务降级： 如果该接口是非核心功能（如点赞、统计），直接关闭功能或返回默认空值。
    • 核心业务降级： 如果是核心查询，暂停复杂的关联查询，只查主表或缓存。

  3. 紧急扩容（Scaling）：

    • 应用扩容： 如果是无状态服务，利用 K8s HPA 迅速增加 Pod 数量。
    • 资源升配： 临时提升云数据库（RDS/Redis）的规格（如果云厂商支持热升配）。

第二阶段：排查定位（找原因）

在系统稳定（或被限流保护）后，需要快速分析流量来源和特征。

  1. 分析流量来源（Who）：

    • 查看访问日志（Nginx/Gateway Log）：
      • IP 分布： 是来自单一 IP/网段（可能是恶意攻击/爬虫），还是分散的真实用户？
      • User-Agent： 是否包含异常的 UA（如 Python 脚本、未知浏览器）？
      • Referer： 流量是从哪里跳转来的？
    • 鉴权信息： 是未登录用户，还是某个特定 UserID 发起的请求？

  2. 判断流量性质（What）：

    • DDoS/CC 攻击： 如果流量特征单一、无业务逻辑、且量级巨大，极可能是攻击。
      • 对策： 开启 WAF（Web应用防火墙），封禁 IP，开启黑洞策略。
    • 爬虫/刷单： 针对特定接口的高频调用。
      • 对策： 封禁账号，增加图形验证码。
    • 内部 Bug： 是否有前端轮询写错了（如 setInterval 没有延时），或者后端服务出现了重试风暴（Retry Storm）。
    • 业务热点（真实流量）： 突发新闻、营销活动、推送误发全量用户等。

  3. 监控指标分析（Where）：

    • 查看 APM（SkyWalking/Pinpoint） 链路追踪，确定瓶颈是在 DB、Redis 还是代码逻辑。
    • 查看 DB 监控：慢 SQL 是否增多？连接数是否打满？CPU/IO 情况。

第三阶段：架构优化（抗压）

如果排查确认是真实业务流量（如秒杀、突发热点），且必须承接这 100 倍流量，需要从架构层面进行优化。

1. 缓存策略（由重到轻）

  • 本地缓存（Local Cache）： 对于热点数据（Hot Key），使用 Guava/Caffeine 做进程内缓存。这是抗高并发的最强手段，避免网络开销。
  • 分布式缓存（Redis）： 确保数据预热。注意防范缓存穿透、击穿、雪崩。
  • CDN 加速： 如果接口返回包含大量静态数据，尽量推送到 CDN 边缘节点。

2. 异步处理（削峰填谷）

  • 引入消息队列（MQ）：
    • 如果是写请求（如投票、下单），不要直接写库。先写入 Kafka/RocketMQ，后端消费者按照数据库能承受的速度慢慢消费。
    • 如果是读请求，一般不走 MQ，但可以通过 MQ 更新缓存。

3. 数据库优化（最后一道防线）

  • 读写分离： 强制所有查询走从库（Slave），主库只负责写。
  • 分库分表： 如果单表数据量过大，考虑 Sharding（但这是长远方案，救急用不上）。
  • SQL 优化： 紧急 Review 代码，去掉 Select *，去掉多表 Join，确保命中索引。

4. 代码逻辑优化

  • 精简响应： 减少接口返回的数据量，只返回必要字段（减少带宽压力）。
  • 合并请求： 如果前端在循环调用接口，改为批量查询接口（Batch Query）。

第四阶段：后续预防（复盘）

事故处理完后，必须进行复盘，防止下次发生。

  1. 全链路压测： 模拟 10x、50x、100x 流量，探测系统瓶颈。
  2. 预案演练： 建立自动化的降级、熔断预案，并定期演练。
  3. 监控告警： 优化告警阈值，确保在流量上涨 5 倍、10 倍时就能收到告警，而不是等到 100 倍才发现。
  4. 流程规范： 任何营销活动必须提前报备技术团队，进行容量预估（Capacity Planning）。

总结（面试回答话术）

“遇到 QPS 暴涨 100 倍，首先我会立刻开启限流和熔断，优先保证核心服务不挂，防止数据库被打死。

接着我会通过日志和监控分析流量来源：
如果是恶意攻击（IP 集中、UA 异常），直接通过 WAF 或网关封禁；
如果是内部 Bug（如前端死循环），紧急回滚或热修；
如果是真实业务流量，我会根据读写类型优化：读请求上多级缓存（本地+Redis），写请求用 MQ 削峰，同时扩容服务实例。

最后，事后我会推动全链路压测和预案建设，避免重蹈覆辙。”

00:00
00:00