HDUO Lab

深度剖析：跨机房 Federation 链路高延迟引发的 RabbitMQ 内存雪崩与路由风暴

作者：

ningniu

在

结论先行：跨机房部署 RabbitMQ Federation 时，高延迟 WAN 链路配合过大的 prefetch-count 会触发 Erlang VM 内存雪崩。解决方案：将 Upstream 的 prefetch-count 下调至 100-500，调优底层 TCP 发送窗口，并强制配置 max-hops=1 彻底阻断 AMQP 路由环路。以下是故障现场复盘。

凌晨两点半，告警群被 P99 投递延迟报警刷屏。生产环境一组基于 RabbitMQ 3.11.15 (Erlang 25.3) 构建的双活集群由于跨机房专线拥塞，引发了连锁反应：上游集群触发 vm_memory_high_watermark 导致全量生产者被 Connection.Blocked 阻塞，核心交易链路短时瘫痪。

为什么高延迟WAN链路会击穿 Federation 的内存防线？

排障的第一步永远是看现场指标。通过 rabbitmq-diagnostics memory_breakdown，我发现上游集群的内存消耗并非由于 Queue 中积压了大量 Ready 消息，而是 connection_readers 和 connection_writers 占用了接近 6GB 内存。

本质上，RabbitMQ Federation 插件是一个运行在下游（Downstream）集群内部的 AMQP 客户端。它会在上游（Upstream）声明一个内部队列（通常命名为 federation: exchange_name -> target），然后通过 AMQP 协议的 basic.consume 不断拉取消息。

当 WAN 链路出现 50ms 以上的延迟波动时，灾难的种子就埋下了：

  1. 默认无限制的信道窗口：如果不显式指定，Federation 链路会使用默认较大的 prefetch_count（或者受限于网络吞吐）。

  2. Erlang 的异步发送机制：上游的 Channel 进程在收到 ACK 之前，会将 In-flight（飞行中）的消息保存在 Erlang 进程字典和底层 TCP Socket 缓冲区中。

  3. 内存急剧膨胀：延迟飙升导致下游 ACK 返回极慢。上游积压了大量 Unacked 消息，Erlang VM 为了维持吞吐，不断分配 Binary Heap。当总内存触及 vm_memory_high_watermark.relative = 0.4 的警戒线时，RabbitMQ 启动自保，触发全局内存告警，挂起所有发送消息的 TCP 连接。

抓取底层网络包也能印证这一点：

# 查看堆积在 TCP Send Buffer 里的数据量
ss -tnpi | grep -A 1 5672

你会看到 wmem_alloc 和 cwnd 极大，数据卡在内核态发不出去，上层 Erlang 进程不断重试分配内存。

隐藏在 Binding 下的无限反射：路由风暴溯源

在控制住了内存水位（临时调大 watermark 阈值放行流量）后，我发现上游的 TPS 曲线呈现出不自然的周期性锯齿。查阅日志，发现了大量重复的 x-received-from Headers。

这就是跨机房双活的第二个大坑：AMQP 路由风暴。

在双向同步（Active-Active）架构中，A 机房的 Exchange 同步给 B 机房，B 机房的 Exchange 又配置了 Federation 同步给 A 机房。如果路由控制不当，一条消息会在 A 和 B 之间像乒乓球一样无限反射。

Federation 防止环路的核心机制是附加 AMQP Header：

  • 消息离开 A 机房时，被打上 x-received-from: A-node-name。

  • 消息到达 B 机房，B 尝试转发回 A 时，检查 Header 发现 A 已经存在，则丢弃。

但坑在于：如果你使用的是 HAProxy 等四层负载均衡连接 Upstream，或者节点重启导致 Node Name 发生变化，Header 的防环检测就会失效。此时 max-hops 参数就成了最后一道防线。如果没配，消息默认会跳跃多次，导致内部网络带宽被无效的 AMQP Framing 完全榨干。

核心调优与防御性配置落地

废话不多说，直接上修复方案和最终配置。我们要从应用层协议栈到底层内核参数进行全面限制。

1. 收紧 Federation 链路的 QoS

重置 Upstream 参数，严格控制 prefetch-count 和 max-hops。

# RabbitMQ 控制台执行，动态更新 Federation Upstream
rabbitmqctl set_parameter federation-upstream my-cross-dc-upstream \
'{"uri":"amqp://sync_user:password@remote-haproxy:5672", 
  "prefetch-count": 200, 
  "max-hops": 1,
  "reconnect-delay": 5,
  "ack-mode": "on-confirm"}'

注：prefetch-count: 200 是经过网络带宽延迟乘积（BDP）计算的折中值，既保证了基本吞吐，又避免了延迟突发时的内存爆仓。ack-mode: on-confirm 确保消息在落盘后再回执，防止脑裂丢数据。

2. 底层 TCP 缓冲区调优

在 rabbitmq.conf 中调整与 WAN 链路适配的 TCP 缓存参数，防止底层协议栈吃光内存后反压至 Erlang 层。

# /etc/rabbitmq/rabbitmq.conf
## 针对高延迟网络调优 TCP Write/Read Buffer
tcp_listen_options.sndbuf  = 131072
tcp_listen_options.recbuf  = 131072
tcp_listen_options.backlog = 1024
tcp_listen_options.nodelay = true

## 开启信用流控告警
vm_memory_high_watermark_paging_ratio = 0.75

3. 清理残留的无效 Binding

路由风暴往往伴随着错误的内部绑定。使用以下命令排查并清理：

# 过滤查看内部的 federation 绑定关系
rabbitmqctl list_bindings -p / | grep 'federation:'

如果发现某些已废弃机房的临时 Queue 还在，坚决通过 rabbitmqadmin delete queue name='...' 干掉，防止死信不断积压。

常见问题

Q1：跨机房同步，Shovel 和 Federation 到底该怎么选？ Federation 是基于 Exchange 拓扑的声明式同步，适合大面积的“状态复制”（如配置广播、多活全量同步），但其隐藏了内部队列，出故障时排查成本高。Shovel 是明确的点对点队列搬运工，属于典型的“硬连接”，结构简单且极度可控。如果是核心交易数据的跨机房灾备，我强烈建议使用 Shovel；如果是常规业务的多活路由，再考虑 Federation。

Q2：Federation 链路状态显示 running，但消息就是不同步怎么排查？ 大概率是网络半连接（Half-Open）或者 AMQP 协议层的死锁。直接看下游节点的内部 Queue 堆积情况。使用 rabbitmqctl list_queues name messages_unacknowledged 过滤 federation: 开头的队列。如果 unacknowledged 居高不下，说明网络回包被丢弃。结合 tcpkill 或重启 Federation link 插件即可快速恢复。

Q3：如何精准监控 Federation 的积压情况？ 不要只盯上游业务队列。必须监控下游针对上游自动生成的内部队列积压。建议在 Prometheus Exporter 中增加正则匹配： rabbitmq_queue_messages_ready{queue=~"federation:.*"}。只要这个指标突破 1000，立刻触发 P2 级告警检查专线质量，否则等待你的就是全线上游节点的熔断。

更多文章