图片
上述代码有问题吗？谁能说有问题？一般情况下是没什么问题，但是在高并发的场景下肯定是存在问题，为什么？
因为有事务的隔离性，step1这个阶段对住院号的校验肯定是存在问题的，在高并发的场景下无法保证这里的校验一定准确。
其实这个接口的并发并不高，在码猿慢病云管理系统中一般不会出现这种问题，那么什么时候会出现呢？
医院中大部分是内网+外网，如果由于网络的抖动，系统请求响应的时间延迟，这样会导致医护操作时会出现重复点击的情况，比如1秒中之内由于第一次点添加患者这个按钮没反应，往往护士都会重复点击，这种情况下是会出现问题。
这里我们就暂且不谈对单个接口的幂等优化了，要想一个方案全局解决这个问题，在码猿慢病云管理系统中其实只要保证这种并发不高的接口在一定时间段内保证幂等即可，比如5秒之内，这样在5秒之内护士重复点击就没事。
解决方案
在码猿慢病云管理系统中新增了一个注解：@RepeatSubmit，代码如下：
图片
只需要将该注解标注在新增、修改、删除接口上就能保证在默认的5秒之内接口幂等。
比如新增住院患者这个接口：
图片
那么原理是什么？其实很简单，先来说下原理，再介绍具体的实现：
- AOP拦截增强@RepeatSubmit注解
- 获取请求的URL、IP地址、请求参数
- 将请求URL、IP地址、请求参数以一定形式转为key
- 借助Redis的setNx命令将key存入Redis，且设置失效时间
- 如果存入成功则允许访问，失败则抛出异常
- 全局异常捕获，输出指定信息给客户端
上述6个步骤中其实只有一点比较难实现的，其他的都是基本操作，就是获取这个请求参数，下面将详细介绍一下如何获取这个请求参数。
获取请求参数
对于form-data的入参只需要调用HttpServletRequest的API读取，但是对于@RequestBody标注的入参是通过IO流读取数据，且IO流只能被读取一次，如果在AOP中读取了，那么在接口层面的入参读取肯定是有问题，报错如下：
图片
解决方案也很简单，只需要保证IO流能够多次读取即可，下面就来介绍一下方案。
这里我们可以利用装饰者模式对 HttpServletRequest 的功能进行增强，具体做法也很简单，我们重新定义一个 HttpServletRequest：
图片
图片
这段代码并不难，很好懂。
首先在构造 RepeatedlyRequestWrapper 的时候，就通过 IO 流将数据读取出来并存入到一个 byte 数组中，然后重写 getReader 和 getInputStream 方法，在这两个读取 IO 流的方法中，都从 byte 数组中返回 IO 流数据出来，这样就实现了反复读取了。
接下来我们定义一个过滤器，让这个装饰后的 Request 生效：
图片
判断一下，如果请求数据类型是 JSON 的话，就把 HttpServletRequest “偷梁换柱”改为 HttpRequestWrapper，然后让过滤器继续往下走。
这样就可以配置后就可以在程序中反复读取参数了！
防重注解实现
解决了参数读取的问题，下面就可以轻松实现这个防重注解了，首先定义注解com.code.ape.codeape.common.security.annotation.RepeatSubmit:
图片
接下来直接用AOP实现，com.code.ape.codeape.common.security.component.CodeapeRepeatSubmitAspect代码如下：
图片
图片
逻辑很简单，上述已经介绍过完整的流程，这里需要注意的是参数的读取，代码如下：
图片
其实就是将request判断下是否是经过过滤器封装后的HttpRequestWrapper对象，如果是的话则是@RequestBody入参，直接从IO流中读取。
总结
本节内容介绍了防重注解@RepeatSubmit的实现原理，后续开发中只需要在非查询接口中添加这个注解就能保证在一定时间内防止重复提交。
码猿慢病云管理系统已经在星球中陆续更新，目前更新内容如下：
前言
01 项目架构+业务介绍
02 三方组件介绍
03 服务端项目部署
04 前端项目部署
05 多租户架构设计
06 医疗系统中的权限如何设计？
07 项目搭建
08 关掉验证码登录
09 开发平台自动生成业务代码
认证鉴权
01 认证登录生成token
02 token检验、鉴权
03 token有效期设置
04 刷新token
05 检查token
06 服务中如何获取当前登录用户信息？
07 接口对外暴露
08 接口只允许内部调用怎么处理？
09 如何实现token中继？
10 当前登录用户身份信息如何异步传递？
11 科室权限如何定一个注解自动注入？
12 一个注解防止接口重复提交
业务
01 科室管理
02 医院管理
03 角色管理
