ActiveMQ Artemis单节点DLQ出现大量Messages killed的技术问询

问题描述 #

我的单节点ActiveMQ Artemis broker的死信队列（DLQ）中存在大量"Messages killed"记录。根据定义，"Messages killed"指：因超过最大投递次数而被broker终止的消息数量，统计自所有队列的subcomponent=queues#MessagesKilled之和。我想了解ActiveMQ Artemis该设计旨在解决什么业务场景？为何DLQ会产生Messages killed计数？原本我预期该数值初始应为0。

相关属性信息：

• Acknowledge attempts 68890
• Address DLA
• Configuration managed false
• Consumer count 0
• Consumers before dispatch 0
• Dead letter address DLA
• Delay before dispatch -1
• Delivering count 0
• Delivering size 0
• Durable true
• Durable delivering count 0
• Durable delivering size 0
• Durable message count 1539
• Durable persistent size 2183288
• Durable scheduled count 0
• Durable scheduled size 0
• Enabled true
• Exclusive false
• Expiry address ExpiryQueue
• ...
• Group buckets -1
• Group count 0
• Group first key
• Group rebalance false
• Group rebalance pause dispatch false
• Id 1006063
• Last value false
• Last value key
• Max consumers -1
• Message count 1539
• Messages acknowledged 0
• Messages added 70429
• Messages expired 0
• Messages killed 68890
• Name jms.queue.satellitanalys_request.DLQ
• Object Name org.apache.activemq.artemis:broker="0.0.0.0",component=addresses,address="DLA",subcomponent=queues,routing-type="multicast",queue="jms.queue.satellitanalys_request.DLQ"
• Paused false
• Persistent size 2183288
• Prepared transaction message count 0
• Purge on no consumers false
• Retroactive resource false
• Ring size -1
• Routing type MULTICAST
• Scheduled count 0
• Scheduled size 0
• Temporary false
• User

解答 #

一、"Messages killed"机制的设计目的 #

这个机制核心是防止消息无限循环投递，专门解决两类业务场景：

• 消费者端存在不可恢复的错误：比如消费者代码有bug、依赖的下游服务永久宕机，导致收到消息后始终无法正常确认（ack），消息会被broker反复重新投递，持续占用CPU、内存、磁盘资源，甚至拖垮整个消息服务。
• 消息本身存在不可修复的问题：比如消息格式损坏、携带的业务数据完全非法，无论投递多少次，消费者都无法处理，继续投递纯粹是浪费资源。

简单来说，就是给错误消息的投递次数设个上限，把无法修复的消息从正常流转链路中剔除，避免无效循环消耗资源，保障broker整体的稳定性。

二、DLQ出现"Messages killed"计数的原因 #

结合你提供的属性数据，核心原因是DLQ自身的消息触发了最大投递次数限制，具体分析：

1. 你的DLQ配置的Dead letter address是DLA，也就是它自己所在的地址。这意味着当DLQ里的消息再次达到最大投递次数时，broker没办法把它转发到其他死信地址，只能选择终止这条消息，计入Messages killed。
2. 数据里Acknowledge attempts和Messages killed数值完全一致（都是68890），说明这些被终止的消息都是因为投递后始终没收到消费确认，达到最大重试次数后被broker终止。
3. 另外DLQ的Consumer count为0，没有消费者去处理这些死信消息，导致消息在DLQ里不断被broker尝试投递（因为没有消费确认，broker会判定投递失败，反复重试），直到触达最大投递次数上限，最终被终止。

你预期这个数值初始为0是合理的，但当DLQ配置不当（死信地址指向自身）且没有消费者处理时，就会出现大量消息被终止的情况。

内容的提问来源于stack exchange，提问作者Demas Sinner