mq监听死信队列后是如何处理-成都快上网建站

mq监听死信队列后是如何处理

今天就跟大家聊聊有关mq监听死信队列后是如何处理,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。

专注于为中小企业提供网站设计制作、网站建设服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业陇西免费做网站提供优质的服务。我们立足成都,凝聚了一批互联网行业人才,有力地推动了1000+企业的稳健成长,帮助中小企业通过网站建设实现规模扩充和转变。

昨天试了半天为啥监听不到死信队列的消息,原因是打开方式不对,还有死信队列就一条消息,没意思。

什么事务啊?我都没启用事务,他怎么就进去了呢?

你不说重试是默认6次吗?我都没改配置,怎么就进了?

1.如何让消息进入死信队列?

1.给ActiveMQConnectionFactory配上重发机制;2.给DefaultMessageListenerContainer配置事务;

或者给消息设置过期时间,过期后进入死信队列

我都没启用事务,说那些都是扯淡,将一个业务消费者干掉,然后将此消费者变为监听死信队列消费者,jmeter开10000线程循环去调

mq监听死信队列后是如何处理

消费者消费不到,然后每次消息出列+1,然后死信队列+1

关于重试机制RedeliveryPolicy

在ActiveMQConnectionFactory可设置RedeliveryPolicy,如果不设置则为默认

 /**     * Sets the global default redelivery policy to be used when a message is delivered     * but the session is rolled back  会话会被回滚     */    public void setRedeliveryPolicy(RedeliveryPolicy redeliveryPolicy) {        this.redeliveryPolicyMap.setDefaultEntry(redeliveryPolicy);    }

activemq官网API

http://activemq.apache.org/maven/apidocs/org/apache/activemq/RedeliveryPolicy.html

如果自定义

        RedeliveryPolicy redeliveryPolicy= new RedeliveryPolicy();          //是否在每次尝试重新发送失败后,增长这个等待时间          redeliveryPolicy.setUseExponentialBackOff(true);          //重发次数,默认为6次   这里设置为10次          redeliveryPolicy.setMaximumRedeliveries(10);          //重发时间间隔,默认为1秒          redeliveryPolicy.setInitialRedeliveryDelay(1);          //第一次失败后重新发送之前等待500毫秒,第二次失败再等待500 * 2毫秒,这里的2就是value          redeliveryPolicy.setBackOffMultiplier(2);          //是否避免消息碰撞          redeliveryPolicy.setUseCollisionAvoidance(false);          //设置重发最大拖延时间-1 表示没有拖延只有UseExponentialBackOff(true)为true时生效          redeliveryPolicy.setMaximumRedeliveryDelay(-1);

其他的方法可以看看源码

mq监听死信队列后是如何处理

重试不是6次吗?

public class RedeliveryPolicy extends DestinationMapEntry implements Cloneable, Serializable {
   public static final int NO_MAXIMUM_REDELIVERIES = -1;    public static final int DEFAULT_MAXIMUM_REDELIVERIES = 6;    默认确实是6次
   private static Random randomNumberGenerator;
   // +/-15% for a 30% spread -cgs    protected double collisionAvoidanceFactor = 0.15d;    protected int maximumRedeliveries = DEFAULT_MAXIMUM_REDELIVERIES;    protected long maximumRedeliveryDelay = -1;    protected long initialRedeliveryDelay = 1000L;    protected boolean useCollisionAvoidance;    protected boolean useExponentialBackOff;    protected double backOffMultiplier = 5.0;    protected long redeliveryDelay = initialRedeliveryDelay;

这里有个类似Hashmap的负载因子的东西,有一个波动范围,但本地的是4次

protected double collisionAvoidanceFactor = 0.15d;

2.消费到死信队列存的什么东西?

呐,就存的这玩意

mq监听死信队列后是如何处理object是我们想要的

消费内容ActiveMQObjectMessage {    commandId = 5,    responseRequired = true,    messageId = ID: KK - 59648 - 1599635155556 - 1: 239: 1: 1: 1,     originalDestination = null, originalTransactionId = null,     producerId = ID: KK - 59648 - 1599635155556 - 1: 239: 1: 1,     destination = queue: //add,     transactionId = null, expiration = 0, timestamp = 1599636301936, arrival = 0,     brokerInTime = 1599636301937, brokerOutTime = 1599636302110,     correlationId = null, replyTo = null, persistent = true, type = null,     priority = 4, groupID = null, groupSequence = 0,    targetConsumerId = null, compressed = false, userID = null,     content = org.apache.activemq.util.ByteSequence@54eae153,     marshalledProperties = org.apache.activemq.util.ByteSequence@1318dd4d,    dataStructure = null, redeliveryCounter = 0, size = 0, properties = {timestamp=1599636300958},    readOnlyProperties = true, readOnlyBody = true, droppable = false,    jmsXGroupFirstForConsumer = false}

3.新问题死信队列里存的对象或消息是动态的如何处理?

1.给业务指定一个死信队列名称,一对一的去消费死信队列,这样就知道入队和出队的内容了

2.入队之前给队列加一个属性值type,使用枚举判断转成什么类型,或者直接instance of,或者使用前缀/或缀什么的去转。

然后在消费时结合业务逻辑去处理就好了,如果转对象成功,去查库,

如果查到数据,判断最后操作时间如果在库里的时间后面则执行此条数据,如果在库里时间之前则删掉队列的这条消息或者不处理

如果查不到数据则直接执行本条数据。

话不多说,先来他10万次

mq监听死信队列后是如何处理

mq监听死信队列后是如何处理

另外业务中遇到死信队列的问题了吗?

没,只是在队列群中多看了它一眼,发现死信队列出现在我面前,就引发这么多问题。

看完上述内容,你们对mq监听死信队列后是如何处理有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注创新互联行业资讯频道,感谢大家的支持。


本文标题:mq监听死信队列后是如何处理
路径分享:http://kswjz.com/article/jdoidp.html
扫二维码与项目经理沟通

我们在微信上24小时期待你的声音

解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流