1.简单模式

生产者把消息放入队列，消费者获得消息，如下图所示。这个模式只有 一个消费者、一个生产者、一个队列，只需要配置主机参数，其他参数使用默认值即可通信。

2.工作队列模式

这种模式出现了多个消费者，如下图所示。为了保证消费者之间的负载均衡和同步，需要在消息队列之间加上同步功能。

工作队列（任务队列）背后的主要思想是：避免立即执行资源密集型任务（耗时），以便下一个任务执行时不用等待它完成。工作队列将任务封装为消息并将其发送到队列中。

3.交换机模式

实际上，前两种模式也使用了交换机，只是使用了采用默认设置的交换机。交换机参数是可以配置的，如果消息配置的交换机参数和 RabbitMQ 队列绑定（binding）的交换机名称相同，则转发，否则丢弃，如下图所示。

4.Routing 转发模式

交换机要配置为 direct 类型，转发的规则变为检查队列的 routing key 值。如果 routing key 值相同，则转发，否则丢弃，如下图所示。

5.主题转发模式

这种模式下交换机要配置为 topic 类型，routing key 配置失效。发送到主题交换机的信息不能是任意 routing key，它必须是一个单词的列表，用逗号分隔。特点是可以模糊匹配，匹配规则为：* 可以代替一个词；# 可以代替 0 个或更多的单词，其模式情况如下图所示。

6.RPC 模式

6.1 消息属性

AMQP 协议给消息预定义了一系列的 14 个属性。大多数属性很少会用到，除了以下几个：

• delivery_mode（投递模式）：将消息标记为持久的（值为 $2$）或暂存的（除了 $2$ 之外的其他任何值）。
• content_type（内容类型）：用来描述编码的 mime-type。例如在实际使用中常常使用 application/json 来描述 JOSN 编码类型。
• reply_to（回复目标）：通常用来命名回调队列。
• correlation_id（关联标识）：用来将 RPC 的响应和请求关联起来。

6.2 关联标识

如果给每一个 RPC 请求新建一个回调队列。这不是一个高效的做法，幸好这儿有一个更好的办法 —— 我们可以 为每个客户端只建立一个独立的回调队列。

这就带来一个新问题，当此队列接收到一个响应的时候它无法辨别出这个响应是属于哪个请求的。correlation_id 就是为了解决这个问题而来的。我们给每个请求设置一个独一无二的值。稍后，当我们从回调队列中接收到一个消息的时候，我们就可以查看这条属性从而将响应和请求匹配起来。如果我们接手到的消息的 correlation_id 是未知的，那就直接销毁掉它，因为它不属于我们的任何一条请求。

你也许会问，为什么我们接收到未知消息的时候不抛出一个错误，而是要将它忽略掉？这是为了解决服务器端有可能发生的竞争情况。尽管可能性不大，但 RPC 服务器还是有可能在已将应答发送给我们但还未将确认消息发送给请求的情况下杀掉。如果这种情况发生，RPC 在重启后会重新处理请求。这就是为什么我们必须在客户端优雅的处理重复响应，同时 RPC 也需要尽可能保持幂等性。

6.3 工作流程

这种模式主要使用在远程调用的场景下。如果一个应用程序需要另外一个应用程序来最终返回运行结果，那这个过程可能是比较耗时的操作，使用 RPC 模式是最合适的。其模式情况如下图所示。

• 当客户端启动的时候，它创建一个匿名独享的回调队列。
• 在 RPC 请求中，客户端发送带有两个属性的消息：一个是设置回调队列的 reply_to 属性，另一个是设置唯一值的 correlation_id 属性。
• 将请求发送到一个 rpc_queue 队列中。
• RPC 工作者（又名：服务器）等待请求发送到这个队列中来。当请求出现的时候，它执行他的工作并且将带有执行结果的消息发送给 reply_to 字段指定的队列。
• 客户端等待回调队列里的数据。当有消息出现的时候，它会检查 correlation_id 属性。如果此属性的值与请求匹配，将它返回给应用。

7.小结

6 种工作模式的主要特点如下

• 简单模式：只有一个生产者，一个消费者。
• 工作队列模式：一个生产者，多个消费者，每个消费者获取到的消息唯一。
• 订阅模式：一个生产者发送的消息会被多个消费者获取。
• 路由模式：发送消息到交换机，并且要指定路由 key，消费者在将队列绑定到交换机时需要指定路由 key。
• Topic 模式：根据主题进行匹配，此时队列需要绑定在一个模式上，# 匹配一个词或多个词，* 只匹配一个词。