RabbitMQ（二）——七种消息收发机制（直连、扇形、主题、Hearder交换机）、RPC调用、消息有效期和死信队列（单条消息过期、特殊情况、死信队列、死信队列典型应用）

RabbitMQ（二）——七种消息收发机制（直连、扇形、主题、Hearder交换机）、RPC调用、消息有效期和死信队列（单条消息过期、特殊情况、死信队列、死信队列典型应用） 一、七种消息收发机制

以上的例子，消息都是推过来我们接收的。用推的方式消费的节奏不能自己控制，是 rabbitMQ 控制的。如果是拉的话，可以自己控制消费的节奏。

1、并发消费+直连交换机 a、并发消费

上图中，如果并发数是 10 个，相当于 10 个消费者了；如果去图形化界面查看，可以发现此时有 11 个消费者。

生产者：

现在 11 个消费者消费 10 个消息，是有一定可能 handleMsg2 一个都消费不到。

b、直连交换机

DirectRabbitConfig：

DirectConsumer：

生产者（生产者这里也要有 DirectRabbitConfig。下同）：

2、扇形交换机

FanoutRabbitConfig：


FanoutConsumer：

生产者：

3、主题交换机

TopicRabbitConfig：


TopicConsumer：

生产者：

效果：

4、Header 交换机

HeaderRabbitConfig：

HeaderConsumer：

生产者：

二、RPC调用

RPC 也称为跨进程调用。也可以理解为一个应用程序调用另外一个应用程序。

1、引言和介绍

2、架构图

3、前期准备

跟前面一样，创建生产者和消费者。

消费者：

生产者：

4、代码实现 a、消费者

RabbitConfig：


HelloController（应该是写在 service 层的，这里直接写在了 controller 层）：

b、生产者

RabbitConfig ：

HelloController：

三、消息有效期和死信队列 1、默认情况

2、TTL（Time-To-Live）

TTL（Time-To-Live），消息存活的时间，即消息的有效期。如果我们希望消息能够有一个存活时间，那么我们可以通过设置 TTL 来实现这一需求。如果消息的存活时间超过了 TTL 并且还没有被消息，此时消息就会变成 死信 ，关于 死信 以及 死信队列 ，后面再介绍。

TTL 的设置有两种不同的方式：

在声明队列的时候，我们可以在队列属性中设置消息的有效期，这样所有进入该队列的消息都会有一个相同的有效期。在发送消息的时候设置消息的有效期，这样不同的消息就具有不同的有效期。那如果两个都设置了呢？

以时间短的为准。

3、单条消息过期 a、前期准备

单个消息的过期时间：在发消息的时候给消息设置一个过期时间，如果时间到了，这个消息还没有被消费，那么这个消息会自动消失；这个消息没有被删除，而是进到了死信队列里面去。

b、config 配置文件

这段配置应该很简单，没啥好解释的，有一个排他性，这里稍微多说两句：

c、接口

到这里，就可以测试了，打开可视化界面，可以看到过一会消息就消失了。

4、特殊情况

5、死信队列

被删除的消息去哪了？真的被删除了吗？并不是！这就涉及到死信队列了，接下来看看死信队列。

a、死信交换机

b、代码实现

配置文件 config：

接口跟上面的一样。

死信队列消费者：

6、死信队列典型应用

这个死信队列可以做一个非常典型的事情，就是延迟消息队列。

虽然 rabbitMQ 没有延迟消息功能，但是能用死信队列实现。

比如定义了死信队列的消费者，10秒钟后消息没有被消费，进入到死信队列中，才被消费掉，那么这不正是一种延迟消息队列吗？

比如典型的应用就是电商网站，下单后 30 分钟内必须付款，不然就会取消订单。虽然可以用定时任务去监控，但是不好维护，出错了不好处理。如果用这种方式，不仅维护方便，也很稳定，出错了还能自动重试。