RabbitMQ 共提供了7种⼯作模式, 进⾏消息传递

一、七种模式的概述

1、Simple(简单模式)

P：生产者，就是发送消息的程序

C：消费者，就是接收消息的程序

Queue：消息队列，类似⼀个邮箱, 可以缓存消息; ⽣产者向其中投递消息, 消费者从其中取出消息

特点: ⼀个⽣产者P，⼀个消费者C, 消息只能被消费⼀次. 也称为点对点(Point-to-Point)模式

2、Work Queue(⼯作队列)

一个生产者P，多个消费者C1、C2，在多个消息的情况下，WorkQueue会将消息分派给不同的消费者, 每个消费者都会接收到不同的消息

特点：消息不会重复，会分配给不同的消费者

适⽤场景: 集群环境中做异步处理（⽐如12306 短信通知服务, 订票成功后, 订单消息会发送到RabbitMQ, 短信服务从RabbitMQ中获取订单信息, 并发送通知信息(在短信服务之间进⾏任务分配)）

3、Publish/Subscribe(发布/订阅)

注：

Exchange: 交换机 (X).
作⽤: ⽣产者将消息发送到Exchange, 由交换机将消息按⼀定规则路由到⼀个或多个队列中(上图中⽣产者将消息投递到队列中, 实际上这个在RabbitMQ中不会发⽣. )
RabbitMQ交换机有四种类型: fanout,direct, topic, headers, 不同类型有着不同的路由策略. AMQP协议⾥还有另外两种类型, System和⾃定义, 此处不再描述.
1. Fanout:⼴播，将消息交给所有绑定到交换机的队列(Publish/Subscribe模式)
2. Direct:定向，把消息交给符合指定routing key的队列(Routing模式)
3. Topic:通配符，把消息交给符合routing pattern(路由模式)的队列(Topics模式)
4. headers类型的交换器不依赖于路由键的匹配规则来路由消息, ⽽是根据发送的消息内容中的headers属性进⾏匹配. headers类型的交换器性能会很差,⽽且也不实⽤,基本上不会看到它的存在.
Exchange(交换机）只负责转发消息, 不具备存储消息的能⼒, 因此如果没有任何队列与Exchange绑定，或者没有符合路由规则的队列，那么消息就会丢失。

RoutingKey: 路由键.⽣产者将消息发给交换器时, 指定的⼀个字符串, ⽤来告诉交换机应该如何处理这个消息.

Binding Key:绑定. RabbitMQ中通过Binding(绑定)将交换器与队列关联起来, 在绑定的时候⼀般会指定⼀个Binding Key, 这样RabbitMQ就知道如何正确地将消息路由到队列了.

如下图所示：如果routingKey为orange就路由到Q1

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

⼀个⽣产者P, 多个消费者C1, C2, X代表交换机消息复制多份，每个消费者接收相同的消息⽣产者发送⼀条消息，经过交换机转发到多个不同的队列，多个不同的队列就有多个不同的消费者
适合场景: 消息需要被多个消费者同时接收的场景. 如: 实时通知或者⼴播消息（⽐如中国⽓象局发布"天⽓预报"的消息送⼊交换机, 新浪,百度, 搜狐, ⽹易等⻔⼾⽹站接⼊消息, 通过队列绑定到该交换机, ⾃动获取⽓象局推送的⽓象数据）

4、Routing(路由模式)

路由模式是发布订阅模式的变种, 在发布订阅基础上, 增加路由key发布订阅模式是⽆条件的将所有消息分发给所有消费者, 路由模式是Exchange根据RoutingKey的规则,将数据筛选后发给对应的消费者队列

适合场景: 需要根据特定规则分发消息的场景.（⽐如系统打印⽇志, ⽇志等级分为error, warning, info,debug, 就可以通过这种模式,把不同的⽇志发送到不同的队列, 最终输出到不同的⽂件）

5、Topics(通配符模式)

路由模式的升级版, 在routingKey的基础上,增加了通配符的功能, 使之更加灵活.Topics和Routing的基本原理相同，即：⽣产者将消息发给交换机，交换机根据RoutingKey将消息转发给与RoutingKey匹配的队列. 类似于正则表达式的⽅式来定义Routingkey的模式.
不同之处是：routingKey的匹配⽅式不同，Routing模式是相等匹配，topics模式是通配符匹配

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

6、RPC（RPC通信）

RPC客户端发送消息到RPC_REQUEST队列中，同时在replyTo属性中设置接收消息的队列RPC_RESPONSE；

RPC服务器收到消息，在RPC_REQUEST队列中对消息进行处理，发送到RPC_RESPONSE响应队列中

过程：

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

7、publish confirm（发布确认）

注：他可以确保消息可以正确发送到RabbitMq的机制

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

通过Publisher Confirms模式，⽣产者可以确保消息被RabbitMQ服务器成功接收, 从⽽避免消息丢失的问题