图 1：本文封面，主题为热点事件突发流量（经典题解析）。
想象面试现场，面试官抛出一个开放式问题：某位顶流明星突然官宣恋情，几千万用户同时涌进来刷同一条内容，平台直接崩了。你说说，为什么会崩？架构上怎么解？这类题没有标准答案，考的是你能不能把「崩溃」拆成一条可分析的链路，再逐环给出对策。
第一步：审题，先讲清楚崩溃链
不要急着背方案，先解释机制。热点事件发生时，一条内容的访问量在几分钟内从几千涨到几千万，崩溃通常沿同一条链传导：第一环，绝大多数请求指向同一个热点 key，缓存层本该挡住它们，但如果缓存里恰好没有或刚刚过期，海量请求同时穿透到数据库——这就是缓存击穿；第二环，数据库单点扛不住远超日常的并发读，查询排队、连接池被占满；第三环，应用服务器的线程或连接被慢查询拖住，新请求不断堆积，超时蔓延到无关接口，一个热点拖垮全站，这就是雪崩。讲完这条链，面试官已经知道你不是在背八股。
这条链上还有一个隐蔽的放大器：重试。接口超时后客户端自动重试，用户刷不出来就反复刷新，实际请求量会成倍放大，形成「越崩越刷、越刷越崩」的正反馈。所以快速失败要尽早介入——宁可立刻拒绝一部分请求，也不要让它们排队等待，把后端拖进更深的泥潭。
第二步：基础回答，四道防线逐级吸收流量
对应崩溃链，防御是分层的。第一道，入口限流：在网关层用令牌桶等算法把放进系统的请求速率压到下游能承受的水平，多余请求直接快速失败，保住核心功能。第二道，热点缓存：对热点 key 做多副本和本地缓存，短过期加主动刷新，让绝大多数请求根本不碰数据库。第三道，服务降级：预案里提前排好优先级，紧急时刻关掉推荐、评论等非核心链路，把资源让给信息流主流程。第四道，弹性扩容加队列削峰：监控触发自动扩容应对整体水位，写操作走消息队列削平瞬时尖峰。四道防线不是单选，是叠加。
还有一环常被忽略：预案与演练。限流阈值、降级开关、扩容策略都要在平时定好并真演练过——热点不会提前打招呼，临时拍脑袋定出的阈值，要么形同虚设，要么误伤正常流量。监控告警是这套防线的眼睛：请求分布、缓存命中率、下游延迟的异常往往比崩溃早到几分钟，这几分钟就是切换预案的全部窗口。
图 2：上方为崩溃链，下方为四道防线的分层防御架构。
第三步：可能的追问
追问一：限流会不会误伤真实用户？会，所以限流要配配额策略和友好提示，核心目标是系统活着，而不是人人满意。
追问二：怎么发现热点 key？靠实时监控请求分布，检测访问频次突增的 key，再动态把它纳入本地缓存或多副本策略。
追问三：降级开关怎么管理？提前在配置中心做好分级预案，演练过才有效，临时想出来的降级方案多半关错服务。
追问四：扩容来得及吗？扩容是分钟级，热点是秒级，所以扩容只解决整体水位，瞬时尖峰必须靠缓存和限流硬扛。
第四步：工程应用与 AI 关联
这套题对 AI 工程岗位并不遥远。一个 AI 功能突然爆红，推理 API 的调用曲线和热点新闻一模一样，而且每次调用背后是昂贵的 GPU 推理，打穿的代价比普通接口更高。推理结果缓存、按用户的调用配额、排队与降级、按负载弹性伸缩推理实例，都是同一套防御思想的迁移。
三个易错点
一是开口就答「加机器」，忽略秒级尖峰只能先靠缓存和限流吸收；二是只讲缓存不讲雪崩传导，显得没见过真实事故；三是把限流降级说成损失，而不说清它保住核心链路的价值。
答题节奏建议
先用一分钟讲崩溃链，证明你理解机制；再按防线逐层给方案，每层配一句权衡；最后主动补监控和预案，说明工程闭环。这个结构展示的是分析框架，而不是背下来的名词清单。
如果热点发生在你负责的 AI 推理服务上，四道防线里你会先上哪一道？为什么？欢迎讨论。
参考资料
- Node.js v22.x 官方 API 文档（同主题 B 站专栏版附令牌桶限流器完整可运行示例，运行环境为 Node.js 22.15.0） — https://nodejs.org/docs/latest-v22.x/api/