一、背景
近日,公司遭遇了一次因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);
}