RabbitMQ流控是资源紧张时对生产者的强制暂停机制，通过connection.blocked帧阻塞连接/通道，不丢消息、不报错；触发条件为内存达vm_memory_high_watermark（默认0.4）或磁盘剩余低于disk_free_limit（默认50MB），并存在基于credit的进程级微流控。
RabbitMQ 的流控机制（Flow Control）不是“限速开关”，而是服务端在资源濒临耗尽时，对生产者发起的强制暂停信号——它会让 connection 或 channel 突然卡住，发不出新消息，直到资源压力缓解。
流控本质是连接级阻塞，不是队列丢弃
很多人误以为流控像 x-max-length 那样会丢消息或拒绝发布，其实不是。流控触发后，生产者调用 channel.BasicPublish() 不会报错、不抛异常，只是无限等待——因为底层 TCP 连接被 RabbitMQ 主动置为 “blocked” 状态，AMQP 协议通过 connection.blocked 帧通知客户端暂停发送。
- 这个阻塞是双向的：所有该连接上的
channel全部暂停，哪怕只有一条 channel 在发消息 - 消费者不受影响：流控只压制生产者，已入队的消息照常被消费
- 客户端无感知风险：.NET/Java 客户端默认不监听
BlockedListener，线程可能卡死在BasicPublish上数分钟
触发流控的两个硬性指标：内存和磁盘
流控不是凭空触发的，只响应两类系统级资源告警：
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
-
vm_memory_high_watermark：默认值0.4，即节点 Erlang VM 内存使用率达总内存 40% 时触发。注意：这里统计的是整个节点内存，不是单个队列；非持久化消息占大头 -
disk_free_limit：默认值50MB，即磁盘剩余空间低于该值时触发。一旦触发，所有新消息（含持久化）都会被阻塞，防止磁盘写满导致崩溃
这两个阈值任一满足即进入全局流控，Web 管理界面中对应 connection 状态会显示为 blocked，而不是 running。
容易被忽略的第三类流控：进程内信用流控（Per-Connection Flow）
除了内存/磁盘这种“大喘气式”长时阻塞，RabbitMQ 还有更细粒度的“微阻塞”——基于信用（credit）的进程内流控，发生在 reader → channel → queue process 消息流转链路上。
- 它不依赖配置，完全由 Erlang 进程间吞吐匹配动态触发，比如 queue process 处理不过来，就会向上游 channel 申请更少 credit
- 这种流控在 UI 中显示为黄色
flow状态，持续时间通常 - 客户端无法监听或干预：它发生在 broker socket 接收层，
BasicPublish调用仍会返回成功，但实际数据被压在 TCP 缓冲区里出不去
真正棘手的不是流控本身，而是它不报错、不超时、不重试——你得靠监控 connection 的 blocked 状态、Erlang 进程的 flow 标记、以及客户端是否意外卡在 publish 调用上，才能定位问题。内存水位和磁盘空间只是表象，背后是生产/消费节奏彻底失衡。
