队列无法解决过载 (2014)
人们常常把队列加入软件系统，希望它们能应对过载，但这里的工程师认为，队列只会平滑短暂的突发峰值，并可能掩盖更深层的容量问题；如果到达率超过处理率，还会导致无限延迟或灾难性失败。他们将队列与负载丢弃、背压、公平或加权公平排队以及自动扩缩容等替代方案进行对比，强调这些方法都只是关于延迟、可用性、复杂度和成本之间的权衡，而不是银弹。多条评论指出，排队论、细致监控以及识别真正瓶颈，是设计弹性强、性能好的系统所必需的。
队列、过载与权衡
- 强烈共识：队列不会“修复”过载；它们只是缓冲过载。如果长期到达率 > 服务率，队列就必须增长，或者必须丢弃负载。
- 队列有助于平滑短暂峰值和隐藏抖动，但如果把它们当作神奇的可扩展性解决方案，就会适得其反。
- 无界或非常大的队列会导致“bufferbloat”：巨大的延迟、被掩盖的问题，以及更困难的恢复。通常更偏好有界且能快速失败的队列。
负载丢弃、背压与客户端行为
- 负载丢弃和背压被描述为明确、诚实的权衡：服务的请求更少 vs. 更高复杂度 vs. 更高延迟。
- 有人认为“忽略”超额请求并强制调用方通过幂等 API 重试是合适的；也有人认为这只是把队列转移到了别处。
- HTTP 429 + 指数退避被认为是一种实用模式；但天真的重试可能会让过载更严重。
自动扩缩容与容量上限
- 一派认为自动扩缩容在实践中对大多数产品都能“解决”过载；另一派则强调成本、无法扩展的组件（数据库、第三方服务）以及云资源限制。
- 多条评论指出，在不解决数据库或 IO 瓶颈的情况下扩展无状态服务，可能会让情况更糟。
排队论与利用率
- Little 定律和基本排队结果被频繁引用：接近 100% 的利用率即使容量≈需求，也会产生非常长的队列。
- 推荐实践：将利用率保持在明显低于 100% 的水平（通常约 80%），以维持可接受的延迟。
- 文中还推荐了若干关于排队论、调度以及亚稳态故障的资源和书籍。
公平排队、优先级与产品
- 公平/加权公平排队被强调为有益：隔离行为异常的客户端，强制执行各类别的容量份额，并能优先处理关键流量。
- 在持续过载下，优先级队列可能使低优先级工作饿死；公平排队有帮助，但无法违背基本容量数学。
- 一些参与者推广实现 WFQ 和基于并发限制的系统，尤其适用于 AI 和 API 负载。
监控、设计与反模式
- 队列本身并不坏；问题来自无界缓冲、缺少 SLA 以及没有监控。
- 建议指标：队列深度、在队列中停留的时间、队列多久清空一次，以及工作线程活动。
- 更广泛的观点是：许多团队在没有先测量或理解真实瓶颈的情况下就加入队列、缓存或 shim，最终导致脆弱的系统。