死信消息 - 云消息队列 RocketMQ 版

消息消费异常时会自动进行消费重试，达到最大重试次数后还未成功，则消息会转为死信状态。云消息队列 RocketMQ 版支持将这些死信消息保存至指定Topic，方便后续进行业务恢复或回溯。本文介绍死信消息的应用场景、死信策略、使用限制、配置方法和使用建议。

应用场景

典型死信消息处理场景
消息重试失败后，您可以选择将死信消息存储到指定的死信Topic中，通过另外创建一个ConsumerGroup消费这些死信消息来处理异常链路或分析死信消息。
典型错误使用死信消息场景
处理死信消息时，如果将死信消息多层流转，转储回原Topic，会引起死信消息再次被循环重试，可能会引起雪崩效应。

消息重试达到最大重试次数后还没有被成功消费，消息将不再被投递，转为死信状态。

死信消息

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

您可以通过控制台开启死信消息保存功能，开启后，死信消息将被存储至指定的Topic中，该Topic被称为死信Topic。具体操作，请参见配置死信消息保存规则。

死信消息是作为一条新的消息被存储到死信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的死信策略关系。

您可以在云消息队列 RocketMQ 版控制台配置是否保存死信消息。

操作入口如下：

消费重试

指标类型	指标项
Metrics元数据指标	rocketmq_send_to_dlq_messages：每分钟转为死信状态的消息量
云监控项	每分钟转为死信状态的消息量（GroupId&Topic）：SendDLQMessageCountPerGid 每分钟转为死信状态的消息量（GroupId）：SendDLQMessageCountPerGidTopic

云消息队列 RocketMQ 版支持配置死信消息相关告警，可以帮助您在业务反馈前及时发现异常，并结合Dashboard指标结果可以进一步排查异常来源。

场景一：查看每分钟转成死信状态的消息量
您可以在仪表盘中查看每分钟转为死信状态的消息量的表盘数据，也可以通过云监控添加每分钟转为死信状态的消息量（GroupId&Topic）告警进行监控。
场景二：查看还有多少死信消息未处理
当死信消息被保存至指定Topic中，您可以在仪表盘中查看指定死信Topic的消费堆积量指标数据，也可以通过云监控添加消息堆积量（GroupId&Topic）告警进行监控。

方案一：在设置死信Topic时，将死信Topic和原Topic进行一一对应。
例如，原消息Topic为testTopic，则将死信Topic设置为DLQ-testTopic。
方案二：将原Topic的信息设置到消息的自定义属性中。示例如下：
```
messageBuilder.addProperty("originalTopic","testTopic")
```

死信消息是正常业务流程中消息重试仍然失败的消息，需要和主业务流程分开处理，避免影响正常业务。

死信Topic和原消息发送Topic不能相同，避免死信消息通过循环配置流转回原Topic，导致无法消费的消息影响正常的ConsumerGroup业务，引起业务雪崩。
避免使用生产流程中的ConsumerGroup去消费死信消息，影响正常消息的消费。