文章目录
- [1. Simple（简单模式）](#1. Simple（简单模式）)
- [2. Work Queue（工作队列）](#2. Work Queue（工作队列）)
- [3. Publish / Subscribe（发布 / 订阅）](#3. Publish / Subscribe（发布 / 订阅）)
-
- [3.1 Exchange 概念介绍](#3.1 Exchange 概念介绍)
- [3.2 RoutingKey与BindingKey示例](#3.2 RoutingKey与BindingKey示例)
- [3.3 Publish / Subscribe 模式](#3.3 Publish / Subscribe 模式)
- [4. 路由模式](#4. 路由模式)
- [5. Topics模式](#5. Topics模式)
- [6. RPC模式](#6. RPC模式)
- [7. Publisher Confirms（发布确认）](#7. Publisher Confirms（发布确认）)
RabbitMQ 共提供了 7 种工作模式，进行消息传递，我们入门程序的案例，其实就是一个简单模式。
官方文档 RabbitMQ Tutorials | RabbitMQ
如下所示：
1. Simple（简单模式）
- P：生产者，也就是要发送消息的程序
- C：消费者，消息的接收者
- Queue：消息队列，图中黄色背景部分。类似一个邮箱，可以缓存消息；生产者向其中投递消息，消费者从其中取出消息。
特点：一个生产者 P，一个消费者 C，消息只能被消费一次。也称为点对点（Point-to-Point）模式。
适用场景：消息只能被单个消费者处理。
2. Work Queue（工作队列）
- P：生产者
- C1 / C2：消费者
- Queue：消息队列
一个生产者P，多个消费者C1 / C2。在多个消息的情况下，Work Queue 会将消息分派给不同的消费者，每个消费者都会接收到不同的消息。
特点：消息不会重复，分配给不同的消费者。
适用场景：集群环境中做异步处理
示例：比如 12306 短信通知服务，订票成功后，订单消息会发送到 RabbitMQ，短信服务从 RabbitMQ 中获取订单信息，并发送通知信息（在短信服务之间进行任务分配）
3. Publish / Subscribe（发布 / 订阅）
图中 X 表示交换机，在订阅模型中，多了一个 Exchange 角色，过程略有变化。
3.1 Exchange 概念介绍
Exchange（交换机，X）：生产者将消息发送到 Exchange，由交换机将消息按一定规则路由到一个或多个队列中（在 RabbitMQ 中生产者不会直接投递消息到队列）。
RabbitMQ交换机有四种类型：fanout、direct、topic、headers，不同类型有不同的路由策略。AMQP协议还有另外两种类型（System 和 自定义），此处不再描述。
- Fanout：广播，将消息交给所有绑定到交换机的队列（Publish / Subscribe模式）
- Direct：定向，把消息交给符合指定 routing key 的队列（Routing 模式）
- Topic：通配符，把消息交给符合 routing pattern（路由模式）的队列（Topics 模式）
- headers：不依赖路由键匹配规则，根据消息内容中的 headers 属性进行匹配，性能差且不实用，基本不会使用。
Exchange 只负责转发消息，不具备存储消息的能力，若没有队列与 Exchange 绑定或没有符合路由规则的队列，消息会丢失。
- RoutingKey（路由键）：生产者将消息发给交换器时指定的字符串，用于告知交换机如何处理该消息。
- Binding Key（绑定）：RabbitMQ 中通过 Binding 将交换器与队列关联，绑定时会指定 Binding Key，用于路由消息到队列。
如下所示：
3.2 RoutingKey与BindingKey示例
如下图所示：如果在发送消息时，设置 RoutingKey 为 orange，消息会路由到Q1。
当消息的 Routing key 与队列绑定的Binding key相匹配时，消息才会被路由到该队列。
BindingKey属于路由键的一种，官方解释为：the routingkey to use for the binding。
可理解为：
- 绑定时需要的路由键是 BindingKey
- 发送消息时需要的路由键是RoutingKey
后续可能将两者合称为 Routing Key，根据使用场景区分。
3.3 Publish / Subscribe 模式
一个生产者 P，多个消费者 C1、C2，X 代表交换机，消息复制多份，每个消费者接收相同的消息。
生产者发送一条消息，经交换机转发到多个不同队列，每个队列对应不同消费者。
适合场景： 消息需要被多个消费者同时接收的场景，如实时通知或广播消息。
示例：气象局发布 "天气预报" 的消息送入交换机，x浪、x度、x狐、x易等门户网站通过队列绑定到该交换机，自动获取气象局推送的气象数据。
4. 路由模式
路由模式是发布订阅模式的变种，在发布订阅基础上，增加路由 key。
发布订阅模式是无条件的将所有消息分发给所有消费者，路由模式是 Exchange 根据 RoutingKey 的规则，将数据筛选后发给对应的消费者队列。
适合场景：需要根据特定规则分发消息的场景。
示例：比如系统打印日志，日志等级分为 error、warning、info、debug 等等，那么就可以通过这种模式，把不同的日志发送到不同的队列，最终输出到不同的文件。
5. Topics模式
路由模式的升级版，在 routingKey 的基础上，增加了通配符的功能，使之更加灵活。
Topics 和 Routing 的基本原理相同，即：生产者将消息发给交换机，交换机根据 RoutingKey 将消息转发给与 RoutingKey 匹配的队列。类似于正则表达式的方式来定义 Routingkey 的模式。
不同之处是：routingKey 的匹配方式不同，Routing 模式是相等匹配，Topics 模式是通配符匹配。
适合场景：需要灵活匹配和过滤消息的场景。
6. RPC模式
在 RPC 通信的过程中，没有生产者和消费者，比较像咱们 RPC 远程调用，大概就是通过两个队列实现了一个可回调的过程。
大致流程就是：
- 1、客户端发送消息到一个指定的队列，并在消息属性中设置 replyTo 字段，这个字段指定了一个回调队列，用于接收服务端的响应。
- 2、服务端接收到请求后，处理请求并发送响应消息到 replyTo指定的回调队列。
- 3、客户端在回调队列上等待响应消息。一旦收到响应，客户端会检查消息的 correlationId 属性，以确保它是所期望的响应。
如下所示：
7. Publisher Confirms（发布确认）
Publisher Confirms 模式是 RabbitMQ 提供的一种确保消息可靠发送到 RabbitMQ 服务器的机制。在这种模式下，生产者可以等待 RabbitMQ 服务器的确认，以确保消息已经被服务器接收并处理。
- 生产者将 Channel 设置为 confirm 模式后（通过调用
channel.confirmSelect()完成），发布的每一条消息都会获得一个唯一的 ID，生产者可以将这些序列号与消息关联起来，以便跟踪消息的状态。 - 当消息被 RabbitMQ 服务器接收并处理后，服务器会异步地向生产者发送一个确认（ACK）给生产者（包含消息的唯一 ID），表明消息已经送达。
通过 Publisher Confirms 模式，生产者可以确保消息被 RabbitMQ 服务器成功接收，从而避免消息丢失的问题。
适用场景：对数据安全性要求较高的场景，比如金融交易，订单处理。