做电子委托在那个网站/网络推广公司排行榜

背景

如何防止接口中同样的数据提交，以及如何保证消息不被重复消费，这些都是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如何保证接口的幂等性》的全部内容了，觉得不错的话，记得点赞 在看 转发 关注哈，感谢您的支持。

与shigen一起，每天不一样！