目前在做一个app的java后端开发,有这样一个需求,某一个用户的某一种数据只能够在数据库表中出现唯一一条
有这个需求的话,很简单的实现就是不用考虑太多东西,直接写好逻辑:
如果数据库中已经存在那条数据了就把它删掉,否则新插入一条数据,在service层当中就直接写了这个逻辑,贼简单,心中不经暗喜,敲完部署就不管了.
然而,过了一段时间服务器崩了(相信这是大部分菜鸟程序员都会发生的事情,有自信的代码居然会出现bug,啊啊啊泪奔怪自己年轻,对吧),关于那条数据的模块都显示不出数据,我赶快看了一下日志发现数据库中报了错,大概的意思就是数据出现了3条,可是在dao层中仅获取一条,问题来了,这多出来的数据是怎么回事?
冷静下来想一想,应该是多条请求在同一时刻内发过来的,它们同时判断出数据库当中没有数据,然后同时插入了进去,噢,原来是这个样子,那么这个问题该如何解决呢?
相信这种问题在后台端开发是非常常见的,例如在web端,要提交一个表单数据,由于服务器处理延迟,用户看不到反馈,就心急地狂按鼠标发送数据;又或者是在下单的时候不小心多按了几下鼠标,导致订单下多了几个,等等..
1.把问题扔给数据库解决
可以在建表的时候,为相关的字段设置唯一索引(也可以设置联合唯一索引),当出现重复数据的时候,自然也就插不进去了,这是保证数据安全的最可靠的方案,为保证安全,这个一定要设置
2.把问题扔给前端或者移动端解决
前端或者移动端可以在提交数据的时候加锁,例如前端提交表单数据的时候,可以用JavaScript把submit设置为disable,直到后端返回数据的时候再设置为enable,等等
3.服务器端自己解决
其实解决方案也差不多,大致就是加锁,问题出现的时候,我是直接在service层对应的方法上面直接加上synchronized,然后把重复的数据从数据库当中删掉,以解燃眉之急,但是这种方案加锁的代码太多了会降低性能,所以干脆写一个不怎么影响性能的代码,,接下来跟大伙分享一下吧!
想象一下,现在有个用户对一个按钮狂按,那么我们就对这个操作加锁
加锁的思路是这样的:当一条请求过来的时候,我们就做一个标识,标识当前用户的某一条请求正在被处理,当这个用户的其他请求进来的时候,看到有标识就对这些请求弃之不顾,然后这一条请求被处理之后,就把这个标识拿掉.
看到上面的思路,大伙肯定想到用Spring的aop去实现这个想法,那么就用aop去实现它吧!
实现想法
非常值得注意的一点是,我们现在要实现的aop是在SpringMVC,而不是直接在Spring当中,所以,按常理那样在Spring的配置文件当中配置<aop:aspectj-autoproxy />和扫描对应的aop类是行不通的,一定要在SpringMVC的配置文件当中配置这两样东西,当我们是用注解去注册标识aop类的时候,一样要这样配置<aop:aspectj-autoproxy proxy-target-class="true" />,否则会出现错误.
这个是注解类:
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface AvoidPostSameTime {
}
这个是aop类
@Aspect
@Component
public class AvoidPostSameTimeAdvice {
private static EhcacheUtil cache = EhcacheUtil.getInstance();
//与token拼接在一起组成一个叫做runningToken的东西,用来标识当前用户的所有请求
private static final String suffix = "running";
@Around("com.cppteam.ulink.comm.aop.LoggerAdvice.executePointcut() && @annotation(AvoidPostSameTime)")
public Object aroundMethod(ProceedingJoinPoint process) {
String runningToken = getRunningToken(process.getArgs());
String runningTokenValue = runningToken+String.valueOf(Thread.currentThread().getId());
try {
synchronized (this) { //这里一定要用同步,同步里面的操作都是对缓存的存储,所以对性能的影响不大
Object obj = cache.get(Project.ULINK.getValue(), runningToken);
if (obj == null) {
//把runningToken和runningTokenValue存进缓存
cache.put(Project.ULINK.getValue(),runningToken,runningTokenValue);
}
}
//在这里再判断当前线程是不是当前正在被处理的请求,如果是其他的请求.则不处理
String cacheRunningTokenValue = (String) cache.get(Project.ULINK.getValue(), runningToken);
if(cacheRunningTokenValue != null && cacheRunningTokenValue.equals(runningTokenValue))
return process.proceed();
} catch (Throwable throwable) {
throwable.printStackTrace();
return BeforeSendJson.install(BeforeSendJson.ERROR,"服务器出现错误");
}
//最后,对于其他的请求就会反馈信息,操作过于频繁
return BeforeSendJson.install(BeforeSendJson.FAIL, "操作过于频繁");
}
//无论是正常返回还是抛出了异常,都会执行
@After("com.cppteam.ulink.comm.aop.LoggerAdvice.executePointcut() && @annotation(AvoidPostSameTime)")
public void afterRun(JoinPoint point){
String runningToken = getRunningToken(point.getArgs());
String runningTokenValue = runningToken+String.valueOf(Thread.currentThread().getId());
String cacheRunningTokenValue = (String) cache.get(Project.ULINK.getValue(), runningToken);
if(cacheRunningTokenValue != null && cacheRunningTokenValue.equals(runningTokenValue)) {
//移走runningToken这一步非常关键,必须是判断是当前用户的当前可以被处理的请求才可以把它remove掉,因为afterRun方法是任何请求(包括不同用户的请求)结束都会调用,
//所以这也是runningTokenValue这样设计的原因,保证是同一个用户的其中一个请求
cache.remove(Project.ULINK.getValue(),runningToken);
}
}
private String getRunningToken(Object[] args) {
return getUserToken(args) + suffix;
}
private String getUserToken(Object[] args) {
User cachUser = (User) Arrays.asList(args).stream().filter((object) -> object instanceof User && ((User) object).getUser_token() != null).findFirst().get();
return cachUser.getUser_token();
}
}
直接说一下怎么设置这把锁吧,我们都知道app当中,用户登录之后都会有一个token,这个token对应的是某一个用户,然后可以根据这个token生成一个叫runningToken的东西标识当前用户的请求,具体是哪个线程在处理呢,所以就要以runningToken为key,runningTokenValue(runningToken与线程id拼接成的字符串)为值存进缓存当中,在aop的@After方法中remove掉runningToken的时候,一定要判断线程是不是当前用户的正在被处理的请求,如果是的话,才可以remove掉它,如果不加限制,加锁是失败的.
另外另外,写完代码一定要测试,不要盲目自信,我们可以自己模拟一个高并发,看看有没有问题发生,模拟高并发的方法很多,自己搞定吧!
