• RabbitMQ的死信队列和延迟队列


    RabbitMQ的死信队列和延迟队列

    一、死信队列是什么?

    1、要想知道死信队列是什么,先要了解什么是死信

    1)“死信”是RabbitMQ中的一种消息机制。

    2)消息变成死信,可能是由于以下的原因:

    • 消息被拒绝
    • 消息过期
    • 队列达到最大长度

    3)死信队列

         当消息在一个队列中变成死信(dead message)之后,它能被重新发送到另一个交换机中,这个交换机就是 DLX(Dead-Letter-Exchange ) ,绑定 DLX 的队列就称之为死信队列。

      “死信”消息会被RabbitMQ进行特殊处理,如果配置了死信队列信息,那么该消息将会被丢进死信队列中,如果没有配置,则该消息将会被丢弃。

    二、如何配置死信队列?

         1.  配置业务队列,绑定到业务交换机上

         2.  为业务队列配置死信交换机路由key

         3.  为死信交换机配置死信队列

         注意:并不是直接声明一个公共的死信队列,然后所以死信消息就自己跑到死信队列里去了。而是为每个需要使用死信的业务队列配置一个死信交换机,这里同一个项目的死信交换机可以共用一个,然后为每个业务队列分配一个单独的路由key。

         有了死信交换机和路由key后,接下来,就像配置业务队列一样,配置死信队列,然后绑定在死信交换机上。也就是说,死信队列并不是什么特殊的队列,只不过是绑定在死信交换机上的队列。死信交换机也不是什么特殊的交换机,只不过是用来接受死信的交换机,所以可以为任何类型【Direct、Fanout、Topic】。一般来说,会为每个业务队列分配一个独有的路由key,并对应的配置一个死信队列进行监听,也就是说,一般会为每个重要的业务队列配置一个死信队列。

         具体因为队列消息过期而被投递到死信队列的流程:

     

        总结:

        死信队列其实并没有什么神秘的地方,不过是绑定在死信交换机上的普通队列,而死信交换机也只是一个普通的交换机,不过是用来专门处理死信的交换机。

        死信消息的生命周期:

        1)业务消息被投入业务队列

        2)消费者消费业务队列的消息,由于处理过程中发生异常,于是进行了nck或者reject操作

        3)被nck或reject的消息由RabbitMQ投递到死信交换机中

        4)死信交换机将消息投入相应的死信队列

        5)死信队列的消费者消费死信消息

        死信消息是RabbitMQ为我们做的一层保证,其实我们也可以不使用死信队列,而是在消息消费异常时,将消息主动投递到另一个交换机中,当你明白了这些之后,这些Exchange和Queue想怎样配合就能怎么配合。比如从死信队列拉取消息,然后发送邮件、短信、钉钉通知来通知开发人员关注。或者将消息重新投递到一个队列然后设置过期时间,来进行延时消费。

    三、死信队列的应用场景

         一般用在较为重要的业务队列中,确保未被正确消费的消息不被丢弃,一般发生消费异常可能原因主要有由于消息信息本身存在错误导致处理异常,处理过程中参数校验异常,或者因网络波动导致的查询异常等等,当发生异常时,当然不能每次通过日志来获取原消息,然后让运维帮忙重新投递消息。

        通过配置死信队列,可以让未正确处理的消息暂存到另一个队列中,待后续排查清楚问题后,编写相应的处理代码来处理死信消息,这样比手工恢复数据要好太多了。

    四、延迟队列

          延迟队列存储的对象是对应的延迟消息;所谓“延迟消息” 是指当消息被发送以后,并不想让消费者立刻拿到消息,而是等待特定时间后,消费者才能拿到这个消息进行消费。

          在RabbitMQ中延迟队列可以通过 过期时间 + 死信队列 来实现;具体如下流程图所示:

        

     

    五、扩展一下

    订单30分钟未支付,系统自动超时关闭有哪些实现方案?

    1、基于任务调度实现(定时任务)

         缺点:效率非常低,消耗服务器性能

    2、基于redis过期key实现(键通知机制)

        1)用户下单的时候,生成一个令牌(有效期)30分钟,存放到我们redis;

        2)redis.set(orderToken ,orderID) 下单时候存放到redis,并存储id入库,30分钟过期,

        3)redis客户端监听,过期获取到orderId,拿orderId去查订单,没有支付则,订单关闭,库存增加

        缺点: 1) 非常冗余 ,会在表中存放一个冗余字段 2) 键通知机制是一种并不可靠的消息机制,如果系统需要需要很好的可靠性,那么它并不是一种很好的选择。

        具体细节可以参考我之前写过的一篇文章:《Redis键通知机制》

    3、基于redis延迟队列

       优点:可以满足吞吐量

       缺点:存在任务丢失的风险(当 Redis 实例挂了的时候)。因此,如果对性能要求比较高,同时又能容忍少数情况下任务的丢失,那么可以使用这种方式来实现。

    4、基于MQ的延迟队列实现( 最佳 )

        比如上面提到的RabbitMQ的延迟队列,使用过期时间+死信队列来实现

        实现原理:

        1)下单投放消息到 A交换机(过期时间30分钟),将 aa队列绑定到该死信交换机A, 不设置aa队列的消费者(故此消息一直未消费).

        2)30分钟后,过期,消息投递到死信交换机,死信队列的消费者消费死信消息, 判断订单id是否支付,执行业务逻辑,支付->return 。未支付->关闭订单,返还库存。

     

    参考链接:

    https://www.cnblogs.com/dalianpai/p/13602770.html

    https://www.cnblogs.com/mfrank/p/11184929.html 

  • 相关阅读:
    SQL CAST与CONVERT区别
    SQL存储过程相关信息查看
    SQLServer系统变量使用
    转 C#中哈希表(HashTable)的用法详解
    SQL中的全局变量和局部变量(@@/@)
    SqlServer中用SQL语句附加数据库及修改数据库逻辑文件名
    SQL Server中常用全局变量介绍
    SQL Server 用户定义表类型
    03- 手机App功能测试要点以及登录页面的测试
    1. APP移动端性能测试基础知识入门
  • 原文地址:https://www.cnblogs.com/hld123/p/14716684.html
Copyright © 2020-2023  润新知