大数据最新微服务—RabbitMQ高级（延迟消息）(1)，2024年最新高级程序员面试题

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

收集因TTL（有效期）到期的消息

应用：通过死信交换机完成在消费者下单一段时间（假设为5秒）后，对支付状态进行检查

由于死信交换机能够收集因TTL（有效期）到期的消息，因此我们可以创建一个消息队列ttl.queue，并且不给它指定w消费者。之后，我们设置发送消息的有效时间为5秒，我们将消息通过ttl.fanout交换机发送至ttl.queue，由于没有消费者消费这条消息，在有效期5秒到期时，该消息会成为死信，并投递到所绑定的死性交换机hmall.direct中，之后再由该交换机发送到队列direct.queue1中，最后被消息者消费。而当这条消息从发布者发出直到消费者通过死信交换机接收到时，经历了有效期5秒的等待时间，从而实现了延迟消息。

注意：

1. 尽管这里的ttl.fanout不需要RoutingKey，但是当消息变为死信并投递到死信交换机时，会沿用之前的RoutingKey，这样hmall.direct才能正确路由消息。

缺点
RabbitMQ的消息过期是基于追溯方式来实现的，也就是说当一个消息的TTL到期以后不一定会被移除或投递到死信交换机，而是在消息恰好处于队首时才会被处理。 当队列中消息堆积很多的时候，过期消息可能不会被按时处理，因此你设置的TTL时间不一定准确。

在MQ管理平台设置死信交换机方法

消息有效时间设置

---

延迟消息插件

下载安装

基于死信队列虽然可以实现延迟消息，但是太麻烦了。因此RabbitMQ社区提供了一个延迟消息插件来实现相同的效果。

插件下载地址： GitHub - rabbitmq/rabbitmq-delayed-message-exchange: Delayed Messaging for RabbitMQ 由于我们安装的MQ是3.8版本，因此这里下载3.8.17版本：

因为我们是基于Docker安装，所以需要先查看RabbitMQ的插件目录对应的数据卷。

docker volume inspect mq-plugins

结果如下：
[
    {
        “CreatedAt”: “2024-06-19T09:22:59+08:00”,
        “Driver”: “local”,
        “Labels”: null,
        “Mountpoint”: “/var/lib/docker/volumes/mq-plugins/_data”,
        “Name”: “mq-plugins”,
        “Options”: null,
        “Scope”: “local”
    }
] 
插件目录被挂载到了/var/lib/docker/volumes/mq-plugins/\_data这个目录，我们上传插件到该目录下。

接下来执行命令，安装插件：

docker exec -it mq rabbitmq-plugins enable rabbitmq_delayed_message_exchange

运行结果如下：

---

延迟交换机声明

基于注解与Bean方式声明延迟交换机：

---

发送延迟消息

发送消息时，必须通过x-delay属性设定延迟时间：

@Test
void testPublisherDelayMessage() {
    // 1.创建消息
    String message = "hello, delayed message";
    // 2.发送消息，利用消息后置处理器添加消息头
    rabbitTemplate.convertAndSend("delay.direct", "delay", message, new MessagePostProcessor() {
        @Override
        public Message postProcessMessage(Message message) throws AmqpException {
            // 添加延迟消息属性
            message.getMessageProperties().setDelay(5000);
            return message;
        }
    });
}

注意
延迟消息插件内部会维护一个本地数据库表，同时使用Elang Timers功能实现计时。如果消息的延迟时间设置较长，可能会导致堆积的延迟消息非常多，会带来较大的CPU开销，同时延迟消息的时间会存在误差。 因此，不建议设置延迟时间过长的延迟消息。

---

订单状态同步问题

接下来，我们就在交易服务中利用延迟消息实现订单支付状态的同步。其大概思路如下：

假如订单超时支付时间为30分钟，理论上说我们应该在下单时发送一条延迟消息，延迟时间为30分钟。这样就可以在接收到消息时检验订单支付状态，关闭未支付订单。 但是大多数情况下用户支付都会在1分钟内完成，我们发送的消息却要在MQ中停留30分钟，额外消耗了MQ的资源。因此，我们最好多检测几次订单支付状态，而不是在最后第30分钟才检测。 例如：我们在用户下单后的第10秒、20秒、30秒、45秒、60秒、1分30秒、2分、…30分分别设置延迟消息，如果提前发现订单已经支付，则后续的检测取消即可。 这样就可以有效避免对MQ资源的浪费了。

优化后的实现思路如下：

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

，涵盖了95%以上大数据知识点，真正体系化！**

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取