一. 问题
近日有学生问壹哥,应该怎样理解【阿里巴巴开发规约中提到的乐观锁至少要重试三次】的规定,为了让大家更好的理解这一点,壹哥先来引用一下阿里巴巴开发规约中的相关规定。
【强制】并发修改同一记录时,避免更新丢失,需要加锁。要么在应用层加锁,要么在缓存加锁,要么在数据库层使用乐观锁,使用 version 作为更新依据。
说明:如果每次访问冲突概率小于 20%,推荐使用乐观锁,否则使用悲观锁。乐观锁的重试次数不得小于 3 次。
二. 解答
对于这个问题,壹哥是这么认为的。【乐观锁采用CAS机制,在事务的最后才会根据version来判断事务是否能够提交成功。很多时候,仅仅只是因为其他的事务快一步更新了version,就导致整个事务提交失败,这样给用户的体验并不好,所以咱们要在这里让事务重试几次,提升用户的使用体验】。
其实重试的方式有很多,今天壹哥来给大家介绍一款Spring自带的重试框架 【spring-retry】
三. spring-retry 框架介绍
2.1 spring-retry框架是什么
spring-retry是spring提供的一个重试框架,它通过几个注解就可以优雅的实现重试的功能。
2.2 怎样使用spring-retry框架
导入依赖
-
<dependency>
-
<groupId>org.springframework.retry
</groupId>
-
<artifactId>spring-retry
</artifactId>
-
</dependency>
在主程序能够扫描到的类上,或者直接在主程序上添加@EnableRetry注解,开启重试。
-
@SpringBootApplication
-
@EnableRetry
-
public
class
BankApplication {
-
-
public
static
void
main
(String[] args) {
-
SpringApplication.run(BankApplication .class, args);
-
}
-
}
在有可能需要重试的方法上添加注解。
-
@Transactional
-
@Retryable(value = { RetryException.class }, maxAttempts = 3, backoff = @Backoff(delay = 1000l, multiplier = 2,maxDelay = 10000l))
-
// @Retryable 加上此注解 那么这个方法就有可能重试
-
// value = { RetryException.class } 当方法中抛出RetryException异常就要重试
-
// maxAttempts 最大重试的次数
-
// Backoff 回避策略
-
// delay 第一次重试的延迟时间
-
// multiplier 下一次重试的延迟时间,公式为:上一次delay* multiplier
-
// maxDelay:最长延迟时间
-
public
void
getMoney
(String ano, BigDecimal money){
-
-
// 1 查询账号是否存在
-
TbAccount
tbAccount
= accountMapper.selectByPrimaryKey(ano);
-
if (tbAccount ==
null) {
-
throw
new
AppException(ResponseEnum.ACCOUNT_NOT_FOUND);
-
}
-
-
// 2 余下额度是否够
-
if(tbAccount.getAccountMoney().compareTo(money)<
0){
-
throw
new
AppException(ResponseEnum.ACCOUNT_MONEY_NOT_ENOUTH);
-
}
-
-
// 3 更新取钱
-
int
count
= accountMapper.updateMoney(ano, money, tbAccount.getVersion());
-
if(count==
0){
-
throw
new
RetryException(
"");
-
}
-
-
System.out.println(
"取钱成功");
-
}
如果最大重试次数也重试完了,但还是失败的话,添加我们将要执行的逻辑。
-
@Recover
-
public
void
recover
(RetryException e) {
-
throw
new
AppException(ResponseEnum.ACCOUNT_EXCEPTION);
-
}
四. 小结
到此,细心的同学应该已经能发现,spring-retry这个框架的底层原理其实就是aop的异常增强。当方法中抛出指定类型异常的时候,我们就给予一定次数的重试。
另外,重试的业务场景也不一定就局限在乐观锁上面,其他很多业务场景也需要使用到重试。
比如说:
- 由于网络波动或者系统太忙,造成远程调用失败需要重试;
- 秒杀时使用分布式锁时,当一个事务锁住商品,导致其他的购买请求不能正常进行时也需要重试。
转载:https://blog.csdn.net/syc000666/article/details/127682263