队列网络、扇出与瓶颈迁移：积压清理与安全容量
消费者从每秒 1,000 扩到 2,000，积压清空时间却没有减半——因为数据库每秒 3,600 次访问的上限把业务处理限制在 1,200。本页把多层队列、扇出放大与共享瓶颈纳入同一张流量守恒账，推导净追赶时间与安全容量。
队列网络与扇出
生产请求通常经过一串排队节点。对一个节点，输入率高于长期服务能力时，积压随时间增长；前置节点的空闲容量不能补偿后置数据库或远程服务的饱和。逐层提高线程数、连接数或批次上限，可能只把排队从应用线程池搬到数据库锁、Broker 或网络缓冲区。
扇出会把一次逻辑请求变成多个资源消耗。若一个请求以概率 p 重试一次，单层期望尝试数为 1 + p；多层独立重试时，总放大近似为各层期望尝试数的乘积，但现实中的失败相关性会让放大集中出现在最差时段。预算应按端到端 deadline 约束总尝试次数，并优先选择一个负责重试的边界。
对容量为 μ、到达率为 λ 的稳定单服务台 M/M/1 模型，要求 λ < μ，平均系统逗留时间为 1/(μ-λ)。当 λ 接近 μ 时，微小流量增量会造成显著排队增长；这是模型解释的非线性，不是可直接套用的生产预测。多服务台、非指数服务时间、批量、优先级和共享锁都会改变结果。
积压清理与安全容量
设积压量为 B 个工作项，新增到达速率为 λ，恢复期间可持续处理速率为 μ，且 μ > λ，忽略工作大小差异时，清空时间近似为 B / (μ - λ)。若恢复时停止新增流量，才可简化为 B / μ。因此只报告"消费者处理 QPS"不足以描述恢复能力，还要报告新增流量、毒消息比例、资源争用和可用于追赶的余量。
计划容量要以安全工作区间为单位：正常负载、单节点或单区失效后的负载、后台重建负载和积压追赶负载分别评估。所有这些工作同时使用数据库、网络和 CPU；如果把余量重复分配给每种工作，整体方案仍可能超载。限制重建速度会延长恢复时间但保护在线请求，扩大追赶速率则需验证是否把故障扩散到依赖。
背压只有在上游能减速、拒绝或持久化暂停点时才形成闭环。TCP 流控限制字节传输，不能自动约束已经写入应用队列的业务任务；消费者停拉但生产者继续接受并写入无界缓冲也不构成系统级背压。
完整案例：从组件模型到端到端流量守恒
本页的故障余量、背压与级联分析参考 Google SRE 过载与级联故障，重试成本参考 AWS 超时与抖动。M/M/1 只是明示假设的教学模型，不能把上述经验变成"所有系统达到某利用率就必然崩溃"的定律。
合成消息加工系统每秒接受 800 条业务事件，每条需要 2 次数据库读和 1 次写；消费者原有安全处理速率每秒 1,000 条。数据库在当前访问混合下安全上限为每秒 3,600 次访问，因此即使消费者无限扩容，数据库约束下总业务处理也不能超过 3,600/3=1,200 条/秒。若不同读写成本不相等，这种等权访问模型必须改成按 CPU、I/O 或锁需求加权，而不能只数调用次数。
现在有 B=240,000 条积压。按原消费者 1,000 处理、800 新到达，清空需 240,000/200=1,200 秒，即 20 分钟。若应用扩到宣称每秒 2,000，数据库仍限制每秒 1,200，净追赶只有 400，理想清空 600 秒；还未给线上查询和恢复重建保留余量。把 240,000 除以 2,000 得到两分钟，是同时漏了新增流量与共享瓶颈。
若对数据库保留 600 次访问/秒给线上交互及重建，消费者可用为 (3,600−600)/3=1,000 条/秒，仍然只能 20 分钟清空。若业务要求 10 分钟内清空，则需 800+240,000/600=1,200 条/秒消费，加上预留后数据库要支持 1,200×3+600=4,200 次访问/秒。可选择增加实际下游能力、减少每事件访问、暂停某些新流量或接受更长恢复目标，不能通过改监控阈值达到目标。
多层排队与故障时序
t0 消费者多扩 10 个实例；t5 每实例连接池全部打开；t10 数据库锁和连接等待增长；t15 消费超时，消息未提交位点又重投；t20 同一业务事件同时出现在多 worker，执行工作增加但业务完成量下降。提高消费者批量可能进一步延长事务，导致锁持有时间更长。
每层应分别记录在途数、等待时间和最老项年龄：Broker lag 是记录或位点距离，不一定代表秒数；数据库连接等待不同于执行时间；一个大任务可能支配 CPU 却只算一个 lag。毒事件反复失败会阻塞有序分区，不能通过平均 lag 看作健康。恢复控制还需区分可跳过、可隔离、必须保持顺序的业务，死信处理也要稳定身份与人工恢复责任。Kafka 位点与重放的组件机制见Kafka消费位点与重平衡。
Kafka 3.7.1 的事务状态可在 TransactionManager核对：sendOffsetsToTransaction 要求处于事务中，beginCommit 转到提交阶段并排队 EndTxn 请求。消费处理、位点和外部数据库不是天然同一事务，单纯增大并行度可能扩大"数据库已提交但位点未提交"的重放窗口。若使用数据库业务键去重，重复尝试仍消耗资源，幂等不等于免费。
两个方案的真实交换
方案 A 按数据库可用能力反向设置消费者速率和并发上限，每秒 1,000，接受 20 分钟恢复；优势是保护在线用户和稳定处理，代价是积压保留空间更大、恢复更慢。它需要入口新流量受控，不然一旦新到达超过消费，恢复目标又失效。
方案 B 优化每事件数据库访问，将原两读一写改为一次经验证的批量裁决或消除冗余读，平均需求降到两次等价访问。在同样预留下，理想可支持每秒 1,500 事件，净追赶 700，清空约 342.86 秒。代价是更大批次的部分失败、锁持有和幂等粒度；若批量操作改变事务语义或不变量，不能只为吞吐采用。
真正背压是上游收到可行动的容量信号后减速、拒绝或暂停到可恢复位点。消费者停止拉取而生产者继续无限写应用内存，不是闭环；Broker 持久化可以移走堆内存压力，但磁盘、保留与用户时限仍有限。对不可拒绝的业务先明确最大受理量和持久化义务，再谈削峰。
扇出与毒消息：等价访问量决定净追赶，而非消息条数
正文用"每事件 3 次访问"推导净追赶，但真实系统里每条事件的访问成本并不相等：毒消息会反复重试，扇出型事件会让一次逻辑处理变成十几次数据库访问。二者都会抬高"等价访问量"，让按条数算出的清空时间失效。
毒消息：若 2% 的事件需要重试 3 次（每次仍是 3 访问），平均每事件访问为 0.98×3+0.02×9=3.12。数据库上限 3,600/s 换算成业务处理能力 3,600/3.12≈1,154/秒，净追赶 1,154−800=354/秒，清空 240,000 积压需要约 678 秒，而不是按 3 访问算出的 600 秒。毒消息比例升到 10% 时访问量 0.9×3+0.1×9=3.6，能力降到 1,000/秒，净追赶只剩 200/秒，清空回到 1,200 秒——与完全不优化的基准相同。
扇出：若 5% 的事件是批量型，单个事件触发 10 倍下游访问，平均每事件 0.95×3+0.05×30=4.35，能力 3,600/4.35≈828/秒，净追赶仅 28/秒，清空需要约 8,700 秒（约 2.4 小时），而且对到达率的微小上升极度敏感：到达从 800 升到 828，清空时间趋于无穷。这说明"按条数扩消费者"在有扇出与毒消息时几乎无效，必须先把等价访问量降下来或隔离昂贵事件。
执行 python3 labs/capacity_models.py fanout_poison：输入积压 240,000、到达 800、DB 3,600、基准 3 访问。预期输出 poison_2pct={accesses:3.12, cap:1153.85, drain_s:678.3}、fanout_5pct={accesses:4.35, cap:827.59, drain_s:8700.0}。脚本是确定性算术，不模拟重试退避与真实扇出分布。
两种方案：A 统一队列，靠扩容消费者吸收一切，简单但毒消息与昂贵事件会阻塞普通事件并抬高平均成本；B 按事件成本分级（普通/昂贵/毒消息隔离），给昂贵事件单独配额与死信路径，复杂但净追赶可预测。本例选 B，并把"等价访问量"作为容量报表的一等指标——只报条数与 QPS 会掩盖成本分布。
可运行模型与架构师变化条件
运行 完整实验脚本：
python3 labs/capacity_models.py network输入上述积压与访问上限，预期清空时间分别为 1,200 秒、无预留消费者2000时 600 秒、有预留且减访问后约 342.86 秒；脚本在 μ 不大于 λ 时不报告有限清空时间，而标为无法追平，model=shared-bottleneck-drain-not-load-test。本轮该公开脚本及断言已运行；真实负载与压测未运行。
再把新流量改为每秒 1,100：A 的消费能力只有 1,000，积压每秒反增 100；B 还有每秒 400 余量，但需验证真实数据库成本和批量失败。把 10% 事件改为成本 10 倍，等权三访问模型失效，必须重建工作量分布。最后在纸上加入重建任务与读查询，检查是否重复使用了同一余量。
交付每层需求矩阵、瓶颈迁移时间轴、净恢复计算、毒消息分支与速率控制阈值。保留原始模型与条件变化后的修订，说明哪些来自源码、哪些是计算与假设。可选专家可使用更符合服务分布的排队或离散事件模拟，但复杂模型不替代准确的工作负载输入。
闭卷验收
本页 8 道闭卷题收进了下方自测面板：先回忆，再展开参考答案与评分点，最后给三档自评。