一、消费流程图

消息在消费出现异常的时候，将一直保留在消息队列，所以你会看到以下奇怪的现象：

消息队列仅有5个消息， 投递速度也非常快，结果却一直无法消费掉。

二、重试策略

重试机制的使用场景：重试机制适用于那些可能因为临时问题（如网络问题、外部服务不可用等）导致处理失败的情况。

自定义重试逻辑：可以通过自定义错误处理器（如 RepublishMessageRecoverer）来实现更复杂的重试逻辑，例如记录重试次数并根据条件决定是否重新投递。

无限重试可能导致问题：如果消息本身存在问题（如格式错误），无限重试会导致大量日志输出，且可能阻塞队列。

本文就是中了此招，带来的后果就是SLS费用剧增。

1、重试次数

开启重试，设置重试的次数、间隔时间。

在计算间隔时间的时候，使用指数级增长，而非简单的倍数。

        listener:
            simple:
                retry:
                    enabled: true
                    max-attempts: 5  # 最大重试次数
                    initial-interval: 10000  # 初始重试间隔（毫秒）
                    max-interval: 30000 # 最大重试间隔（毫秒）
                    multiplier: 3 # 重试间隔的乘数因子

2、死信队列

为了避免消息无限重试，建议配置死信队列。当消息达到最大重试次数后，将其发送到死信队列，以便后续处理。

        listener:
            simple:
                default-requeue-rejected: false

通过合理配置重试机制和死信队列，可以有效避免消息无限重试导致的问题，同时确保消息的可靠处理。

建立死信消息监听者，对消息的最后处理，如果还是失败，则发送告警消息给相关人员。

当消费者在处理消息时抛出异常且达到最大重试次数后，消息会被拒绝并发送到死信队列，从而避免消息丢失并便于后续处理。

三、消息确认模式

在 Spring AMQP 的默认配置中，acknowledge-mode 的默认值是 AUTO，即自动确认模式。

最终rabbitmq的配置见下：

        listener:
            simple:
                retry:
                    enabled: true
                    max-attempts: 5
                    initial-interval: 10000
                    max-interval: 30000
                    multiplier: 3
                acknowledge-mode: auto
                default-requeue-rejected: false

自动确认模式（AUTO）

在自动确认模式下，当消费者接收到消息后，Spring AMQP 会自动向 RabbitMQ 发送确认消息（ACK），表示消息已被成功消费。这意味着：

• 优点：实现简单，不需要手动确认消息，适合简单的消费场景。
• 缺点：如果消费者在处理消息时抛出异常，消息会被认为已经消费成功，从队列中移除，不会重新投递。这可能导致消息丢失。

手动确认模式（MANUAL）

在手动确认模式下，消费者需要显式地调用确认方法（basicAck 或 basicNack）来确认消息。这意味着：

• 优点：可以更灵活地控制消息的确认时机，确保消息在成功处理后才被确认，从而避免消息丢失。
• 缺点：实现相对复杂，需要在代码中手动处理确认逻辑。

四、总结

消息在消费的时候，如果出现异常，直接抛弃，不想进入重试流程。
你可能会配置修改如下：

        listener:
            simple:
                retry:
                    enabled: false

回到最上面的流程图，其实还是无法解决消息消费失败的死循环。

虽然不会进入重试， 但是在消费消息的时候，由于抛异常，又会进入消息队列。

最终导致死循环。

解决方法是： 对于不想要重试，而又不陷入死循环。那么就只有一个办法，使用个大大的try-catch住消息监听方法。