RabbitMQ七种工作模式

1.Simple（简单模式）

P是生产者，C是消费者，Queue是消息队列。

生产者将消息放到Queue中，消费者来消费

特点：只有一个生产者和一个消费者，一个信息只能被消费一次。

适应场景：消息只能被单个消费者处理。

2 Work Queue（工作队列）

 P仍然代表生产者，C1和C2都是消费者

这种模式只有一个生产者，消费者可以有多个。当产生多条消息的时候，Work Queue会将消息分配给不同的 消费者，每个消费者收到的消息都不同。

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

适用场景：集群环境中做异步处理。

 2.Publish/Subscribe(发布/订阅)

这个比上面两种模式多了一个x，x就是交换机，也就是Exchange。

交换机起到路由作用。生产者生产的信息发送到交换机，交换机通过一定规则路由到一个或者多个消息队列中。

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

RoutingKey: 路由键.生产者将消息发给交换器时, 指定的一个字符串, 用来告诉交换机应该如何处理这个消息. 
Binding Key:绑定. RabbitMQ中通过Binding(绑定)将交换器与队列关联起来, 在绑定的时候一般会指定一个Binding Key, 这样RabbitMQ就知道如何正确地将消息路由到队列了.

 

 

这两个图就很好解释了 RoutingKey，BindingKey的作用.
当消息的Routing key与队列绑定的Bindingkey相匹配时，消息才会被路由到这个队列.

上面这种模式，生产者生产一个消息，发给交换机，交换机复制多分，发给消息队列，每个消息队列消息相同。

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

4.Routing（路由模式）

Routing 模式是发布订阅模式的变种，加了key，作用就是过滤，就是根据Routing Key来进行筛选，将筛选后的消息发给对应的消息队列。

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

看下图

 

5.Topics(通配符模式) 

路由模式的升级版, 在routingKey的基础上,增加了通配符的功能, 使之更加灵活.

Topics和Routing的基本原理相同，即：生产者将消息发给交换机，交换机根据RoutingKey将消息转发给与RoutingKey匹配的队列. 类似于正则表达式的方式来定义Routingkey的模式.

不同之处是：routingKey的匹配方式不同，Routing模式是相等匹配，topics模式是通配符匹配.
适合场景: 需要灵活匹配和过滤消息的场景

6.RPC(RPC通信) 

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

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

7.Publisher Confirms(发布确认)

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

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

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

适用场景: 对数据安全性要求较高的场景. 比如金融交易, 订单处理.

过程就和下图差不多

上面这7中模式并非哪种就是最优的，要根据业务场景进行选择，举个例子如果要求安全性高，就可以使用Publisher Confirms（发布确认）。