rabbitmq

RabbitMQ 核心知识

完整参考：有关生产者模式（Node.js、Java、Python、Go）、消费者模式、安全配置和高可用性设置，请参阅 advanced.md。

深入了解：使用 mcp__documentation__fetch_docs，并将技术设为：rabbitmq，以获取全面的文档。

快速开始（Docker）

services:
  rabbitmq:
    image: rabbitmq:3-management
    ports:
      - "5672:5672"   # AMQP
      - "15672:15672" # Management UI
    environment:
      - RABBITMQ_DEFAULT_USER=admin
      - RABBITMQ_DEFAULT_PASS=admin

核心概念

概念	说明
交换机	将消息路由到队列
队列	用于存储消息的缓冲区
绑定	将交换机连接到队列的规则
路由键	用于路由的消息属性

架构

Producer ──▶ Exchange ──binding──▶ Queue ──▶ Consumer
                │
                ├── direct   (exact routing key match)
                ├── topic    (pattern matching)
                ├── fanout   (broadcast to all)
                └── headers  (header-based routing)

交换机类型

类型	路由方式	使用场景
direct	精确匹配键	任务队列、RPC
topic	模式（*.#）	事件路由
fanout	广播所有消息	通知
headers	匹配标头	复杂路由

# Topic exchange patterns
order.*        → matches order.created, order.updated
order.#        → matches order.created, order.item.added
*.created      → matches order.created, user.created

队列配置

参数	说明
x-message-ttl	消息过期时间（ms）
x-max-length	队列最大长度
x-dead-letter-exchange	用于被拒绝消息的 DLX
x-dead-letter-routing-key	DLQ 路由键
x-queue-type	classic、quorum、stream

不适合使用此技能的场景

• 需要回放的事件流——Kafka 提供持久化日志
• 超高吞吐量（>100k msg/s）——Kafka 或 Pulsar 的扩展能力更强
• AWS 原生架构——SQS 集成更好
• 轻量级消息传递——NATS 的运维更简单
• 需要符合 JMS 标准——ActiveMQ 提供 JMS API

反模式

反模式	不足之处	解决方案
未设置预取限制	消费者不堪重负	将 prefetch 设为 10-50
在 HA 中使用 classic 队列	节点故障时会丢失数据	使用 quorum 队列
未配置 DLX	有毒消息会无限循环	配置死信交换机
自动确认	崩溃时消息会丢失	使用手动确认
未启用发布者确认	消息会静默丢失	为关键消息启用确认

快速故障排查

问题	可能原因	修复方法
消息堆积	消费者处理缓慢或已停止	检查消费者数量和处理情况
内存使用率高	未确认的消息过多	降低预取量，增加消费者
消息未路由	路由键错误	检查交换机与队列的绑定
消息重复	消费者在确认前崩溃	实现幂等处理
发布者确认超时	Broker 过载	降低发布速率

生产环境检查清单

• 已启用 TLS/SSL
• 用户遵循最小权限原则
• 使用虚拟主机实现隔离
• 使用 quorum 队列实现 HA
• 已配置死信交换机
• 已设置消息 TTL
• 已配置预取限制
• 已启用发布者确认
• 已设置监控仪表板
• 已配置告警

参考文档

可用主题：basics、exchanges、queues、consumers、clustering、production