第24章：RabbitMQ 信用流控、Prefetch 调优与内存背压

1. 项目背景

大促预演：发布器 Confirm 很快，短信网关却每秒只能发几十条。有人把 prefetch 调到 1000「提前把货领到消费者内存」，Broker 的 unacked 下降了，消费者进程堆爆，GC 停顿后心跳超时，连接断开，消息重投，风暴回来。另一人 prefetch=1，吞吐腰斩，领导说 MQ 不行。运维看到的是内存水位（第 14 章）和 blocked 连接，开发看到的是 Confirm 超时，两边用词不一致。

流控其实有多层：

basic.qos prefetch → 每条 Channel/消费者能拿多少未 Ack（rabbit_limiter） AMQP 1.0 link credit → 信用证（本章以 0-9-1 为主） Connection 级 blocked → 内存/磁盘告警，停发布不停消费 Queue 进程邮箱 → 发布过快时 writer/reader 的 credit 与 mailbox quorum WAL/段 → 内存告警时 rabbit_quorum_memory_manager 触发 wal 滚动

第 9 章讲过 prefetch 与 Ack。本章要画出曲线：同一慢消费者，prefetch 三档，记录吞吐、unacked、Broker 内存、消费者 RSS。没有表就不许把「200」写进默认配置。

经典堆积主要在队列消息与消费者 unacked；quorum 还有 Raft 日志与 wal。告警时只停进水，所以调 prefetch不能解除第 14 章红灯，只能改变「货堆在 Broker 还是堆在应用」。

2. 项目设计

小胖把仓库提货单比成信用卡额度。

小胖：这不就是一次多领点货少跑腿吗？prefetch 越大越好。blocked 不就是水库关闸吗？关了发布自然慢，消费者慢慢吃就行，还调啥。为啥 quorum 还要单独一个 memory manager？

大师：多领货等于把仓库搬到面包车里，车先爆。prefetch 是应用侧缓冲区大小，不是越大越快：慢网关时 1 和 20 可能吞吐接近，200 只增加在途和重连损失。blocked 是整节点停发，那是最后防线；日常应让消费者跟得上，而不是靠红灯。quorum 内存告警时滚动 wal（min_wal_roll_over_interval），为的是释放可回收日志，不是给你把 prefetch 调到 2000。

技术映射：prefetch = 未 Ack 窗口；blocked = 节点资源告警；wal 滚动 = quorum 的泄洪辅助。

小白：Channel QoS 与全局 QoS 还支持吗？prefetch=0 表示无限吗？unacked 算进内存水位吗？慢消费时消息在 ready 还是 unacked？发布侧 credit 耗尽客户端会阻塞在哪？经典与 quorum 内存曲线差在哪？推荐值能不能写死？

大师：全局 QoS 已过时，用 per-consumer/channel qos。prefetch=0 在 0-9-1 常被当成不限制，禁止在生产支付/触达使用。unacked 占 Broker 内存（要跟踪投递状态），也占应用内存（消息体在客户端）。慢消费且 prefetch 小：货主要在ready；prefetch 大：货在unacked+应用堆。发布过快，reader 会对连接做流控，客户端表现为写阻塞或心跳失败，不一定立刻 Alarm。经典大堆积可落盘；quorum 堆积更贵。推荐值按场景：SAC 回调 prefetch=1～10；触达网关以网关 RPS 的 0.5～2 秒在途量为上限试 20；禁止 1000 当默认。

小胖：实验：消费者sleep(50ms)模拟网关，发布尽量快，三档 prefetch 各跑 30 秒，填表。再拧低内存水位看 blocked，确认调 prefetch 救不了红灯。

大师：三档不要并行打同一队列。每档之间等 unacked 归零。表头：prefetch、吞吐 msg/s、avg unacked、Broker memory、是否 blocked。

技术映射：rabbit_limiter:can_send/3决定队列能不能再投给该消费者。

小白：Confirm 与 prefetch 是不是一回事？mandatory Return 会不会占窗口？多 Channel 共用连接时流控怎么算？

大师：Confirm 管发布落地，prefetch 管消费在途，完全两层。Return 的是未路由，不占消费者窗口。一条连接多个 Channel，告警 blocked 是连接级；prefetch 是 Channel/消费者级。所以「一个支付一个 Channel」仍然值得（第 4 章）。

小胖：检查单：三档表签字；生产配置有上限；blocked SOP 仍走第 14 章；禁止用无限 prefetch 冲 KPI。

3. 项目实战

3.1 环境准备

单节点足够看曲线；内存绝对值用vm_memory_high_watermark.absolute。队列用 classicq.mkt.sms.lab避免打坏支付 quorum。

3.2 步骤一：慢消费者

# promo-mq/ch24/slow_consumer.pyimportargparse,time,pika ap=argparse.ArgumentParser()ap.add_argument("--prefetch",type=int,default=20)ap.add_argument("--sleep",type=float,default=0.05)args=ap.parse_args()c=pika.BlockingConnection(pika.ConnectionParameters("127.0.0.1",5672,"marketing",pika.PlainCredentials("app_mkt","mkt_dev_2026"),heartbeat=30,client_properties={"connection_name":f"ch24-pf{args.prefetch}"}))ch=c.channel()ch.basic_qos(prefetch_count=args.prefetch)n=[0]t0=time.time()defon_msg(ch,method,props,body):time.sleep(args.sleep)ch.basic_ack(method.delivery_tag)n[0]+=1ifn[0]%50==0:print("acked",n[0],"rps",n[0]/(time.time()-t0))ch.basic_consume("q.mkt.sms.lab",on_msg,auto_ack=False)ch.start_consuming()

坑：sleep 太长会心跳失败，50ms 安全；若要更慢，加大 heartbeat。
坑：BlockingConnection 不要多线程共享。

3.3 步骤二：快生产者

# promo-mq/ch24/fast_pub.pyimporttime,pika c=pika.BlockingConnection(pika.ConnectionParameters("127.0.0.1",5672,"marketing",pika.PlainCredentials("app_mkt","mkt_dev_2026"),heartbeat=30,blocked_connection_timeout=15,client_properties={"connection_name":"ch24-fastpub"}))ch=c.channel()ch.confirm_delivery()body=b'{"m":"x"}'t0=time.time()sent=0try:whiletime.time()-t0<30:ch.basic_publish("","q.mkt.sms.lab",body,properties=pika.BasicProperties(delivery_mode=2),mandatory=True)sent+=1exceptExceptionase:print("stopped",type(e).__name__,sent)print("sent",sent,"rps",sent/max(time.time()-t0,0.1))c.close()

先 declare durable 队列。跑 30 秒。若 blocked，pika 可能抛错或卡住，记分桶。

3.4 步骤三：三档测量

每档：空队列 → 起消费者 → 起发布 30s →list_queues name messages messages_unacknowledged→memory_breakdown→ 停发布等 Ack 完。

实验室网关 sleep=50ms 理论上限约 20 rps/单消费者。200 不会变成 200 rps。把这句话写进纪要。

运行结果：三行表。消费 rps 三档接近，unacked 随 prefetch 涨。

坑：档位之间没排空，数据叠在一起。
坑：多消费者时表要注明并发数。

3.5 步骤四：告警与 prefetch 无关

按第 14 章临时拧低 watermark，快发，观察connection.blocked。prefetch 无论 1 还是 200，发布侧都停。恢复水位。证明：背压分层，调 QoS 救不了红灯。

dockerexecrabbit-promo-n1 rabbitmqctl set_vm_memory_high_watermark absolute 50MB# 演示完必须改回 1200MB

3.6 步骤五：源码点名

• rabbit_limiter：prefetch/credit，can_send、ack_from_queue。
• rabbit_reader/rabbit_writer：连接收发与流控。
• vm_memory_monitor：水位。
• rabbit_quorum_memory_manager：内存告警时滚动 wal，有最小间隔。

现场不改 Erlang。支付 quorum 堆积请回到「加消费者或限发」，不要指望 prefetch=1 降低 Raft 已提交日志。

3.7 推荐值（推广中台）

配置中心要有上限校验。压测表附在变更单。

3.8 完整代码清单

promo-mq/ch24/ slow_consumer.py fast_pub.py measure.sh column/samples/ch24/

3.9 测试验证

值班检查单：改 prefetch 必附表；心跳与 sleep 匹配；绝对水位实验必须 finally 恢复。看到 unacked 远大于 rps×2 秒，先疑 prefetch 过大。消费者 RSS 涨而 Broker 降，说明货搬家了不是变快了。多 Channel 共用连接出现 blocked，所有业务一起停，回到第 4 章隔离。交接班念一句：红灯先停发再泄洪，不调 QoS 当魔法。

测量脚本把list_queues与memory_breakdown打时间戳存文件，禁止只靠感觉。三档必须同一机器同一队列类型，不要 classic 一档 quorum 一档横向比。若 Docker 限内存过小，先把第 3 章 absolute 水位设合理再测，否则全程 blocked 无曲线。

prefetch 推荐值要带单位语境：单消费者、sleep=50ms、payload 小于 1KB。换网关或换消息体必须重测，不得抄别组的 20。触达三个 Fanout 队列各有消费者，不要共用一个 Channel 的 prefetch 当三个网关的总额度——一个慢邮件会拖住同 Channel 上的短信（第 4 章）。发布被 block 时客户端分桶记blocked，超时不得写 SENT，与第 8、16 章同一纪律。慢消费导致 ready 堆积时，优先加消费者或降发布，而不是把 prefetch 调到 500「看起来 unacked 很忙」。unacked 忙只是货在路上。quorum 队列做同一实验时，表要加一列 Raft 内存，避免和 classic 比绝对值。实验室 sleep 切勿 5 秒，heartbeat 默认会先把连接打死，曲线变成重连噪声。

把三档表贴进默认配置的 PR 描述，没有表的 prefetch 变更直接打回。大促前只允许在预发改 QoS，生产临时改要有回滚值。看到消费者 RSS 与 unacked 同向爆炸，先杀应用的 prefetch 再查是不是内存泄漏。流控是保护，不是性能旋钮。领导要 TPS 数字时，用消费 rps 而不是发布 rps——快发慢吃的发布 rps 没有意义。

再补一层给值班：messages_unacknowledged与消费者数一起看。消费者=0 时 unacked 应为 0，ready 可以很高，那是第 15 章病例 D。消费者>0 且 unacked 长期等于 prefetch×人数，说明窗口打满、下游慢，此时加 prefetch 只会把窗口加大。正确动作是扩网关或降流量。内存曲线要分 queue_procs、binary、allocated，不要只看容器 CGroup 一个数。经典队列 paging 不是 4.x 主策略，不要用旧博客「page 到磁盘就好了」解释本章实验。发布器在 blocked 解除后可能突然打出积压在客户端的发送缓冲，像一次小风暴，需要在客户端也做解除后的限速。测量 30 秒太短看不出 GC，预发可拉到 5 分钟，但实验室三档×30 秒足够证明「200 不更快」。把 heartbeat 调到 60 时，sleep 仍不要超过 10 秒。多消费者竞争下 prefetch 是每人一份，总在途=人数×prefetch，表要写清。SAC 场景用第 23 章的 1～5，不要套本章触达的 20。流控与第 8 章 Confirm 超时叠加时，先看是否 blocked 再看网络，顺序与第 15 章 SOP 一致。

推荐值评审会只讨论表，不讨论感觉。没有 sleep 模拟的「纯内存 echo 消费者」会让三档都很快，那种表不能当网关依据。推广中台以真实网关 RPS 为分母。磁盘告警与内存告警都会停发，prefetch 实验期间若误触发，数据作废重来，并检查是否忘了恢复 watermark。这是第 14 章夹具纪律在中级篇的再现。客户端blocked_connection_timeout要小于产品等待阈值，以便快速失败转降级，而不是卡死收银台。

容量规划把「网关 RPS × 平均处理秒数 × 副本数」当成在途上限，prefetch 只是该上限在单连接上的切片。超过切片的部分应留在 Broker ready 里，这是设计而不是缺陷。压测报告禁止只贴发布端 TPS。慢消费者扩容优先水平加进程，每人仍用小 prefetch，总吞吐近似线性，总 unacked 也可预期。垂直把单进程 prefetch 加到 2000 会在崩溃时制造第 22 章式风暴。内存背压演习与 QoS 演习分开做，同一天可以做，但不要同一分钟拧水位又改 prefetch，否则分不清因果。把ch24-pf1等 connection_name 写进图表标题，方便对照 docker logs。经典队列 ready 堆积时磁盘会涨，实验前看 disk_free_limit，避免误入第 14 章红灯。得出推荐值后锁进配置模板，代码里不得再写魔法数字 1000。评审问「为什么是 20」时打开表，而不是现场编。若预发网关换成更快的供应商，整表重测，推荐值可上调但须重新签字。这就是中级篇调优与基础篇「先跑通」的差别。配置模板评审不通过就不得合并默认值。测试把三档表做成自动采集后，人工只负责签字，避免每次手抄 list_queues 抄错行。发现消费 rps 随 prefetch 明显上升，先怀疑 sleep 没生效或消费者不是慢网关，而不是高兴地宣布 200 更好。表不合格即重测，不得改数字交差。

4. 项目总结

优点与缺点

优点：1）用表说话。2）分层背压不再吵。3）与第 9、14 章闭环。
缺点：1）无全局最佳值。2）实验受 sleep/心跳影响。3）quorum 内存账更复杂。

适用场景

• 网关型慢消费者。
• SAC 回调。
• 预发定默认 QoS。

不适用：无限 prefetch 冲 TPS 榜；用 QoS 解除内存告警。

注意事项

• prefetch=0 禁止。
• 安全：流控不是权限。
• 版本：全局 QoS 不要再抄旧文。
• 容器用绝对水位。

常见踩坑（生产）

1. prefetch=1000 当加速器，发布一断重投一万。根因：在途过大。处理：降到网关窗口。
2. Alarm 时调大 prefetch。根因：货搬到应用，节点仍红。处理：第 14 章 SOP。
3. 三档测试并行。根因：曲线污染。处理：串行排空。

思考题

1. 两个 Channel 共享连接，一个触达一个支付，Alarm 时为何两业务一起死？架构如何拆？
2. quorum 在内存告警下滚动 wal，对 Confirm 延迟的影响你如何在预发量化？

（第 4 章连接隔离；第 19、27 章指标。）

推广计划提示

下一章把 guest 和明文 AMQP 换成 TLS 与 OAuth2/LDAP，安全评审才肯放行生产网。

附录 C：第 23 章思考题参考答案

题 1：VIP 插队 + 支付级 HA。
不要给 quorum 打 max-priority。拆两条 quorum：q.cs.vip与q.cs.normal，发布按级别选队列；或应用侧高优先发。支付回调继续 SAC quorum。经典优先队列只留实验室或可丢的咨询。

题 2：SAC + prefetch=200 切主。
最多 200 条 unacked 会重投给新主，重复处理窗口巨大。SAC 推荐 prefetch=1～5。第 24 章表已经表明 200 不提高慢消费者吞吐，切主时只放大事故。

延伸阅读与资源

SQLAlchemy 2.0从入门到进阶的实战之旅
Dify 从入门到进阶：LLM 应用平台实战修炼
Java 工程师进阶：从 JVM 生产排障到OpenJDK原理
NumPy 从入门到生产落地：全链路实战指南（科学计算/向量化）
Redis 8 实战精讲：从 CRUD 到源码，构建高可用缓存系统
Redis 实战修炼与原理进阶
Python 3实战精进：从脚本到高并发订单引擎
python入门：Rquests从菜鸟脚本到企业级SDK的网络实战圣经
Milvus向量数据库实战修炼：从 0 到 1精通向量检索与生产落地
MongoDB 实战进阶与内核修炼
后端工程师的 AI 转型第一课：Ollama 与私有化大模型实战
10倍开发者的 Dify 魔法书：从零构建全栈 AI 应用
后端工程师转型AI第一课-Ollama 与私有化大模型实战
大型语言模型(LLM) vLLM 高性能推理落地实战
Agent开发之LlamaIndex 实战修炼与源码进阶
大语言模型Transformers 实战修炼与源码剖析