题目与范围
为后端服务设计一个 Worker Pool：接收任务、限制同时执行的数量，并在关闭时不静默丢弃已接收任务。说明队列容量、接纳或拒绝、取消、重试归属、结果关联、指标和优雅关闭。
假设任务相互独立，可能调用下游 API。这里讨论进程内组件；若任务必须跨进程故障恢复，应在更外层设计持久化队列。
面试官考察什么
面试官会看你是否给出明确的并发上限、有界内存模型和过载策略，也会追问取消如何到达 Worker、重试是否会放大流量，以及关闭时如何区分排队、执行中、完成和拒绝的任务。
作答前需要确认的问题
- 进程崩溃时允许丢任务吗？不允许时先放入持久化消息系统。
- 任务是否幂等，是否可以安全重试？
- 下游限流、平均耗时和尾延迟目标是什么？
- 队列满时是短暂阻塞、返回
429，还是优先拒绝低优先级任务？ - 取消只针对未开始任务，还是任务可以协作式中断 I/O？
30 秒回答框架
“我会用固定数量的 Worker 和有限队列实现有界提交。容量耗尽时返回明确的过载结果；context 或取消信号让排队任务退出，也让执行中的任务协作式停止。每个任务有 ID 和终态，重试次数受限并由单一层负责。指标包括队列深度、等待时间、活跃 Worker、拒绝、耗时和取消。关闭先停止接纳，再按策略处理排队任务，在截止时间内排空已接收任务，并报告未完成任务。”
分步深入
第一步：定义状态机
使用 submitted → queued → running → succeeded|failed|cancelled。队列满时返回 rejected，不要让调用方无限等待。若调用方需要进程崩溃后恢复，状态必须持久化到进程外。
第二步：同时限制 Worker 与队列
选择 W 个 Worker 和容量为 Q 的队列；内存上界约为 Q 个任务载荷加 Worker 栈。不要为每个请求创建线程或 goroutine。Python 的 ThreadPoolExecutor 提供 max_workers，但提交量无界时仍需要应用层的有界接纳策略。
第三步：选择接纳和背压
可以非阻塞提交、限时等待或按优先级拒绝。返回稳定的过载码，只有确认安全时才给 Retry-After。满队列上无限等待可能卡住请求链路；无界队列则会把过载变成延迟和内存增长。
submit(job, deadline):
if stopping or deadline expired: return REJECTED
if queue.try_push(job): return ACCEPTED(job.id)
if policy == WAIT and wait_until(deadline) and queue.try_push(job):
return ACCEPTED(job.id)
return OVERLOADED第四步：实现协作式取消
把取消 context 传给任务。尚未开始的任务可以移除；执行中的任务要在安全点检查取消，并把信号传给下游客户端。线程通常不能被安全强杀，因此要定义不可中断 I/O 的“已取消”语义。
第五步：让重试只有一个归属层
选择由 Pool、任务处理器或持久化队列中的一层调度重试。限制次数，使用带抖动的指数退避，并区分可重试和永久错误。否则多层超时会对同一依赖制造重试风暴。
第六步：关联结果和错误
返回任务 ID 或 future，不要共享可变结果槽。记录原始错误、尝试次数和终态。若采用轮询，要说明结果保留时间和鉴权；若采用等待，要说明调用方断开后任务怎么处理。
第七步：设计优雅关闭
关闭时先停止接纳，再按策略处理排队任务，让执行中的任务在截止时间前排空。Go 的流水线指南通过 done 信号传播取消；Worker Pool 也应遵循同样原则。超时后要报告未完成任务以便重放，只有契约明确时才能标记为放弃。
第八步：观测真正的瓶颈
记录队列深度和年龄、活跃 Worker、利用率、接纳/拒绝/取消数量、执行耗时、重试次数和下游错误。告警应关注持续队列年龄与拒绝率，而不只看 CPU。W 应依据下游连接池、外部限流或 CPU 容量设置。
权衡与边界
权衡一：固定 Worker 还是动态扩缩
固定数量容易预测并发并保护依赖。动态扩缩可以提高吞吐，但必须有全局硬上限，并统计每个副本的并发，否则各实例独立扩张会压垮下游。
权衡二：队列满时拒绝还是等待
拒绝能快速反馈并保护延迟；等待可以吸收短峰值，但必须有截止时间，不能长期占用稀缺请求线程。
权衡三：进程内还是持久化队列
进程内 Pool 延迟低、实现简单。持久化 Broker 增加恢复、重放能力和运维成本。若任务要跨部署、崩溃或多实例路由存活，应选持久化方案。
失败演练与演进计划
演练一：下游故障
让任务都慢速失败，观察队列年龄、拒绝、超时和有界重试，确认依赖不健康时并发不会继续膨胀。
演练二：大规模取消
提交 10,000 个任务，执行前取消一半，并在排空期间停止服务。确认排队取消任务不会执行，已接收的执行中任务最终都有可报告状态。
演练三：副本滚动发布
滚动发布期间同时运行两个版本，确认每个实例遵守本地上限；需要系统级上限时，再验证持久化队列或全局限流器。
常见错误与追问
错误一：无界缓冲
无界队列只是在隐藏过载，最终会表现为内存或延迟崩溃。容量和拒绝策略必须可观测。
错误二：重复重试
HTTP 客户端和任务处理器同时重试会相乘。指定单一重试归属，并传递尝试次数。
错误三：把取消当作强杀线程
多数运行时不能安全强杀任意任务。使用协作式检查、可取消 I/O 和明确的放弃策略。
错误四：排空前不停止接纳
新任务会让队列永远非空。等待排空截止时间前先关闭接纳。
错误五：忽略副本级并发
10 个副本各有 20 个 Worker 就是 200 个并发调用。要说明上限是本地、分片还是全局协调。
错误六：没有结果保留策略
future 和轮询记录都需要过期、鉴权和失败路径，否则已接收任务会造成无界存储。