当前位置:   article > 正文

RabbitMQ--基础--10.3--延迟队列_rabbitmq消费失败重入队列延迟多少s

rabbitmq消费失败重入队列延迟多少s

RabbitMQ–基础–10.3–延迟队列


1、延迟队列

  1. 消息发送到队列之后,并不期望消费者能马上消费,也是延迟一段时间之后,才拿到该消息进行消费。
  2. 延迟队列我们是使用 死信队列 和 TTL 来模拟 延迟队列的

1.1、特点

  1. 需要在某个事件发生之后或者之前的指定时间点完成某一项任务
  2. 举例:发生订单生成事件,在十分钟之后检查该订单支付状态,然后将未支付的订单进行关闭。

2、使用场景

  1. 订单在十分钟之内未支付则自动取消
  2. 新创建的店铺,如果在十天内都没有上传过商品,则自动发送消息提醒
  3. 用户注册成功后,如果三天内没有登录则进行短信提醒
  4. 用户发起退款,如果三天内没有得到处理则通知相关运营人员
  5. 预定会议后,需要在预定的时间点前十分钟通知各个与会人员参加会议

2.1、订单在十分钟之内未支付则自动取消

  1. 下单了一个外卖,需要在10分钟以内完成支付,若未按时完成,则属于异常处理,需要延迟队列来处理这些消息
  2. 本例子中,用户下单,将消息丢入队列中,TTL 为10分钟,若10还未完成支付,则消息会被丢入对应的死信队列中进行处理

2.2、为什么不使用定时任务 来处理上面的场景

上面的案例,使用定时任务,一直轮询数据,每秒查一次,取出需要被处理的数据,然后处理数据,这个方案可以吗?

  1. 如果数据量比较少,确实可以这样做

    1. 比如:对于"如果账单一周内未支付则自动进行结算"这样的需求,如果对于时间不是严格限制,而是宽松意义上的一周,那么每天晚上跑个定时任务检查一下所有未支付的账单,确实是一个可行的方案。
  2. 但是对于数据量比较大,并且时效性较强的场景,不可以使用定时任务

    1. 比如:“订单十分钟内未支付则关闭”,短期内未支付的订单数据可能会有很多,活动期间甚至会达到百万甚至千万级别,对这么庞大的数据量仍旧使用轮询的方式显然是不可取的,很可能在一秒内无法完成所有订单的检查,同时会给数据库带来很大压力,无法满足业务要求而且性能低下。

3、实现方式

  1. 基于死信队列实现延时队列
  2. 基于死信队列实现延时队列

3.1、基于死信队列实现延时队列

3.1.1、代码架构图

  1. 创建两个队列QA和QB,两个队列TTL分别设置为10s和40
  2. 创建一个交换机X和死信交换机Y,他们的类型是direct
  3. 创建一个死信队列QD

在这里插入图片描述

3.1.2、代码

@Component
public class MessageConsumer {

    @RabbitListener(queues = "QD")
    public void receiveD(Message message, Channel channel){
        String msg = new String(message.getBody());
        System.out.println(msg);
    }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

@Component
public class MessageProducer {
    
    @Autowired
    private RabbitTemplate rabbitTemplate;
    
    /**
     * 发送消息
     * 
     * @param message 消息
     * @param ttlTime ttl时间
     */
    public void send(String message, String ttlTime) {
        rabbitTemplate.convertAndSend(TtlQueueConfig.X_EXCHANGE, "XC", message, msg -> {
            msg.getMessageProperties().setExpiration(ttlTime);
            return msg;
        });
    }
    
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21

/**
 * 延时队列 配置类
 */
@Component
@Configuration
public class TtlQueueConfig {
    
    // 普通交换机
    public static final String X_EXCHANGE = "X";
    
    // 死信交换机
    public static final String Y_DEAD_EXCHANGE = "Y";
    
    // 普通队列
    public static final String QUEUE_C = "QC";
    
    // 死信队列
    public static final String DEAD_QUEUE_D = "QD";
    
    // 声明X交换机
    @Bean("xExchange")
    public DirectExchange xExchange() {
        return new DirectExchange(X_EXCHANGE);
    }
    
    // 声明Y交换机
    @Bean("yExchange")
    public DirectExchange yExchange() {
        return new DirectExchange(Y_DEAD_EXCHANGE);
    }
    
    // 声明普通队列
    @Bean("queueC")
    public Queue queueC() {
        return QueueBuilder.durable(QUEUE_C).deadLetterExchange(Y_DEAD_EXCHANGE).deadLetterRoutingKey("YD").build();
    }
    
    // 声明死信队列
    @Bean("queueD")
    public Queue queueD() {
        return QueueBuilder.durable(DEAD_QUEUE_D).build();
    }
    
    // 队列与交换机进行绑定
    @Bean
    public Binding queueCBindingX(@Qualifier("queueC") Queue queueC, @Qualifier("xExchange") DirectExchange xExchange) {
        return BindingBuilder.bind(queueC).to(xExchange).with("XC");
    }
    
    @Bean
    public Binding queueDBindingY(@Qualifier("queueD") Queue queueD, @Qualifier("yExchange") DirectExchange yExchange) {
        return BindingBuilder.bind(queueD).to(yExchange).with("YD");
    }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/码创造者/article/detail/1018974
推荐阅读
相关标签
  

闽ICP备14008679号