常见的RabbitMQ消息模式及何时使用它们？

RabbitMQ消息模式决定了是一个工作者处理任务、每个订阅者接收事件，还是一个服务等待回复。如果选择了错误的模式，系统可能会重复工作、丢失有用的事件，或者在应该保持异步的调用上阻塞。

RabbitMQ提供了交换机、队列、绑定、确认和消息属性。有用的设计工作是选择这些组件如何适应你的应用程序。常见的模式包括工作队列、发布/订阅、直接或主题路由，以及请求/回复。

---

工作队列：在工作者之间分配任务

工作队列模式，通常称为任务队列，是最简单且最常见的消息模式，用于在多个工作进程（消费者）之间分发耗时的任务。

工作原理

1. 生产者将任务（消息）发送到单个队列。
2. 多个消费者（工作者）监听同一个队列。
3. RabbitMQ将每条消息传递给一个消费者，因此工作者共享积压的任务。

默认情况下，RabbitMQ以轮询方式在活跃消费者之间分发消息。如果一个工作者处理慢任务而另一个处理快任务，这种分发并不总是公平的，因此通常将此模式与确认和预取限制结合使用。

使用确认

通过手动确认，工作者在任务完成时通知RabbitMQ。如果工作者在发送basic_ack之前死亡，RabbitMQ可以重新排队并将该消息重新传递给另一个消费者。这使得工作队列对于报告生成、图像处理、计费任务或任何你不想静默丢弃的任务非常有用。

设置预取计数

basic.qos控制一个消费者一次可以持有的未确认消息数量。对于慢速、不均匀的任务，prefetch_count为1是一个安全的起点，因为RabbitMQ在该消费者确认第一条消息之前不会向其发送第二条任务。对于较快的任务，在测量吞吐量和内存使用后，可以提高该值。

实现示例（概念性）

# 消费者设置以实现公平调度
channel.basic_qos(prefetch_count=1)
channel.basic_consume(queue='task_queue', on_message_callback=worker_function)

# 工作者逻辑必须在成功处理后发送确认
worker_function(ch, method, properties, body):
    # 处理任务...
    ch.basic_ack(delivery_tag=method.delivery_tag)

发布/订阅：广播事件

发布/订阅模式旨在同时向多个感兴趣的消费者广播消息。与工作队列不同，工作队列中每条消息只由一个消费者消费，而发布/订阅确保每个连接的订阅者都收到消息的副本。

使用扇形交换机

生产者发布消息到扇形交换机。交换机忽略路由键，并将消息复制到绑定到它的每个队列。每个订阅者通常有自己的队列，因此一个日志服务、一个指标服务和一个审计服务都可以接收同一事件而无需竞争。

用例

• 实时通知： 向每个应用实例广播维护模式事件。
• 日志分发： 将同一日志事件发送到归档服务和告警服务。
• 缓存失效： 在数据库更改后通知所有服务实例清除本地缓存。

实现技巧

对于短期订阅者，创建一个排他、自动删除的队列，并将其绑定到扇形交换机。对于持久订阅者，使用持久队列，以便订阅者可以回来读取其离线期间到达的消息。

直接和主题路由：选择性发送事件

虽然扇形交换机提供盲目广播，但AMQP提供了用于选择性发布的交换机，扩展了发布/订阅模型。

直接交换机

消息根据消息的路由键与队列的绑定键之间的精确匹配路由到队列。当需要针对不同类型的消费者时，这非常有用。

例如，日志发布者可以发送带有路由键如error、warning和info的消息。告警队列可以只绑定到error，而归档队列可以绑定到所有三个严重级别。

主题交换机

这是最灵活的交换机类型，允许绑定键和路由键使用通配符。路由键被视为分隔列表（例如，使用句点.）。

• * 匹配一个单词。
• # 匹配零个或多个单词。

像orders.us.created这样的路由键可以发送到绑定到orders.*.created的欺诈队列和绑定到#.us.#的美国运营队列。当路由规则是真实的业务类别而不仅仅是一个固定字段时，使用主题交换机。

请求/回复：请求特定响应

请求/回复模式允许客户端应用程序发送请求消息并同步等待工作者（服务器）的回复。尽管消息传递本质上是异步的，但此模式在消息总线上模拟传统的远程过程调用（RPC）。

使用reply_to和correlation_id

1. 客户端将请求发送到队列，例如rpc_queue。
2. 客户端将reply_to设置为其正在消费的回调队列。
3. 客户端设置唯一的correlation_id。
4. 工作者处理请求并将响应发布到reply_to队列。
5. 客户端通过检查correlation_id将响应与原始请求匹配。

用例

• 服务查找： 从另一个服务获取用户配置文件或功能标志。
• 短决策： 在接受订单前检查库存。

谨慎使用

请求/回复很有用，但它将同步等待带回了消息传递系统。设置客户端超时，处理重复回复，并避免对长时间运行的任务使用RPC。对于慢速工作，发布命令，返回作业ID，并单独发送进度或完成事件。

概念性RPC流程

graph TD
    A[客户端（请求者）] -->|1. 请求消息（包含reply_to, correlation_id）| B(RPC请求队列);
    B --> C[服务器（工作者）];
    C -->|2. 处理请求|
D[结果];
    D -->|3. 回复消息（通过reply_to，保持correlation_id）| A;

---

常见RabbitMQ模式一览

模式	交换机类型	路由机制	关键特性	主要用例
工作队列	默认或直接	工作者共享一个队列	一条消息，一个消费者	负载均衡长时间运行的任务
发布/订阅	扇形	忽略路由键	一条消息，所有绑定队列	系统广播，日志记录
直接路由	直接	精确匹配路由键	选择性定位消费者	基于严重性或类型的路由
主题路由	主题	通配符匹配（*，#）	灵活、复杂的路由	微服务通信，事件流
请求/回复（RPC）	直接（用于回复）	使用reply_to和correlation_id	模拟同步API调用	即时服务查找，小事务

要点

从通信的形状开始。当恰好一个工作者应该处理一个任务时使用工作队列，当每个订阅者应该看到一个事件时使用发布/订阅，当只有部分订阅者应该看到它时使用直接或主题路由，只有当调用者真正需要立即回答时才使用请求/回复。