一、背景

近日，公司遭遇了一次因MQ消息队列故障导致的待办信息推送中断事件。小王，作为技术团队的一员，突然接到了业务部门的报障，称今日的待办信息未能如期推送至用户。这一消息让小王颇感意外，因为考虑到消息通知服务的不稳定性，他们团队先前已特地引入了MQ消息队列来实现消息推送的重试机制。

小王迅速展开排查，但在系统日志中并未发现与待办信息推送失败相关的记录。进一步检查MQ的消费情况后，他震惊地发现MQ服务竟然出现了宕机。面对这一突发状况，他立即通知了运维团队进行紧急处理。

此次事件引起了主管的高度重视。主管召集团队成员，共同探讨如何优化现有的系统架构，以防范类似故障的再次发生。在讨论中，主管提出了一个建议：是否可以考虑将待办消息推送与MQ消息队列进行解耦，并尝试使用其他更为可靠的重试方法。

大林子，作为团队中的资深成员，被cue到发表看法。他沉思片刻后表示，可以利用Spring框架提供的@Recover注解来实现消息推送的异常处理和重试机制。这种方法不仅能够有效应对MQ宕机等异常情况，还能提高系统的健壮性和可维护性。

经过讨论，团队最终决定采纳大林子的建议，并交由他负责实施这一优化方案。

二、注解配置

• value：指定需要重试的异常类型。

• include：除了value指定的异常外，还可以包括哪些异常进行重试。

• exclude：排除哪些异常，即使它们匹配了value或include配置。

• maxAttempts：最大重试次数。

• backoff：回退策略，如@Backoff可以设置延迟时间和随机增加的因子。

• retryExceptions：直接指定需要重试的异常列表，可以替代value。

（可选）使用@Recover

如之前所述，你还可以为重试失败后指定恢复逻辑，通过在同一个类中定义一个带有@Recover注解的方法

三、代码实现

<!-- Spring Retry -->
<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
</dependency>

@Configuration
@EnableRetry
public class RetryConfig {
}

@Override
@Retryable(value = {Exception.class}, maxAttempts = 3, backoff = @Backoff(delay = 1000))
public void test(){
    // 报错测试
    int i = 1/0;
}

@Recover
public void failureAlarm(Exception e) {
    log.error("消息通知，超三次失败", e);
}