【RabbitMQ】Simple模式 && 工作队列 && 发布/订阅模式 && 路由模式 && 通配符模式 && RPC模式 && 发布确认机制

文章目录

• • 一、Simple（简单模式）
  • [二、Work Queue（工作队列模式）](#二、Work Queue（工作队列模式）)
  • 三、Publish/Subscribe（发布/订阅模式）
  • • 概念介绍🐔
  • 四、Routing（路由模式）
  • 五、Topics（通配符模式）
  • 六、RPC（RPC通信模式）
  • [七、Publisher Confirms（发布确认机制）](#七、Publisher Confirms（发布确认机制）)

官方文档： RabbitMQ Tutorials | RabbitMQ

一、Simple（简单模式）

• 特点： 一个生产者P，一个消费者C，消息只能被消费一次，也称为点对点（Point-to-Point）模式。
• 适用场景： 消息只能被单个消费者处理

二、Work Queue（工作队列模式）

一个生产者P，多个消费者C1、C2。在多个消息的情况下，Work Queue会将消息分派给不同的消费者，每个消费者都会接收到不同的消息 。RabbitMQ 默认使用 轮询 （Round-Robin）分发给消费者。

• 特点： 消息不会重复，分配给不同的消费者。
• 适用场景： 集群环境中做异步处理
  • 比如 12306 短信通知服务，订票成功后，订单消息会发送到 RabbitMQ，短信服务从 RabbitMQ 中获取订单信息，并发送通知信息（在短信服务之间进行任务分配）
    

三、Publish/Subscribe（发布/订阅模式）

一个生产者P，多个消费者C1、C2，此外 X 代表交换机，它可以将消息复制多份，让多个消费者接收相同的消息。

生产者发送一条消息，经过交换机转发到多个不同的队列，多个不同的队列就有多个不同的消费者。

适合场景：消息需要被多个消费者同时接收的场景。比如：实时通知或者广播消息。

比如中国气象局发布 "天气预报" 的消息送入交换机之后，新浪、百度、搜狐、网易等门户网站接入消息，通过队列绑定到该交换机，自动获取气象局推送的气象数据。

概念介绍🐔

Exchange：交换机(X)

作用： 生产者将消息发送到 Exchange，由交换机将消息按一定规则路由到一个或多个队列中（上图中生产者将消息直接投递到队列中，实际上这个在 RabbitMQ 中不会发生）

Exchange 只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与 Exchange 绑定，或者没有符合路由规则的队列，那么消息就会丢失。

RabbitMQ 交换机有四种类型：fanout、direct、topic、headers，不同类型有着不同的路由策略。

1. Fanout ：广播策略 ，将消息交给所有绑定到该交换机的队列（Publish/Subscribe 发布订阅模式）
2. Direct ：定向策略 ，把消息交给符合指定 routing key 的队列（Routing 路由模式）
3. Topics ：通配符策略 ，把消息交给符合 routing pattern 的队列（Topics 通配符模式）
4. headers ：该类型的交换器不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中的 headers 属性进行匹配。（headers 类型的交换器性能会很差，而且也不实用，基本上不会看到它的存在）

Routing Key：路由键。生产者将消息发给交换器时，指定的一个字符串，告诉交换机应该如何处理这个消息（即告诉交换机将该消息发送到哪里去）

Binding Key：绑定键。交换器与队列通过 Binding Key 关联起来。队列在绑定交换机的时候一般会指定一个 Binding Key，告诉交换机要接收哪些消息。

比如下图：如果在发送消息时，设置了 Routing Key 为 orange，那么消息就会路由到 Q1。

当消息的 Routing key 与队列绑定的 Binding key 相匹配时，消息才会被路由到这个队列。

此外，Binding Key 其实也属于路由键中的一种，官方解释为: the routing key to use for the binding。可以翻译为：在绑定的时候使用的路由键。

大多数时候，包括官方文档和 RabbitMQ Java API 中都把 Binding Key 和 Routing Key 看作 Routing Key，为了避免混淆，可以这么理解：

• 生产者在发送消息的时候，需要的路由键是 Routing Key
• 队列在绑定交换机的时候，需要的路由键是 Binding Key

四、Routing（路由模式）

路由模式是发布订阅模式的变种，在发布订阅模式的基础上，增加了 Routing Key。

发布订阅模式是无条件的将所有消息分发给所有消费者，路由模式是 Exchange 根据 Routing Key 的规则,将数据筛选后发给对应的消费者队列。

适合场景：需要根据特定规则分发消息的场景。

比如系统打印日志，日志等级分为 error、warning、info、debug，就可以通过这种模式，把不同的日志发送到不同的队列，最终输出到不同的文件。

五、Topics（通配符模式）

路由模式的升级版，在 Routing Key 的基础上，增加了通配符的功能，使之更加灵活。

Topics 和 Routing 模式的基本原理相同，即：生产者将消息发给交换机，交换机根据 Routing Key 将消息转发给与 Routing Key 匹配的队列。

不同之处：

• Routing 模式是 精确匹配
• Topics 模式是 模糊匹配（通配符匹配）

适合场景：需要灵活匹配和过滤消息的场景。

六、RPC（RPC通信模式）

在 RPC 通信的过程中，没有生产者和消费者，比较像 RPC 远程过程调用，就是通过两个队列实现了一个可回调的过程。

该模式通常用于 "客户端发送请求给服务端执行某个任务，并等待结果返回 "。换句话说，用异步消息机制模拟 "同步调用"。

1. 客户端发送消息到一个指定的队列，并在消息属性中设置 replyTo 字段，这个字段指定了一个回调队列，用于接收服务端的响应。
2. 服务端接收到请求后，处理请求并发送响应消息到 replyTo 指定的回调队列。
3. 客户端在回调队列上等待响应消息。一旦收到响应，客户端会检查消息的 correlationId 属性，以确保它是所期望的响应。

适用场景： 在分布式系统中，我们常常有这种需求："我有一个计算密集型任务（比如生成报告、图片识别、机器学习推理），我不想在主系统中直接做，而想交给后端的工作进程去做，然后拿到结果。"

七、Publisher Confirms（发布确认机制）

Publisher Confirms 模式是 RabbitMQ 提供的一种确保消息可靠发送到 RabbitMQ 服务器的机制。在这种模式下，生产者可以等待 RabbitMQ 服务器的确认，以确保消息已经被服务器接收并处理，从而避免消息丢失的问题。

1. 生产者将 Channel 设置为 confirm 模式后（通过调用 channel.confirmSelect() 完成），发布的每一条消息都会获得一个唯一ID，生产者可以将这些序列号与消息关联起来，以便跟踪消息的状态。
2. 当消息被 RabbitMQ 服务器接收并处理后，服务器会异步地 向生产者发送一个确认 ACK 给生产者（包含消息的唯一ID），表明消息已经送达。

适用场景：对数据安全性要求较高的场景。比如金融交易、订单处理等等。

💥注意事项：

Publisher Confirms（发布确认机制）属于可靠层，与发布订阅、路由、主题等模式不冲突。

它们是 "并行概念"，一个负责消息投递的可靠性（安全性） ，另一个负责消息分发的逻辑（路由模式） 。两者是互补而不是互斥的。

所以完全可以在发布订阅（Fanout）等模式下，开启 Confirm 确认机制来确保消息可靠投递。