Rabbitmq的六大工作模式机制

关于Rabbitmq六大消费模式的官方文档： https://www.rabbitmq.com/getstarted.html

简单模式(点对点模式)：

应用场景：发送验证码，

一个生产者，一个消费者。生产者将消息放入队列，消费者监听消息队列,如果队列中有消息,就消费掉,消息被拿走后,自动从队列中删除(隐患 消息可能没有被消费者正确处理就已经从队列中消失了,造成消息的丢失)

work模式(竞争模式)：

应用场景： 抢包红；大项目中的资源调度；秒杀系统的订单处理服务等

一个生产者，多个消费者，每个消费者获取到的消息唯一。消息产生者将消息放入队列后多个消费者同时监听同一个队列,消息被消费。多个消费者同时抢夺当前消息队列里的内容,谁先拿到就可以消费消息(隐患,高并发情况下,默认会产生某一个消息被多个消费者共同使用,可以设置一个开关(syncronize,与同步锁的性能不一样) 保证一条消息只能被一个消费者使用。具体可参考本人另一篇文章消息队列如何保证消息不被重复消费（如何保证消费时的幂等性）)。如下图

 

Publish/Subscribe发布/订阅模式(共享资源)：

应用场景： 短信群发；发送广播，公告消息等

一个生产者发送的消息会被多个消费者获取。

 

Routing路由模式：

发送消息到交换机并且要指定路由key ，消费者将队列绑定到交换机时需要指定路由key

 

Topic主题模式(路由模式的一种):

将路由键和某模式进行匹配，此时队列需要绑定在一个模式上。“*”和“#”代表通配符，“#”匹配一个词或多个词，“*”只匹配一个词。

消息产生者产生消息,把消息交给交换机，交换机根据key的规则模糊匹配到对应的队列,由队列的监听消费者接收消息进行消费

 

RPC模式:

RPC 模式就是通过消息队列（Message Queue）来实现rpc的功能。就是客户端向服务端发送定义好的Queue消息，其中携带的消息就应该是服务端将要调用的方法的参数 ，并使用Propertis告诉服务端将结果返回到指定的Queue。

RPC 模式的使用场景：一般是 希望同步得到结果的场合 或者是不希望客户端受限于服务端的速度等。

与普通的RPC调用相比较：普通RPC进行同步调用，对于要等待返回结果/处理结果的场景，RPC是可以非常自然直觉的使用方式，但由于调用方需等待结果，客户端会有线程消耗。当然RPC也可以是异步调用，如果以异步RPC的方式使用，客户端线程消耗的问题可以解决，但不能做到像消息队列一样暂存消息请求，压力会直接传导到服务端甚至直接击垮服务器。

RPC 模式的实现流程如下图：

图解基本概念：

Callback queue 回调队列，客户端向服务器发送请求，服务器端处理请求后将其处理结果保存在一个存储体(回调队列)中。而客户端为了获得处理结果，那么客户在向服务器发送请求时，同时发送一个回调队列地址reply_to。服务器便将处理完的请求结果丢进这个回调队列中。

Correlation id 关联标识，客户端可能会发送多个请求给服务器，当服务器处理完后，客户端无法辨别在回调队列中的响应具体和那个请求时对应的。为了处理这种情况，客户端在发送每个请求时，同时会附带一个独有correlation_id属性（我们可以把它理解为一个请求ID），这样客户端在回调队列中根据correlation_id字段的值就可以分辨此响应属于哪个请求。

图解流程说明：

1、当客户端启动的时候，作为生产者的客户端将创建一个匿名独享的回调队列。

2、在 RPC 请求中，客户端（生产者）将带有两个属性的消息(一个是设置回调队列的 reply_to 属性，另一个是设置唯一值的 correlation_id 属性)发送到一个RPC_QUEUE队列中。

3、服务器(此时服务器端是消费者)监听这个RPC_QUEUE队列。当这个队列中有请求（消息）出现的时候，服务器将接收并处理完这个请求（消息），并且将处理结果扔进 reply_to 字段指定的队列。

4、客户端（这时候客户端就是消费者了）监听回调队列里的数据。当有消息出现的时候，它会检查 correlation_id 属性。如果此属性的值与请求匹配，则作为一次正常的服务器响应去处理了

关于RPC模式可参考文章RabbitMQ学习系列（五）: RPC 远程过程调用