RabbitMQ系列04 - 流控与信用机制

RabbitMQ 流控：内存磁盘告警与连接级信用机制

当生产速率持续高于消费与落盘能力 时，Broker 必须先保护自己 ，否则可能 OOM 或磁盘打满。RabbitMQ 上常见两类手段：一是内存/磁盘水位触发的全局阻塞 ；二是进程间基于「信用」的反压，从慢环节一路传导到网络读端。本文区分二者并说明其关系；阈值与指标以当前版本文档为准。

两类机制对照
全局流控：内存与磁盘告警
[Erlang 进程邮箱为何会把节点撑爆](#Erlang 进程邮箱为何会把节点撑爆)
连接级（内部）流控：credit-based
反压如何沿管道传导
[与消费者 prefetch 的关系](#与消费者 prefetch 的关系)
运维上可观察的现象
免责声明

两类机制对照

类型	常见叫法	触发/作用范围	典型现象
资源告警	Global flow control（概念上）	内存或可用磁盘低于配置水位	阻塞或暂停集群内全部连接上的流量（行为细节依版本）
内部流控	Per-connection / internal flow control	单条连接内部管道	该连接上发布端被限速，直至下游处理跟上

二者可同时存在：全局是「节点要死了先踩刹车」；连接级是「平时别把一个慢消费者拖垮整条内部流水线」。

全局流控：内存与磁盘告警

资源	通俗含义
内存告警	节点上可被消息占用的内存逼近上限；Broker 倾向阻塞发布者，避免继续堆堆内/堆外结构导致崩溃。
磁盘告警	持久化消息需要落盘；磁盘剩余空间过低时同样会限制写入。

具体阈值、是否 block、paging 等策略随 RabbitMQ 版本与配置项变化，排障时应对照官方 Alarms、Resource Limits 章节。

text 复制代码

  ┌──────────────────────────────────────────┐
  │  Broker 节点                               │
  │  内存高水位 / 磁盘低水位 ──► 全局 block 发布  │
  └──────────────────────────────────────────┘

Erlang 进程邮箱为何会把节点撑爆

RabbitMQ 基于 Erlang/OTP ：大量逻辑跑在轻量进程 里，进程间通过邮箱（mailbox）异步收消息。邮箱默认没有硬上限 时，若某进程处理慢于到达速率，邮箱会无限增长 ，最终内存飙升乃至节点不稳定。

生产快、消费慢 且缺乏内部反压时，热点路径上的进程邮箱会先顶满，进而触发更大范围的阻塞或告警。

连接级（内部）流控：credit-based

RabbitMQ 使用基于信用（credit-based）的机制限制发送侧 速率，使任一环节的处理速度成为瓶颈时，上游不会无界堆积：

监控各进程邮箱长度或等价背压信号。
某进程来不及处理 时邮箱增长，达到阈值则不再接收上游新消息。
其上游进程邮箱随之增长，再向上传导。
最终可传导到负责读网络数据 的进程，使 TCP 接收窗口层面的数据进入变慢。

效果：端到端 把发送速率钳在最慢一环能承受的范围内。

反压如何沿管道传导

邮箱积压达阈
继续向上
网络读进程
解析/路由相关进程
队列侧进程

text 复制代码

  下游慢 → 下游邮箱满 → 拒收上游
            → 上游邮箱满 → ... → 网络侧读变慢 → 对端 TCP 反压

与消费者 prefetch 的关系

Basic.Qos（prefetch） 限制未 ACK 消息数 ，让 Broker 不要一次性把大量消息推给处理很慢的消费者，从而：

改善多消费者公平性；
减少「消费者进程内堆积」；
与 Broker 内部 credit 流控 目标一致：避免整条链路无界缓冲。

prefetch 是消费端窗口 ；credit-based 多在 Broker 内部 ；两者配合才能从客户端到内核态形成完整背压故事。

运维上可观察的现象

线索	可能含义
管理 UI memory/disk alarm	全局资源告急，优先查堆积、持久化、磁盘与内存配置
Connection blocked 或发布卡住	可能处于全局或连接级流控
队列深度长期上涨	消费能力不足或单条消息处理过慢；调 prefetch、扩容消费者、优化业务
IO 等待、磁盘使用率	持久化与日志路径是否共盘、是否需扩容或清理

免责声明

Classic queue、Quorum queue、流控实现 随版本演进，生产排障请以 RabbitMQ 官方文档与当时告警原因为准。

主题：RabbitMQ、流控、背压、Erlang、内存告警、prefetch。