详解Redis如何保证接口的幂等性
背景
如何防止接口中同样的数据提交,以及如何保证消息不被重复消费,这些都是shigen
在学习的过程中遇到的问题。今天,趁着在学习redis
的间隙,我写了一篇文章进行简单的实现。
注意:仅使用于单机的场景,对于分布式、高并发场景,还是建议使用分布式锁。
首先我们分析一下Restful接口和幂等性的关系:
请求方式 | 是否幂等 | 对应的sql案例 |
---|---|---|
get | 是 | select * from user; |
put | 是 | update user set name=‘shigen’ where id =10001; |
delete | 是 | delete from user where id = 10002; |
Post | 否 | insert into user (id, name) values(10002, ‘shigen’); |
可见我们主要是针对post的请求方式做进一步的优化。
常用的解决方式
大概主流的解决方案:
token机制(前端带着在请求头上带着标识,后端验证)
加锁机制
- 数据库悲观锁(锁表)
- 数据库乐观锁(version号进行控制)
- 业务层分布式锁(加分布式锁redisson)
全局唯一索引机制,ID不能重复
redis的set机制
前端按钮加限制,类似于vue的
v-once
指令,但前提是用户不刷新页面
今天用到的就是redis的set方法。我们只需要一个注解即可实现,接下来看看shigen
是如何的设计吧!
代码实现
- 自定义注解
Idempotent
其中的value表示接口的唯一标识,可以为空,下边的IdempotentAspect
中会讲到
- 定义
IdempotentAspect
的切片
这里主要是定义一个切片的环绕通知,在里边处理主要的接口防刷逻辑
- 幂等性处理类
IdempotentProcessor
接口的唯一标识变成了方法名+方法的参数
- 幂等性处理接口
IdempotentProcessor
的实现类RedisIdempotentProcessor
好的所有的准备已经就绪,现在我们写一个测试的接口测试一下:
采用的是get请求测试,是为了方便。post请求的使用也和案例一样。
直接写上一个注解即可。我们还是采用ab
进行测试。
ab -n 2 '127.0.0.1:9000/idempotent/test?msg=test'
控制台的输出如下:
成功了一次,失败了1次,并且redis中出现了值为true
的keytesttest
。java后端也如期的出现了the same requests
的异常信息。
到此这篇关于详解Redis如何保证接口的幂等性的文章就介绍到这了,更多相关Redis保证接口的幂等性内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!
相关文章
详解redis大幅性能提升之使用管道(PipeLine)和批量(Batch)操作
这篇文章主要介绍了详解redis大幅性能提升之使用管道(PipeLine)和批量(Batch)操作 ,具有一定的参考价值,感兴趣的小伙伴们可以参考一下。2016-12-12
最新评论