1.前端方案:
通过js将按钮绑定一个方法,点击后3s内将按钮设置成不可用,或者隐藏。
缺点:绕过前端,例如通过postman发请求。
2.hashmap版:
请求携带一个参数,将请求携带的参数(可以是用户id)存到内存的hashmap(用syc修饰)里,value存放请求时间。
当下次发送请求时,先判断map里有没有参数参数作为key。当请求时先判断map里面有没有这个key,有并且时间超过3分钟就覆盖key,没有超过三分钟就返回请求频繁。没有请求成功。
缺点:随着时间推移map越来越大,oom。
3.commons-collections 轮子
Apache 为我们提供了一个 commons-collections 的框架,里面有一个非常好用的数据结构 LRUMap
可以保存指定数量的固定的数据,并且它会按照 LRU 算法,帮你清除最不常用的数据。
java
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-collections4</artifactId>
<version>4.4</version>
</dependency>
java
// 最大容量 100 个,根据 LRU 算法淘汰数据的 Map 集合
private LRUMap<String, Integer> reqCache = new LRUMap<>(100);
@RequestMapping("/add")
public String addUser1(String id) {
// 非空判断(忽略)...
synchronized (this.getClass()) {
// 重复请求判断
if (reqCache.containsKey(id)) {
// 重复请求
System.out.println("请勿重复提交!!!" + id);
return "执行失败";
}
// 存储请求 ID
reqCache.put(id, 1);
}
// 业务代码...
System.out.println("添加用户ID:" + id);
return "执行成功!";
}
思考:当采用分布式部署,多台服务器上部署项目,用户请求时由于负载均衡、不知道请求到那台服务器上了,上面的方法就不好用了。
4.分布式锁(用在多台服务器时,上面的方法用在单台服务器)
分布式锁就是对于一个对象只能有一个线程修改(对对象修改的方法只能有一个线程调用)。
基于数据库实现、redis实现、zookeeper实现
(1)数据库实现
存方法名、线程信息(设计可重入性)、失效时间(设置定时任务清除,防止死锁)
当执行某个方法时,将方法名和线程插入,插入前先查询是不是存在,存在就返回错误。不存在就插入。
(2)redis实现
- 将方法名和参数拼接作为key,uuid作为value,并设置有效时间(防止死锁)。利用setnx(如果不存在就存进入,如果存在就什么也不做)
- 先判断redis中有没有key,如果有就是重复请求,不做处理。
- 如果redis中没有key,就不是重复请求,执行业务。执行业务后,使用lua脚本释放锁。使用lua脚本,因为lua脚本在redis中以原子形式操作,要么全做,要么全不做。避免检查锁和删除锁引发的并发错误。
(3)ZooKeeper实现分布式锁
ZooKeeper是一个为分布式应用提供一致性服务的开源组件,它内部是一个分层的文件系统目录树结构,规定同一个目录下只能有一个唯一文件名。基于ZooKeeper实现分布式锁的步骤如下:
创建一个目录mylock;
线程A想获取锁就在mylock目录下创建临时顺序节点;
获取mylock目录下所有的子节点,然后获取比自己小的兄弟节点,如果不存在,则说明当前线程顺序号最小,获得锁;
线程B获取所有节点,判断自己不是最小节点,设置监听比自己次小的节点;
线程A处理完,删除自己的节点,线程B监听到变更事件,判断自己是不是最小的节点,如果是则获得锁。
这里推荐一个Apache的开源库Curator,它是一个ZooKeeper客户端,Curator提供的InterProcessMutex是分布式锁的实现,acquire方法用于获取锁,release方法用于释放锁。
优点:具备高可用、可重入、阻塞锁特性,可解决失效死锁问题。
缺点:因为需要频繁的创建和删除节点,性能上不如Redis方式。