题干与适用场景
服务同时调用数据库、支付和推荐依赖。推荐服务从 10ms 变成 1s 后，请求并发因等待时间增加而膨胀，线程池和连接池被占满，连不依赖推荐的 API 也失败。请设计 bulkhead，让慢依赖的影响停留在相关功能。
AWS Builders’ Library 将这种问题归因于延迟驱动的并发过载：超时不能替代并发上限，必须围绕每个客户端或依赖隔离资源。方案要同时保护本服务与下游，不能只增加超时或重试。
面试官考察点
- 能否解释 Little’s Law 直觉：延迟上升会在相同到达率下推高在途请求。
- 是否按依赖、API、租户或资源池划分并发预算，避免一个慢依赖耗尽全局资源。
- 是否区分硬配额、软配额、动态分配，并说明公平性与利用率取舍。
- 是否设计快速拒绝、降级、超时、熔断、恢复和可观测性。
- 是否验证无关 API 仍可用，且隔离不会造成队列爆炸或饥饿。
回答前需要澄清的问题
- 哪些 API 调用推荐依赖，哪些是关键路径？请求是否可降级？
- 线程、连接、内存和队列的上限及当前并发分布是什么？
- 下游是否支持取消、幂等、批量或缓存？调用方 deadline 如何传播？
- 预算按 API、依赖、租户还是可用区隔离？是否需要动态借用？
- 故障时的用户体验、错误契约和恢复目标是什么？
30 秒回答框架
“我为每个依赖建立独立并发舱壁和有限队列，关键 API 与可降级 API 分池。请求携带 deadline，超过预算立即快速失败或返回缓存；不把超时当并发保护。先用软配额提高利用率，再用硬上限保护全局，动态借用必须有最大值。指标按依赖和 API 观察在途数、拒绝、等待、超时和恢复，压测慢依赖验证无关功能仍可用。”
分步骤深入解答
第一步：量化延迟驱动的并发
记录每个依赖的到达率、服务时间、在途请求和超时。用历史基线估算：服务时间从 10ms 变 1s 时，即使请求率不变，在途量也可能扩大约 100 倍。先找到资源瓶颈，再决定舱壁大小。
第二步：划分资源舱壁
按依赖建立独立连接池、信号量和队列；对同一依赖的关键与可降级 API 再分池。跨可用区或 cell 的共享状态要谨慎，避免隔离名义上存在、实际仍共享线程或连接。
第三步：选择硬、软和动态配额
硬配额保证单个 API 不超限，但流量偏斜时利用率低；软配额允许空闲预算借用，仍需全局上限；动态配额依据负载调整，但必须有最小保障、最大上限和变更速率。租户公平时按租户再切分。
global_limit = 500
payments = hard 150
recommendations = soft 200, borrow <= 100
other_apis = reserved 50第四步：设计拒绝与降级
获取并发许可失败时快速返回明确错误或缓存结果，不把请求塞入无限队列。下游超时遵守调用方 deadline，取消未完成工作；重试必须有预算、退避和幂等条件。关键写入不能静默降级。
第五步：恢复与防止振荡
慢依赖恢复后逐步增加配额，用熔断或半开探测避免瞬时洪峰。保留拒绝、超时和队列水位的时间序列，按依赖、API、租户和 cell 分析。配置变更需要版本和回滚。
第六步：验证隔离边界
注入单一依赖延迟、错误和连接耗尽，观察推荐 API 的拒绝率、关键支付 API 的成功率、全局线程/连接使用和尾延迟。测试突发、租户倾斜、配置更新和 cell 故障；验收无关 API 仍达标且队列有界。
高质量示范回答
“我先用到达率、服务时间和在途量证明推荐依赖变慢会放大并发。每个依赖有独立信号量、连接池和有界队列，关键与可降级 API 分开。支付设硬保留，推荐使用软配额并限制借用；所有调用传播 deadline，许可不足快速失败或返回缓存。”
“恢复时半开探测并逐步增加额度。指标包含在途数、许可拒绝、等待、超时、降级命中、下游错误和恢复时间。故障演练只拖慢推荐，验证支付和其他 API 的尾延迟、连接池和线程池不越界。”
常见错误
- 只调大超时 → 在途请求膨胀 → 设置依赖级并发上限。
- 所有 API 共用线程和连接池 → 慢依赖拖垮全站 → 按依赖和关键性分池。
- 无限队列缓冲 → 内存和延迟失控 → 有界队列并快速拒绝。
- 硬配额静态切死 → 流量偏斜时资源闲置 → 软借用但保留最大边界。
- 重试无预算 → 放大下游过载 → 传播 deadline、限制次数并要求幂等。
- 只测故障依赖 → 无法证明隔离 → 同时验证无关 API 的 SLO。
追问及应对
为什么超时不能替代并发隔离？
超时只限制单次等待时间；在等待期间仍占用线程、连接和内存。依赖延迟上升会让更多请求同时在途，必须限制许可数量。
软配额如何避免一个 API 借光资源？
设置全局上限、每 API 最小保留、单次借用最大值和回收速度；借用方达到上限后快速失败，不能无限增长。
什么时候返回缓存？
读取且业务允许陈旧时可返回带时间戳的缓存；支付、权限和写入结果不能用过期数据静默替代。
如何判断隔离真的生效？
注入单依赖慢和错误，检查无关 API 的在途、尾延迟、线程/连接占用和成功率；如果仍同步下降，说明共享资源或队列边界未隔离。