面试题：消息队列RocketMQ重试次数的设置及对业务的影响

Question

RocketMQ如何设置消息的最大重试次数？不同的重试次数设置对业务会产生怎样不同的影响？结合具体业务场景阐述。

Answer 1

设置消息最大重试次数

在RocketMQ中，可以通过Consumer端的配置来设置消息的最大重试次数。以Java客户端为例，通过DefaultMQPushConsumer对象设置：

DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("consumerGroup");
consumer.setMaxReconsumeTimes(3); // 设置最大重试次数为3次

也可以在控制台或者通过修改配置文件来设置消费组的最大重试次数。

不同重试次数设置对业务的影响

1. 重试次数设置较少（如1 - 2次）
   • 优点：能快速结束重试流程，减少因反复重试对系统资源（如CPU、网络等）的消耗。例如在一些对实时性要求不高，且处理逻辑简单的日志收集业务场景中，如果日志数据处理失败，少量的重试能够在短时间内确定是否需要人工介入处理，避免大量无效重试占用资源。
   • 缺点：可能因为重试次数不足，导致一些短暂的网络波动、瞬时的系统繁忙等原因造成的消息处理失败无法成功恢复，从而丢失部分业务数据。比如在一个简单的订单状态更新业务中，如果因为短暂的数据库连接闪断导致更新订单状态消息处理失败，仅重试1 - 2次可能无法成功更新订单状态，影响业务完整性。
2. 重试次数设置较多（如5次以上）
   • 优点：对于一些复杂业务逻辑，较多的重试次数能提高消息处理成功的概率。比如在涉及多个系统交互的电商订单处理业务中，订单创建消息需要同时更新库存系统、支付系统等多个关联系统的数据。由于系统间交互复杂，可能会因为某个系统的短暂性能问题导致消息处理失败，较多的重试次数能给予更多机会来完成整个订单处理流程，保证业务的完整性。
   • 缺点：过多的重试会占用大量系统资源，包括网络资源、CPU资源等。同时，如果业务存在死循环问题导致消息一直无法成功处理，过多的重试会使问题持续存在，甚至导致整个系统性能下降。例如在一个数据同步业务中，如果源数据和目标数据存在逻辑冲突导致数据同步消息反复处理失败，过多的重试会加重系统负担，影响其他正常业务的运行。