雪崩机理：一次超时如何拖死全链路
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 5 · 流量防护 · 第 28/49 篇 · 🚧 占位待学
上一篇：《ShardingSphere 实战与平滑扩容》
下一篇：《限流四大算法：从计数器到令牌桶》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 5 · 单元 5.1
一、本文要解决的问题
一个下游慢 2 秒，为什么最后整个网站 502？因为故障会沿着线程池向上传播：下游慢 → 上游线程阻塞 → 上游线程池耗尽 → 上游对更上游表现为「挂了」。理解这条传播链，才能理解四板斧（超时 / 限流 / 熔断 / 隔离）各自在哪一步拦截。
二、知识点清单
- 雪崩三部曲：慢（下游 RT 飙升）→ 满（上游线程池耗尽）→ 传（上游成为新的故障源）
- 超时——第一道防线：超时时间的设定方法（P99 的倍数 / 预算分配），不设超时等于允许无限占用线程
- 重试的风暴放大：重试次数按层级相乘（1.5 的 4 次方 ≈ 5 倍流量），重试预算与退避（jitter）
- 线程池打满的现象学：拒绝策略四种（Abort/CallerRuns/Discard/DiscardOldest）各自的行为
- 四板斧的拦截位置总览：超时（止损）、隔离（限制爆炸半径）、熔断（快速失败）、限流（入口闸门）
三、动手实验（学习时必须真跑）
- 搭 A→B→C 链路，C 慢 3s：观察 A 的线程池从健康到打满的全过程（jstack 三个时间点快照）
- 记录 A 打满后的表现：新请求被拒、其他接口（本不受影响）也失败——复现「陪葬」
- 给 A→C 调用加 500ms 超时 + 降级返回默认值，重复实验观察 A 存活
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。