同时防服务器维修,服务器端如何防止在同一时刻接收多个请求?

目前在做一个app的java后端开发,有这样一个需求,某一个用户的某一种数据只能够在数据库表中出现唯一一条

有这个需求的话,很简单的实现就是不用考虑太多东西,直接写好逻辑:

如果数据库中已经存在那条数据了就把它删掉,否则新插入一条数据,在service层当中就直接写了这个逻辑,贼简单,心中不经暗喜,敲完部署就不管了.

然而,过了一段时间服务器崩了(相信这是大部分菜鸟程序员都会发生的事情,有自信的代码居然会出现bug,啊啊啊泪奔怪自己年轻,对吧),关于那条数据的模块都显示不出数据,我赶快看了一下日志发现数据库中报了错,大概的意思就是数据出现了3条,可是在dao层中仅获取一条,问题来了,这多出来的数据是怎么回事?

冷静下来想一想,应该是多条请求在同一时刻内发过来的,它们同时判断出数据库当中没有数据,然后同时插入了进去,噢,原来是这个样子,那么这个问题该如何解决呢?

相信这种问题在后台端开发是非常常见的,例如在web端,要提交一个表单数据,由于服务器处理延迟,用户看不到反馈,就心急地狂按鼠标发送数据;又或者是在下单的时候不小心多按了几下鼠标,导致订单下多了几个,等等..

1.把问题扔给数据库解决

可以在建表的时候,为相关的字段设置唯一索引(也可以设置联合唯一索引),当出现重复数据的时候,自然也就插不进去了,这是保证数据安全的最可靠的方案,为保证安全,这个一定要设置

2.把问题扔给前端或者移动端解决

前端或者移动端可以在提交数据的时候加锁,例如前端提交表单数据的时候,可以用JavaScript把submit设置为disable,直到后端返回数据的时候再设置为enable,等等

3.服务器端自己解决

其实解决方案也差不多,大致就是加锁,问题出现的时候,我是直接在service层对应的方法上面直接加上synchronized,然后把重复的数据从数据库当中删掉,以解燃眉之急,但是这种方案加锁的代码太多了会降低性能,所以干脆写一个不怎么影响性能的代码,,接下来跟大伙分享一下吧!

想象一下,现在有个用户对一个按钮狂按,那么我们就对这个操作加锁

加锁的思路是这样的:当一条请求过来的时候,我们就做一个标识,标识当前用户的某一条请求正在被处理,当这个用户的其他请求进来的时候,看到有标识就对这些请求弃之不顾,然后这一条请求被处理之后,就把这个标识拿掉.

看到上面的思路,大伙肯定想到用Spring的aop去实现这个想法,那么就用aop去实现它吧!

实现想法

非常值得注意的一点是,我们现在要实现的aop是在SpringMVC,而不是直接在Spring当中,所以,按常理那样在Spring的配置文件当中配置和扫描对应的aop类是行不通的,一定要在SpringMVC的配置文件当中配置这两样东西,当我们是用注解去注册标识aop类的时候,一样要这样配置,否则会出现错误.

这个是注解类:

@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掉它,如果不加限制,加锁是失败的.

另外另外,写完代码一定要测试,不要盲目自信,我们可以自己模拟一个高并发,看看有没有问题发生,模拟高并发的方法很多,自己搞定吧!