一、Simple（简单模式）
- P: producer 生产者，也就是要发送消息的程序
- C: consumer 消费者，消息的接收者
- Queue: 消息队列
- 图中黄色背景部分，类似一个邮箱，可以缓存消息；生产者向其中投递消息，消费者从其中取出消息。
简单模式特点：就一个生产者 P，一个消费者 C，消息只能被消费一次。也称为点对点 (Point-to-Point) 模式。
适用场景：消息只能被单个消费者处理。
二、Work Queue（工作队列模式）
在简单模式上，引入多个消费者，在多个消息情况下，工作队列会将消息分派给不同的消费者，每个消费者都会接收到不同的消息。
工作队列模式特点：消息不会重复消费，消息会分配给不同的消费者。
适用场景：集群环境中做异步处理。
三、Publish/Subscribe（发布订阅模式）
- X：交换机
在工作队列模式上，引入交换机 Exchange，而且是 fanout 类型的交换机。
3.1 交换机
交换机的作用：生产者将消息发送到 Exchange，由交换机将消息按一定规则路由到一个或多个队列中 (在 RabbitMQ 中生产者直接将消息投递到队列中，实际上不会发生，也就是简单模式和工作队列模式也会经过一层交换机，但是交换机与不存在作用类似)。
RabbitMQ 交换机有四种类型：fanout、direct、topic、headers，不同类型有着不同的路由策略。
- Fanout（扇出交换机）：广播，将消息交给所有绑定到交换机的队列 (Publish / Subscribe 模式)
- Direct（直连交换机）：定向，把消息交给符合指定 routing key 的队列 (Routing 模式)
- Topic（主题交换机）：通配符，把消息交给符合 routing pattern (路由模式) 的队列 (Topics 模式)
- headers（头交换机）：类型的交换器不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中的 headers 属性进行匹配。headers 类型的交换器性能会很差，而且也不实用，基本上不会看到它的存在。
AMQP 协议里还有另外两种类型：
- System（系统交换机）：用于将消息路由到系统服务，通常以 amq. 开头保留给协议内部使用。
- Implementation-defined（实现自定义交换机）：由具体 AMQP 实现（如 RabbitMQ）扩展定义，类型名必须以 x- 开头。
Exchange(交换机）：只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与 Exchange 绑定，或者没有符合路由规则的队列，那么消息就会丢失。
RoutingKey：路由键。生产者将消息发给交换器时，指定的一个字符串，用来告诉交换机应该如何处理这个消息。
Binding Key：绑定。RabbitMQ 中通过 Binding (绑定) 将交换器与队列关联起来，在绑定的时候一般会指定一个 Binding Key，这样 RabbitMQ 就知道如何正确地将消息路由到队列了。Binding Key 也是 RoutingKey 的一种。
3.2 发布订阅模式
Publish/Subscribe 模式：
一个生产者 P，多个消费者 C1,C2，X 代表交换机消息复制多份，每个消费者接收相同的消息，生产者发送一条消息，经过交换机转发到多个不同的队列，多个不同的队列就有多个不同的消费者。
适合场景：消息需要被多个消费者同时接收的场景。如：实时通知或者广播消息。
四、Routing（路由模式）
在发布订阅模式基础上，增加 routing key (路由 key)
发布订阅模式是无条件的将所有消息分发给所有消费者，路由模式是 Exchange 根据 RoutingKey 的规则，将数据筛选后发给对应的消费者队列。
适合场景：需要根据特定规则分发消息的场景。如系统打印日志，日志分发给不同级别的队列。
五、Topics（通配符模式）
在 routingKey 的基础上，增加了通配符的功能，使之更加灵活。
Topics 和 Routing 的基本原理相同，即：生产者将消息发给交换机，交换机根据 RoutingKey 将消息转发给与 RoutingKey 匹配的队列。类似于正则表达式的方式来定义 Routingkey 的模式。
不同之处是：routingKey 的匹配方式不同，Routing 模式是相等匹配，topics 模式是通配符匹配。
适合场景：需要灵活匹配和过滤消息的场景。
六、RPC(RPC 通信)
在 RPC 通信的过程中，没有生产者和消费者，比较像 RPC 远程调用，大概就是通过两个队列实现了一个可回调的过程。
像调用本地函数一样调用远程服务的通信范式。它屏蔽了网络、序列化、反序化、错误处理等细节，让分布式系统的开发像写单机程序一样简单。就像'打电话'，而消息队列是'发邮件'
七、Publisher Confirms(发布确认)
Publisher Confirms 模式是 RabbitMQ 提供的一种确保消息可靠发送到 RabbitMQ 服务器的机制。在这种模式下，生产者可以等待 RabbitMQ 服务器的确认，以确保消息已经被服务器接收并处理。
- 生产者将 Channel 设置为 confirm 模式 (通过调用 channel.confirmSelect() 完成) 后，发布的每一条消息都会获得一个唯一的 ID，生产者可以将这些序列号与消息关联起来，以便跟踪消息的状态。
- 当消息被 RabbitMQ 服务器接收并处理后，服务器会异步地向生产者发送一个确认 (ACK) 给生产者 (包含消息的唯一 ID)，表明消息已经送达。通过 Publisher Confirms 模式，生产者可以确保消息被 RabbitMQ 服务器成功接收，从而避免消息丢失的问题。
适用场景：对数据安全性要求较高的场景。比如金融交易，订单处理。
