Redis分布式锁解决接口幂等的两种方案分布式锁解决接口幂等的两种方案
Redis分布式锁解决接口幂等的两种方案分布式锁解决接口幂等的两种方案一、背景二、基础知识三、解决方案四、实验五、说在最后的话
一、背景一、背景
还在为不了解分布式锁而烦恼吗？还在为众多微服务接口不幂等而发愁吗？如果是，并且有兴趣同我一起学习，那请接着看本
文，通过本文能够学习到分布式锁的基本原理、如何实现分布式锁以及使用分布式锁解决接口幂等问题。
二、基础知识二、基础知识
本文是通过使用 Redis 实现分布式锁，当然也可用使用各大数据库，比如 Mysql、Oracle 自持的行级锁、大厂的 Zookeeper
等方案实现。
分布式锁的基本思想
我们既然称其为“锁”，那就是说只有唯一的一把钥匙才能将锁打开，将这种思想放到我们软件设计上来，那就是在同一时间内
只有同一个进程或者线程拥有这个”钥匙“来锁住资源，防止其他进程或线程用”钥匙“锁住同一个资源。当然，这是一种通俗的
理解，在我们软件工程中，“锁”是要更复杂，更难以掌握的。
Redis 实现分布式锁原理
Redis 主要是利用命令 redis.call() 、SETNX 和 PEXPIRE 实现分布式锁的，但是因为是两个分开的命令，单独执行这两个命令肯定
是非原子性，根据答墨菲定理未来一定会发生非原子的操作。好在一点是的 Redis 可以使用 Lua 脚本将单独的多个命令统一
顺序执行，命令 EVAL。通过 EVAL 命名可以执行多个命令，这些命名要么都成功，要么都失败（这就是我们想要的事务的原
子性啊）。关于 Lua 脚本如何使用，Redis 官网有示例，可以点击 Lua 脚本使用 学习。如果觉得 Lua 太难，那就感谢 Redis
帮我们实现了分布式锁框架 Redisson 吧，Redisson 实现分布式锁。另外 Redisson 帮我们实现了更多细节问题，例如，通过加
入 watchdog 监控锁的状态，当实例还在运行时自动帮你续约（实际就是通过命令 PEXPIRE 重新设定过期时间）。
三、解决方案三、解决方案
为了能够在多场景下复用，避免重复造轮子的现象，我们可以借助 Spring AOP 技术，通过自定义注解 @ApiIdempotent 来实
现，写好后在打成 jar 放到我们的中央仓库，在项目上引入 jar ，再在需要控制接口幂等的 Controller 方法上加上我们的注解
即可，方便快捷。我这下面自定义一个接口幂等的注解：
/**
* 自定义接口幂等注解
* @author ouyang
* @version 1.0
* @date 2020/4/20 11:21
**/
@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface ApiIdempotent {
/**
* 过期时间，单位：ms。 默认2000
*/
long expire() default 2000;
/**
* 重试次数，默认0
*/
int retryTimes() default 0;
/**
* 重试间隔时间，单位：ms，默认100
*/
long retryInterval() default 100;
}
本注解 @ApiIdempotent 支持自定义锁时间、重试加锁次数及重试间隔设置。
/**
* @author ouyang
* @version 1.0
* @date 2020/4/20 11:21
**/
@Aspect
@Component
public class ApiIdempotentAspect {
private final Logger logger = LoggerFactory.getLogger(ApiIdempotentAspect.class);
private final RedisLockUtil redisLockUtil;
评论0