面经策

一条 1s 请求的响应，怎么优化成 1ms？ ​

  • 标签：后端、场景题

🏛 业务架构师 ​

1 秒优化到 1 毫秒是 1000 倍提升，靠单点优化不可能达成，必须架构级重构。我的方法论：先测量分段、再按收益倍数排序手段，最后提醒不是所有接口都值得这么干。

第一步：耗时解剖 拿到 1 秒的构成：慢 SQL 600ms + 下游调用 300ms + 业务逻辑 100ms 这种拆解决定优化顺序。

手段按量级排序（收益倍数思维）

1. 缓存（10~100 倍）：最优先。热点数据 Redis 预热（读 RT 从 100ms → 1ms），更极致用本地缓存 Caffeine（纳秒级）。先确认这 1 秒的接口是不是读多写少——是的话缓存能吃掉 80% 耗时。

2. 并行化（等于依赖链长度倍数）：串行调 5 个下游各 100ms，CompletableFuture 并行后 = max(100ms)，5 倍到手。

3. 预计算（无限倍）：把实时计算改成离线算好（数仓/定时任务产出宽表），在线只做查询——排行榜、首页推荐位这类"看起来实时、实际允许分钟级延迟"的数据，预计算是最狠的刀。

4. 存储与索引（数倍~数十倍）：覆盖索引消除回表、深分页改游标、大 JSON 字段拆表。

5. 减法（最容易被忽略）：砍掉非必须的同步调用（日志上报、风控同步查询异步化/合并），每砍一个串行依赖，延迟直接减去它。

6. 极致路径：1ms 级意味着一次网络往返（内网 0.5~1ms）都不能有——数据进本地缓存/内存网格、序列化换 Protobuf、GC 换 ZGC 消停顿。

架构师收尾（必说）：1ms 是核心交易/风控级别的指标，为它付出的架构复杂度应该和业务价值匹配——管理后台 1 秒很好，别为简历优化。优化的钱花在"每毫秒影响转化率"的地方：搜索、首屏、支付链路。

🏗 系统架构师 ​

1s 到 1ms 是三个数量级的跨越，靠单点优化不可能，必须重构请求路径。我按方法论"先测量、再分层砍"来讲。

第一步：测量定位耗时构成 1s 的响应拆开看：慢 SQL 300ms、下游 RPC 400ms、大对象序列化 100ms、网络往返 100ms……没有 profiling 一切优化都是猜。

第二步：分层打击（每层一个数量级）：

  1. 缓存：把计算变成查找（最大杠杆）

    • 热点结果整体缓存（Redis/本地 Caffeine），命中即 1ms 级返回——99% 的场景答案就在这
    • 缓存的对象粒度要细：参数化缓存、多级缓存（本地 1ms 内、Redis 2~5ms）

  2. 数据库：砍掉慢查询

    • 索引优化、覆盖索引、深分页改游标——单条 SQL 从 300ms 到 5ms 是常规操作
    • 只查需要的列，消灭 SELECT * 与 N+1 查询（join 或批量 IN 一次拿）

  3. RPC：串行变并行

    • 无依赖的下游调用 CompletableFuture.allOf 并行，400ms 串行 → 150ms
    • 裁剪报文：返回体从 MB 级压到 KB 级，序列化换 Protobuf

  4. 异步化：砍掉请求里的非必要工作

    • 日志、埋点、发券、通知全部出主链路（MQ 异步）
    • 主链路只保留"用户看到结果所必需"的计算

  5. 基础设施：连接池预热复用、同城/同 AZ 部署减少 RTT、JIT 预热、GC 调优（ZGC 把停顿从几十 ms 降到亚 ms）

第三步：验证：压测确认 P99 达标，监控固化。我的经验总结成一句话：缓存干掉计算、索引干掉扫描、并行干掉串行、异步干掉等待，四个"干掉"各贡献一个数量级的一部分，1ms 才有 path 到达。

💻 全栈开发专家 ​

1s → 1ms 是三个数量级，靠单点小修不可能，必须改变数据访问路径。我按排查结果对症下药。

典型耗时拆解（1s 接口的构成）

  • 慢 SQL 800ms + 远程调用 150ms + 自身逻辑 50ms。

三板斧

  1. 缓存挡住读路径（最大头）
java
// 两级缓存：本地 1ms 内返回 + Redis 兜底
Object v = caffeine.getIfPresent(key);
if (v == null) v = redisOrDb(key);   // 回源后回填

热点查询进本地缓存（微秒级），一般查询进 Redis（亚毫秒）。DB 索引优化后单查也就 1~5ms，缓存把磁盘 IO 变成网络/内存访问。

  1. 串行并行化
java
CompletableFuture<A> fa = CompletableFuture.supplyAsync(() -> rpcA(), pool);
CompletableFuture<B> fb = CompletableFuture.supplyAsync(() -> rpcB(), pool);
CompletableFuture.allOf(fa, fb).join();   // 150ms+150ms -> ~150ms

聚合接口里 3 个串行 RPC 变并行，RT 直接砍半以上。

  1. 数据结构下沉/预计算
  • 排行榜、计数、去重判断用 Redis ZSET/SET，别 SQL 里 ORDER BY 百万行。
  • 复杂报表提前算好（物化/汇总表），查询只做读取。

还能挤的

  • 批量合并：N 次单查合一次批量接口。
  • 序列化/日志瘦身：大对象 JSON、逐条打日志在 P99 里很常见。
  • 连接池预热、消除 DNS/建连开销（keep-alive）。

实话：1ms 意味着"内存级访问 + 无串行网络"，通常要本地缓存 + 并行化双管齐下才够得着。