RocketMQ5.0死信队列

消费逻辑的最终兜底机制，若消息一直处理失败并不断进行重试，直到超过最大重试次数还未成功，此时消息不会再重试，会被投递至死信队列。您可以通过消费死信队列的消息进行业务恢复。

死信队列

当一条消息初次消费失败，RocketMQ会自动进行消息重试，达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息。此时，该消息不会立刻被丢弃，而是将其发送到该消费者对应的特殊队列中，这类消息称为死信消息（Dead-Letter Message），存储死信消息的特殊队列称为死信队列（Dead-Letter Queue），死信队列是死信Topic下分区数唯一的单独队列。如果产生了死信消息，那对应的ConsumerGroup的死信Topic名称为%DLQ%ConsumerGroupName，死信队列的消息将不会再被消费。可以利用RocketMQ Admin工具或者RocketMQ Dashboard上查询到对应死信消息的信息。

云消息属性

云消息队列 RocketMQ 版默认不保存死信消息，消息转为死信状态后将被丢弃。

死信消息是作为一条新的消息被存储到死信Topic中，云消息队列属性变更如下：

• Message ID：死信消息转储到死信Topic后会生成新的Message ID。

• 用户自定义属性、消息体等用户设置的信息不变。

• 死信消息的保存时长：从进入死信Topic后重新开始计算。例如，某条消息生产者发送到服务端的时间为13∶00∶00，2个小时后（15∶00∶00）该消息消费失败且重试失败被存储至死信Topic，则该消息的保存时长从15∶00∶00开始计算。

• 保存死信消息的Topic只支持普通消息和顺序消息类型的Topic，事务消息类型和定时消息类型的Topic不能作为死信Topic。

• 不支持将生产原消息的Topic作为死信Topic（避免出现循环雪崩的问题）。在死信消息转存流程中，若系统发现死信Topic和生产消息的原Topic相同，则该条消息将被丢弃。

• 不同Topic的死信消息可以保存到同一个死信Topic中。

• 删除某个ConsumerGroup时，对应的死信Topic不会被删除。

• 若某个Topic被死信策略引用，删除该Topic前，您必须先解除该Topic的死信策略关系。

主机安装的RocketMQ5.0死信队列属性：

• 保存死信消息的Topic 支持普通消息，顺序消息类型和事务消息类型和定时消息

• Message ID：死信消息转储到死信Topic后会生成新的Message ID。

• 用户自定义属性、消息体等用户设置的信息不变。