超级会员免费看
当优惠券系统数据库宕机时，文章探讨了如何利用RocketMQ的消费重试机制和死信队列来解决异常场景。在数据库不可用时，不应返回CONSUME_SUCCESS，而应返回RECONSUME_LATER，让RocketMQ将消息放入重试队列。若16次重试后仍无法处理，消息会被转移到死信队列。死信队列的处理方式可根据具体业务需求定制，如设置后台线程持续重试或进行其他操作。
1. 如果优惠券系统的数据库宕机，会怎么样？
假设我们的MQ使用都没有问题，但是如果我们的优惠券系统的数据库宕机了呢？因为我们一直都是假设了一个场景，就是订单支付成功之后会推消息到MQ，然后优惠券系统、红包系统会从MQ里获取消息去执行后续的处理，比如发红包或者发优惠券。
那么如果这个时候，优惠券系统的数据库宕机了，就必然会导致我们从MQ里获取到消息之后是没办法进行处理的。
所以针对这样的一个坑爹的异常场景，我们应该怎么处理？优惠券系统应该怎么对消息进行重试？重试多少次才行？万一重复重试都没法成功，这时候消息应该放哪儿？
2. 数据库宕机的时候，你还可以返回CONSUME_SUCCESS吗？
在下面代码片段中，可以清晰的看到，我们注册了一个监听器回调函数，当consumer获取到消息之后，就交个我们的函数来处理
consumer.registerMessageListener(
订阅专栏 解锁全文
扫一扫
1893
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
