性能反模式

这一课你将能做到

1. 识别 Busy Database、Chatty I/O、N+1、Retry Storm 四大反模式的症状与根因
2. 亲手修复一处 N+1 查询（循环查询 → 批量 JOIN），并用 SQL 日志验证修复效果
3. 为重试配置指数退避 + jitter + 上限，说出「盲目重试如何演变成全网雪崩」的完整链条

为什么要学

架构评审最容易翻车的不是「缺组件」，而是**「能跑但会死」的惯用写法**：开发环境几百条数据一切正常，上线数据一多、流量一来，DB CPU 100%、连接池打满、重试风暴雪崩。反模式清单是设计的负向检查表——知道「别做什么」往往比知道「做什么」更救命。

面试里反模式题是深挖题的入口：「你遇到过的线上性能事故？怎么定位怎么修？」「重试为什么要加退避和 jitter？」「N+1 是什么、怎么发现？」——用事故故事回答，比背概念有说服力。

人话：Busy Database 是让一个人干全公司的活（所有查询压一个库）；Chatty I/O 是给同事发消息一页一条连发 50 条（该一封邮件说清的事）；Retry Storm 是客户打不通电话就一直狂拨（把占线变成彻底瘫痪）。

先建立图像

四大反模式速查表（评审对照用）：

反模式	症状	根因	对策
Busy DB	DB CPU 100%、连接耗尽、慢查询堆积	无缓存、N+1、全表扫、报表混部	缓存、批量、索引、读写分离
Chatty I/O	P99 高但单次调用都快	循环 RPC、每节点一次请求	聚合接口、批量 API、BFF
N+1 查询	一次页面请求 DB 往返几十次	ORM 懒加载或循环查询	JOIN / 批量 IN / 预加载
Retry Storm	下游雪崩、错误率 100%、全网瘫痪	无退避、无上限、超时过宽	指数退避 + jitter + 熔断

本站高危路径画像：

❌ GET /api/problems/1024
     → 查题目 (1 次)
     → 循环 500 个节点，每节点查资源 (500 次)      ← N+1，页面打开 2.5 秒
     → 循环 500 个节点，每节点调一次统计服务 (500 次) ← Chatty I/O

✅ 一次 JOIN 拉全题目+资源 (1 次)
✅ 统计走批量接口 / Redis 预聚合 (1 次)

Retry Storm 的死亡链条（背下来，面试直接用）：

DB 变慢 → 请求超时 → 客户端/网关重试 → 有效 QPS ×3
→ DB 更慢 → 更多超时 → 更多重试 → ×9
→ 线程池占满 → 相邻无辜接口也超时 → 全站 502
（重试流量放大 + 超时把「慢」变成「死」）

跟着做

步骤 1：发现 N+1——打开 SQL 日志

# 开发/测试环境开启 SQL 日志
mybatis:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

访问一次题目详情接口，日志里数 SQL 条数：

==> Preparing: SELECT * FROM problem WHERE id = ?
==> Preparing: SELECT * FROM node_resource WHERE node_id = ?   ← 出现 500 次

一次用户请求 = 501 次 DB 往返。每往返 1ms 是 500ms 纯网络开销，加上每条查询的解析执行，这就是「详情页 2 秒」的真相。发现手段三个：SQL 日志、APM 链路追踪看 DB 段次数、慢查询之外的「QPS 与 DB TPS 比值异常」（1 QPS 打出 500 TPS）。

步骤 2：修复 N+1——循环改批量