面试题答案
一键面试方案一：调整重试策略
- 实现方式：在代码中修改RocketMQ的重试次数和重试间隔。例如，通过设置
MessageListenerConcurrently的maxReconsumeTimes来减少重试次数，通过配置retryAnotherBrokerWhenNotStoreOK来优化重试逻辑，避免在某些不必要的情况下重试。同时可以动态调整重试间隔，如指数退避策略，首次重试间隔短，随着重试次数增加，间隔逐渐变长。 - 优点：实现简单，在不改变整体架构的情况下，通过调整少量代码参数即可优化。可以在一定程度上控制重试频率，避免过于频繁的重试对系统资源的过度消耗。
- 缺点：如果重试次数设置过低，可能导致一些确实可以通过重试成功的消息永久失败；若重试间隔设置不合理，可能无法有效利用资源进行重试。
- 适用场景：适用于业务场景对消息可靠性要求不是极高，且目前重试机制导致系统资源紧张，急需快速缓解压力的情况。
方案二：引入死信队列（DLQ）
- 实现方式：在系统架构层面，为RocketMQ配置死信队列。当消息重试达到一定次数后，将消息发送到死信队列。然后单独启动一个消费组来处理死信队列中的消息，这个消费组可以采用与主消费逻辑不同的处理策略，例如人工介入处理、记录日志后忽略等。
- 优点：将重试失败的消息与正常消息隔离，避免大量重试消息对正常消息消费的影响，提高主业务流程的稳定性。可以对死信队列中的消息进行集中管理和分析，方便定位问题。
- 缺点：增加了系统的复杂度，需要额外维护死信队列的消费逻辑。如果死信队列处理不当，可能导致消息堆积在死信队列中，长期占用资源。
- 适用场景：适用于对消息可靠性要求较高，且需要对重试失败消息进行特殊处理和分析的场景，如金融交易等业务场景。
方案三：异步处理重试消息
- 实现方式：在代码实现上，将消息重试逻辑放到异步线程池中处理。当消息消费失败时，将重试任务提交到线程池，主线程继续处理后续消息。在系统架构上，可以采用生产者 - 消费者模型，生产者将重试任务发送到一个队列（如内存队列或其他轻量级队列），消费者从队列中取出任务并在异步线程池中执行。
- 优点：不会阻塞主线程，保证主业务流程的高并发处理能力。通过线程池和队列的缓冲，可以有效控制重试任务的执行频率和并发度，提高系统的整体性能。
- 缺点：引入线程池和队列增加了代码实现的复杂度，需要处理线程安全、队列满等问题。如果线程池配置不合理，可能导致任务堆积或资源浪费。
- 适用场景：适用于高并发场景下，对主业务流程的响应时间要求较高，且可以容忍一定程度的异步处理延迟的场景，如电商订单处理等业务场景。