🍊 Java学习：Java从入门到精通总结
🍊 深入浅出RocketMQ设计思想：深入浅出RocketMQ设计思想
🍊 绝对不一样的职场干货：大厂最佳实践经验指南
📆 最近更新：2022年11月4日
🍊 个人简介：通信工程本硕💪、Java程序员🌕。做过科研paper，发过专利，优秀的程序员不应该只是CRUD
🍊 点赞 👍 收藏 ⭐留言 📝 都是我最大的动力！
文章目录
- 死信队列重新投递
- 定时重新投递
死信队列重新投递
当消息消费失败时，消息队列RocketMQ会自动进行消息重试，达到最大重试次数后，如果依然没有消费成功的话，说明消费者无法正常消费该消息了。
在这种情况下，RocketMQ不能直接把消息给丢弃掉，而是会将其发送到该消费者对应的死信队列中。
死信消息的特征：
- 不会再被
Consumer正常消费 - 有效期与正常消息相同，均为3天后会被自动删除
- 一个死信队列对应一个
Group ID，而不是对应单个消费者实例 - 一个死信队列包含了对应
Group ID下所有Topic产生的所有死信消息 - 可以从RocketMQ的控制台对死信队列里的消息进行操作：查询、导出、重发等
死信消息查询维度：
| 查询方式 | 查询条件 | 查询类别 | 说明 |
|---|---|---|---|
| 按照Group ID查询 | Group ID + 时间段 | 范围查询 | 根据ID和时间范围批量获取消息，查询量较大，不易匹配到具体的消息 |
| 按照Message ID查询 | Group ID + Message ID | 精确查询 | 根据两个ID可以精确定位到某条消息 |
死信消息产生的时间通常是一条消息被发送到死信队列的时间
导出死信消息：
可以在RocketMQ的控制台里将其导出，以避免消息超过有效期。控制台提供批量导出功能，包含如下信息：
| 消息字段 | 字段含义 |
|---|---|
| topic | 消息所属的Topic |
| msgId | 消息ID |
| bornHost | 消息产生的地址 |
| bornTimestamp | 消息产生的时间 |
| storeTimestamp | 消息被存储到死信队列的时间 |
| reconsumeTimes | 消费失败次数 |
| properties | 消息属性（JSON格式） |
| body | 消息体（base64编码） |
| bodyCRC | 消息体CRC |
重发死信消息：
当排查并解决了问题之后，管理员可以在消息队列RocketMQ的控制台控制重新发送这条消息，并重新发送给Consumer进行消费。
也可以人工导出死信队列里的消息，并将他们重新再投递到Broker一次
定时重新投递
为了防止消息丢失，可以将死信消息存储在本地消息表里，并定时进行重新投递。
具体的，在实际业务中，可能会出现一种极限情况：某条消息一直无法消费成功变成了死信消息，要写入到死信队列里，此时恰好Broker宕机了，这样这条消息就丢失了。
对于一些核心业务来说，消息时100%不能丢失的，可以采用本地存储消息表的形式来进行失败消息的方式，并开启一个定时任务，进行失败消息的重新投递。
