消息消费异常时会自动进行消费重试，达到最大重试次数后还未成功，则消息会转为死信状态。云消息队列 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 版控制台配置是否保存死信消息。
操作入口如下：
在实例列表页面中单击目标实例名称。
在左侧导航栏单击Group 管理，然后在Group 管理页面单击创建 Group。
死信消息可观测指标
指标说明
指标类型 | 指标项 |
rocketmq_send_to_dlq_messages：每分钟转为死信状态的消息量 | |
|
指标应用
云消息队列 RocketMQ 版支持配置死信消息相关告警，可以帮助您在业务反馈前及时发现异常，并结合Dashboard指标结果可以进一步排查异常来源。
使用建议
消费者如何获取原Topic信息
方案一：在设置死信Topic时，将死信Topic和原Topic进行一一对应。
例如，原消息Topic为testTopic，则将死信Topic设置为DLQ-testTopic。
方案二：将原Topic的信息设置到消息的自定义属性中。示例如下：
messageBuilder.addProperty("originalTopic","testTopic")
死信消息和主业务区分处理
死信消息是正常业务流程中消息重试仍然失败的消息，需要和主业务流程分开处理，避免影响正常业务。
死信Topic和原消息发送Topic不能相同，避免死信消息通过循环配置流转回原Topic，导致无法消费的消息影响正常的ConsumerGroup业务，引起业务雪崩。
避免使用生产流程中的ConsumerGroup去消费死信消息，影响正常消息的消费。