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。