36 消息处理失败场景下死信队列的解决方案

你的名字 2022-08-31 11:09 187阅读 0赞

### 1. 消息处理失败的场景-优惠券系统的数据库宕机 ###

在基本确保MQ的消息不丢失，且同时不会对消息进行重复处理的情况下，在正常流程下，基本就没什么问题了。

在MQ使用没问题之后，这里要考虑一个问题，那就是如果消费者所在的优惠券系统的数据库宕机了该怎么办？

在前面的场景中，订单支付成功之后会推送消息到MQ，然后优惠券系统、红包系统会从MQ里获取消息去执行后续的处理，比如发红包或者发优惠券。

如果优惠券系统的数据库宕机了，就会导致消费者端所在的系统从MQ里获取到消息之后没办法进行处理。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70][]

在上述的场景中，需要考虑以下几个问题：

1.  优惠券系统应该怎么对消息进行重试？
2.  重试多少次才行？
3.  如果反复重试依旧无法成功，这时消息应该怎么处置？保留还是丢掉？

### 2.数据库宕机的时候，避免直接返回 CONSUME\_SUCCESS ###

在MQ的消费者逻辑中，我们注册了一个监听器回调函数，当Consumer获取到消息之后，就会叫个该函数去处理。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 1][]

在之前的分析中，当消费者的逻辑在回调函数中对消息进行处理，比如发红包、发优惠券之类的，处理完成之后，就可以返回一个状态告诉RocketMQ Consumer这批消息的处理结果。

按照正常的流程，如果返回的是CONSUME\_SUCCESS，那么Consumer就知道这批消息处理完成了，就会对提交这批消息的Offset到broker去，然后下次就会继续从broker获取下一批消息来处理了。

但是如果在上面的回调函数中，对一批消息发优惠券的时候，因为数据库宕机了，导致优惠券发放逻辑无法完成，此时就不能返回CONSUME\_SUCCESS状态了。

如果你返回的话，下一次就会处理下一批消息，但是这批消息其实没处理成功，此时必然导致这批消息就丢失了。

肯定会导致有一批用户没法收到优惠券的。

### 3. 如果对消息的处理有异常，可以返回RECONSUME\_LATER状态 ###

在面对上述数据库宕机的问题，会导致这批消息的处理是异常的，此时没法处理这批消息，我们就应该返回一个 CONSUME\_LATER 状态。

**CONSUME\_LATER** 的意思是，我现在没法完成这批消息的处理，麻烦你稍后过段时间再次给我这批消息让我重新试一下！

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 2][]

上述的代码与之前的做出了修改，如果消息处理失败了，就会进入catch() 语句块中返回 RECONSUME\_LATER 状态，让RocketMQ稍后再重新把这批消息给我，让我重试对这批消息进行处理。

### 4. RocketMQ发起消费重试的原理 ###

RocketMQ 在收到消费者返回的 RECONSUME\_LATER 状态之后，让消费者进行消费重试的逻辑如下：

简单来说，RocketMQ 会有一个针对该 ConsumerGroup 的重试队列。如果消费端返回了 RECONSUME\_LATER 状态，它会把这批消息放到该消费组的重试队列中去。

这里要说明的是，MQ将消息放到消费组的重试队列是基于返回的 RECONSUME\_LATER状态后自己去处理，不需要再新增其他配置或代码去触发了。

**场景说明：**

假如你的消费组的名称是“VoucherConsumerGroup” ，也就是说这优惠券系统的消费组，它对应的就会有一个“%RETRY%VoucherConsumerGroup” 这个名字的重试队列。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 3][]

在经过一段时间之后，重试队列中的消息会再次推送给我们的消费者，让我们进行处理。如果再次失败，就又返回了 RECONSUME\_LATER，如此返回多次，默认最多是重试16次！

在多次重试消息的过程中，每次重试之间的间隔时间是不一样的，这个间隔时间可以如下进行配置：

messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h

上面这段配置的意思是，第一次重试是1秒后，第二次重试是5秒后，以此类推，知道重试第16次是2h后。

### 5.如果连续重试16次还是无法处理消息，进入**“死信队列”** ###

连续重试16次在最大程度上保证了消息处理成功。但也有例外，当在16次重试范围内都无法成功处理，就需要另一个队列了，也就是**死信队列。**

**死信队列**，意思是**死掉的队列就放这个队列里**。也就是一批消息在重试16次之后还无法成功处理掉，就不再重试消息，而是直接被判定为死掉了，会自动进入到**死信队列**里去。

死信队列的名字是 “%DLQ%VoucherConsumerGroup” ，这是可以在 RocketMQ 的管理后台上看到的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 4][]

对于死信队列中的消息的处理方式如下：

这是看使用场景而定，比如我们可以专门开一个后台线程，去订阅 “%DLQ%VoucherConsumerGroup” 这个死信队列，对死信队列中的消息，继续不停的重试处理。

### 6. 消息处理失败场景下的方案总结 ###

在MQ消费者底层的发生故障，比如发生数据库宕机、缓存宕机等情况时，消费者系统就无法完成消息的处理，此时可以通过一些返回状态让消息进入 RocketMQ 自带的重试队列；如果重试16次消息处理后还是失败，就可以让消息进入RocketMQ自带的死信队列，后续针对死信队列中的消息进行单独的处理就可以了。

### 7. 扩展 ###

（1）消费失败返回 RECONSUME\_LATER状态，消息进入重试队列，此时消息处理失败，是不会提交offset 的。

（2）死信队列和正常消息一样是一个Topic，所以定期会在磁盘里面被清理掉。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70]: /images/20220829/b55ac23c4f494c0f85feb7d726e8f50b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 1]: /images/20220829/5b969e831605401f85f4ee87476d4d59.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 2]: /images/20220829/1d0c2bf94c2c4789ac275efb3cf9668d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 3]: /images/20220829/ed1e6e37001f4b96871fd1f6830a40e9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQwNTY3MA_size_16_color_FFFFFF_t_70 4]: /images/20220829/6e06c862327442e091916542c670e311.png