rocketMq中，消费者消费一条消息后，需要回复broker消息的消费状态，消费状态共有两种，consume_success表示消费成功，reconsume_later表示稍后重新消费，在实现消费逻辑时，如果消费失败，并希望可以重新消费，应该返回一个reconsume_later状态，本文旨在说明返回该状态后rocketMq中的处理流程，也就是rocketMq是如何进行失败消息重试的
我们以topic=topic_1,groupId=GID_1为例，讲述该组中消费者消费一条消息，并返回reconsume_later后的处理逻辑
1.原消息，也就是消费失败的消息内容如下：重点关注我标红的两个属性(topic使我们熟悉的topic_1，bornTimestamp是指消息的创建时间)
消息消费失败后，consumer会将消息发回给broker，可以简单理解为消费者表示这消息我现在消费不了，还给你，待会我再来试试。如果本次发送失败，则5s后在消费端重新消费，当然了，正常情况下，都会发送成功，下面讨论发送成功的情况
2.broker端收到回发消息的请求后，处理逻辑和生产者发来消息是不一样的，对于消费者发回的消费失败的消息，会将消息进行转换，转换后内容如下：
可以看到，topic已经不再是我们熟悉的topic_1了，变成了%RETRY%GID_1(%RETRY%{groupId})，RETRY_TOPIC是原消息的topic，DELAY是延时等级，不同等级延时时效不一样，等级越高，延时越久
3.然后在存储时，commitLog中会判断DELAY属性是否>0，是表示这个应该作为延时消息存储，然后又是一顿转换，转换后的消息如下：
你应该发现了，topic又变了，变成了延时队列专用的topic，SCHEDULE_TOPIC_XXXX，REAL_TOPIC是本次转换前的RETRY队列topic
好了，延时消息已经存储好了，此时，broker中存了两条消息，一条原消息，topic=topic_1，存在队列queue2(queueId=2)中，虽然消费者返回了RECONSUME_LATER，但对于broker来说，topic_1里的这条消息已经被GID_1这个消费者组消费过了，消费位点随之增加，该消费者组会继续消费queue2后面的消息；这一点很重要，不能因为某些消息消费失败影响了后续消息的正常消费
另一条是延时消息，topic=SCHEDULE_TOPIC_XXXX，这个topic对消费者是不可见的，只有broker内部可以看到，那消费者如何重新消费呢？
4.broker在启动时，会启动一个ScheduleMessageService任务，该任务用于处理延时队列中的消息，延时队列的topic是固定的SCHEDULE_TOPIC_XXXX，延时队列分为1~18个level，其用意就是用不同的level等级表示不同的延时，level越高，表示重试过的次数越多，相应的，下次延时越久(每消费失败一次，level会加1)，每个level对应一个queue，第一次消费失败的消息存入queue1，再失败就存入queue2，每个level对应的延时时间如下(单位毫秒)：
{1=1000, 2=5000, 3=10000, 4=30000, 5=60000, 6=120000, 7=180000, 8=240000, 9=300000, 10=360000, 11=420000, 12=480000, 13=540000, 14=600000, 15=1200000, 16=1800000, 17=3600000, 18=7200000}
每个队列都有一个专门的Timer定时器去轮询其中的消息，拉到消息后，判断消息的生产时间+延时时间是否超过当前时间(延时时间就是上面给出的与level对应的时间，生产时间就是我们上面四幅图中框出的bornTimestamp，可以看到，无论怎么转换，这个字段值都是不变的)，是则表明该消息到了要处理的时间了，就将消息转换成如下内容，进行存储
可以看到，topic又变成了%RETRY%GID_1，不过这次不会再被转换了，会直接存储到commitLog中，并且这个topic对消费者是可见的
消费者在启动后，会被动订阅topic=%RETRY%{groupId}的消息(本例中，groupId=GID_1)，那上面这条消息就会被消费者拉取到，再次消费
如果消费再次失败，则继续上面的过程，不同之处就是其延时level增1，消息进入延时等级更高的队列中，等待更长时间后被处理，如果超过最大重试次数后，还是失败，则消息从延时队列移除，进入死信队列
PS:如果有不足之处，欢迎指出；如果解决了你的疑惑，就点个赞吧o(*￣︶￣*)o