Java 后台防重复提交一般怎么做的？

• 資深大佬 : wysnylc

  这就是幂等

• 資深大佬 : gz911122

  订单号唯一主键不就天然防重复了…

• 資深大佬 : shenlanAZ

  前端：
  锁住按钮 等请求返回之后再对按钮解锁。

  后端:
  差不多也是用锁的思路 无非就是锁的粒度，可以锁业务，也可以锁订单。看业务需求。

• 資深大佬 : beryl

  关键词：防重入

• 資深大佬 : luckyrayyy

  主键的话你插入不进去啊。

• 資深大佬 : tabris17

  每次提交都包含一个业务 ID，重复 ID 的请求丢弃

• 資深大佬 : oneisall8955

  摘抄网上的幂等解决办法
  1.实现幂等性常见的方式有：悲观锁（ for update ）、乐观锁、唯一约束
  2.几种方式，按照最优排序：乐观锁 > 唯一约束 > 悲观锁

• 資深大佬 : hantsy

  cxrf 。。。设置 Http Header，或者 Http Form 。

  传统框架大部分自带 Form 重复提交了。

• 資深大佬 : lhx2008

  最简单的方法可以依赖数据库的唯一键，复杂一点就是请求带 token+redis 黑名单

• 資深大佬 : hantsy

  修正：cxrf –> csrf 或者叫 xsrf

• 資深大佬 : jinzhongyuan

  @gz911122 主的意思应该是，指定时间内方法参数一样的请求无法进入方法或者 controller

• 主 資深大佬 : luxinfl

  @jinzhongyuan 不是不是，我就是说两笔相同参数同时提交的问题。。有时候会碰到前台没做防重点按钮点了好多次。

• 主 資深大佬 : luxinfl

  @lhx2008 放在 redis 是不是快一点。因为他这个重复提交也就那么一小会，人手动点的。。感觉用不到数据库

• 資深大佬 : gz911122

  @luxinfl
  那你都加了唯一索引了 点 100 次又何妨

• 資深大佬 : doudouwu

  #14 @ gz911122 唯一索引的是订单号，提交的是不包含的订单号，待生成订单号的数据呢
  主说的场景很可能存在

• 資深大佬 : kanepan19

  csrf +1

• 資深大佬 : gz911122

  @doudouwu
  订单号肯定是预先生成好的…
  会有生成器之类的负责,

  而且他说了是相同参数.

• 資深大佬 : dayformyjob

  threadlocal + 信号量 重入锁，每个线程只能提交一次—-单机版情况。
  分布式 多机器，就引入中间件–redis 或者 jms 之类的

• 資深大佬 : royan

  csrf+1

• 資深大佬 : kiracyan

  预先生成 token 然后设置过期时间 提交成功后删除 不存在的不让提交

• 資深大佬 : DJQTDJ

  订单号不是自增的吗

• 資深大佬 : wizzer

  年月日时分秒+redis incr N 位自增长

• 資深大佬 : pinktu

  让前端写，哪边简单哪边做

• 資深大佬 : wizzer

  “`
  public synchronized String getNewOrderId() {
  String date = DateUtil.format(new Date(), “yyMMddHHmm”);
  long ttl = redisService.ttl(RedisConstant.REDIS_KEY_ORDER_ID + date);
  long id = 0;
  if (ttl <= 0) {
  id = redisService.incr(RedisConstant.REDIS_KEY_ORDER_ID + date);
  redisService.expire(RedisConstant.REDIS_KEY_ORDER_ID + date, 80);
  } else {
  id = redisService.incr(RedisConstant.REDIS_KEY_ORDER_ID + date);
  }
  return date + Strings.alignRight(id, 6, ‘0’);
  }
  “`

• 資深大佬 : jinzhongyuan

  @luxinfl 额，不是我说的这回事吗？

• 資深大佬 : zh841318441

  后端做幂等性
  一般是基于数据库方面建立唯一索引或者联合索引
  基于 redis 也可以，生成订单唯一号存储在 redis 里面，保存的时候先从 reids 取，如果 reids 里面有，存储并删除。如果没有则不保存,但是这种并发情况下要考虑一下锁。
  基于 token 也可以,实现情况和 redis 那种差不多.

  前端：做放重复点击，点击过后没返回结果，不能重复点击.

• 主 資深大佬 : luxinfl

  @jinzhongyuan 就是两条完全一模一样的请求，同时进到后台了。后台要怎么处理。就这么个意思

• 主 資深大佬 : luxinfl

  @zh841318441 这个 token 就是上面大佬说的那种 csrf 嘛？

• 主 資深大佬 : luxinfl

  @hantsy 这个前端是不是只要加个隐藏的表单字段就行了。数据什么的后台生成再校验？

• 資深大佬 : Veneris

  redis 的 setnx，key 是 业务+业务 id+用户 id，set 成功则执行业务并 delete key，否则直接 return

• 資深大佬 : MiBAO

  @pinktu 思路不对呀，还是得讲究一个双向验证。

• 資深大佬 : youxiachai

  lz 是听不懂幂等是干嘛的….前面那么多人都给出标准答案了…
  为啥还要前端参与….

• 資深大佬 : no1xsyzy

  你试试看 v2 在一个主题里写点东西，然后切其他标签页访问个十几分钟在其他主题下做点回复，再回到这个主题的时候点回复，会失败一次，变成一个只有回复内容的网页，需要重新点一次回复。
  这个就是 CSRF，每次请求主题页面就请求一个 CSRF token，包含在 input[type=”hidden”][name=”once”] 里，过了有效期再发送请求的话，这个请求就会失效。

• 主 資深大佬 : luxinfl

  @no1xsyzy 现在是不是都流行这样搞？反正我们前台没要求我们生成个 token 给他们。。而且小公司，以前写页面的时候都是我们自己写的，也没考虑过这个。用的最多的就是 disabled

• 資深大佬 : hantsy

  @luxinfl CSRF 只对当前请求有效。重复提交后的第二次的同样的 CSRF Code 到后端是无法通过验证的。

  一般传统 Web 框架都是隐藏字段，比如 JSF, Jakarta MVC 等，这些框架都是会自己有较验机制，不用手动代码检测。

  https://github.com/hantsy/jakartaee-mvc-sample/blob/master/src/main/webapp/WEB-INF/views/add.xhtml#L13-L15

  https://github.com/hantsy/jakartaee-mvc-sample/blob/master/src/main/java/com/example/web/TaskController.java#L89

  Spring Security 也支持 Csrf，可以用于表单验证（使用 Themleaf 等），或者 Http Header （用于 API ）。Spring 官方教程与 Angular 结合的 Microservice 例子，https://spring.io/guides/tutorials/spring-security-and-angular-js/

• 主 資深大佬 : luxinfl

  @no1xsyzy 刚才回复你的时候就碰到你说的这个情况了，跳到了一个回复页面。。是因为我改了标签属性么，加了 disabled 么。。。
• 資深大佬 : hantsy

  @luxinfl 不可能由前台，都是后台生成的。Spring Security 会默认加到 Header 上去的。

• 資深大佬 : hantsy

  Spring 官方那个例子，以前用的 Angularjs，现在换成 Angular （ 2+）了。之前 Angularjs 中 CSRF 的名字是 XSRF，Spring Security 叫 csrf, 不一致还需要转换。 现在 Angular 不用了。

• 資深大佬 : hecz

  @shenlanAZ 幂等跟锁不是一个东西。。。。

• 資深大佬 : wj5868386

  两种处理方法，后端处理，前端处理完全能绕过去的，业务层 数据库层
  业务层：建立提交规则，符合规则的放行，不符合的丢弃。
  数据层：锁，唯一约束。
  业务层其实也就是锁的思路。

• 資深大佬 : SashaMu

  redis +1

• 資深大佬 : DanielGuo

  插入之前判重，这叫幂等——你那个订单号可能不太够，最好是由前端传入一个值作 referenceId，前端连续的重复请求都是同一 referenceId 。插入时判断数据库中有没有此 referenceId，有的话就重复，不允许插入。
  防止并发插入——仅仅做了幂等也不够，若并发时也能重复插入成功。这时要做并发控制，可以在数据库层面将 referenceId 这个字段设置成唯一，由数据库阻止并发；也可以 单机的话直接 java 锁，分布式用 redis （不推荐，因为坑多）或 zookeeper 做分布式锁

• 資深大佬 : qloog

  简单点用 redis 的 set nx px 作为分布式锁来做频率控制进行处理。

• 資深大佬 : luzhh

  我之前写过一个通用的框架来保证接口的幂等性，你这个问题我讲一下大概的思路：
  首先下单接口有若干个参数，n 次接口请求某几个参数值如果一样，那么认为是重复请求，那么把这几个参数拿出来组成一个在业务中可以是认为唯一的一个字符串，然后用 FutureTask 构造一个下单任务，将上面的唯一 key 和 task 保存在一个 map 中，每次请求接口时，先生成 ke 到 map 中看 value 存在不，如果存在那等待 task 的返回结果就行，如果不存在那就保存 task 到 map 中并调用 task.run 执行后续的下单业务逻辑。
  这样若干个相同请求进来了只会处理一次。
  上面是针对单个项目的情况，如果是集群部署的话 task 怎么保存和后面重复请求过来了怎么拿到请求结果，相应的用其他中间件改一下应该可以的。

• 主 資深大佬 : luxinfl

  @luzhh 这个 FutureTask 不是线程的那个吧。。。

• 資深大佬 : pinkrab

  这是一个幂等性问题，一般的处理方式有：
  数据库的唯一约束，这个最简单了，但是需要看业务场景。
  使用 token：提交数据的时候验证 token，一旦提交成功清除，下次来提交必会失败
  状态机幂等：一个数据在整个生命周期中所经历的状态，每次进行状态校验。

• 資深大佬 : mmdsun

  网关加的过滤。同一个用户，同一个接口在 1 秒内点击了两次。就过滤掉。

• 資深大佬 : opengps

  提交时候就加 requestid，同一个 requestid 都返回同一个结果

• 資深大佬 : luzhh

  @luxinfl 就是线程相关的，通过这个可以等待并获取线程的执行结果。多个重复请求进来只有一个下单任务在执行，后续的请求直接等待结果即可。

• 資深大佬 : spicecch

  赞成 3 的，这个前端来判断比较方便，服务器没有返回重复提交就给他弹窗，这个前端可以判断出来的，可以去看下 xhr 的状态

• 資深大佬 : Returnear

  @Veneris 对的，严谨一点加个 3 秒过期

• 資深大佬 : yukiloh

  不需要改代码,让用户学会”风怒了,编辑”…

• 資深大佬 : gaius

• 資深大佬 : freebird1994

  分布式锁

• 資深大佬 : Vegetable

  后端只要做一部分就行了.

  我把所有非幂等操作 md5(body+token)用 redis 做了缓存,ttl 5 秒,重复值丢弃.建立在误点操作两次请求内容完全相同的前提下能正常工作.

• 資深大佬 : xcstream

  放在 redis 里 key 就是页面生成时随机一个 id

• 資深大佬 : pinktu

  @MiBAO 好吧！以前公司重复提交都是让我加按钮设置

• 資深大佬 : wupher

  不清楚你的使用场景。

  如果是业务类型，比如 A 用做 xx 操作时，禁止 A 用户同时做 xx 操作。比如不允许同时发两个密码不同的改密码请求。类似这种，比如商家转账，此时考虑用分布式锁，用数据库、Redis 、ZooKeeper 、ETCD 看你喜好和资源了。

  如果是类似安全类型的，比如重放攻击。可以通过对 Nonce 串进行 Hash 校验，对于重复的请求进行识别与过滤，及至屏蔽转移攻击。

• 資深大佬 : MiBAO

  @pinktu 哈哈 我们公司不知道还好 被知道了就会和你强调这种东西一定要双向验证

• 資深大佬 : guoyuchuan

  百度一下不就知道了吗

• 資深大佬 : Wuxj

  跳转到下单页的时候，将一些唯一性参数先传到后端生成唯一性 requestId，通过后端跳转到下单页，将生成的 requestId 放隐藏字段。提交订单的时候，根据 requestId 生成分布式锁。刚毕业那会做的，好像也没啥问题~仅供参考

• 資深大佬 : TomatoYuyuko

  扔前端做啊，哪有前端不做设置的

• 資深大佬 : sola97

  虽然我不懂，但前端处理防不了各种爬虫、脚本、秒杀软件吧

• 資深大佬 : zhupeng163

  定义一个环绕增强的切面，切需要防重提交的 controller 甚至所有 controller，类名+方法名+所有参数拼接起来作为 key，用 redis setNx，给一个失效时间，setNx 返回 false 则抛重复提交异常。

• 資深大佬 : 1107139144

  请求加锁

• 資深大佬 : wanguorui123

  用户锁+业务判断

• 資深大佬 : pythonee

  csrf+1
  不过数据库的设计也有必要

• 資深大佬 : pythonee

  @guoyuchuan 尽量避免百度哦

• 資深大佬 : guoyuchuan

  @pythonee #68
  那就谷歌

• 資深大佬 : ningyu1

  csrf+1

• 資深大佬 : ningyu1

  csrf 能控制一部分重复提交（同一个页面多次点击 button 提交）， 另外一部分是相同的业务参数重复提交（刷新页面获取新的 csrftoken 但是提交请求的其他参数不变，多用在录制回放），这个还要配合后端的幂等控制，做法有很多，可以排序后 md5 放到 redis 中去验证是否存在，也可以使用临时表控制幂等。

• 資深大佬 : BlackBerry999

  前端做防抖节流

• 資深大佬 : wc951

  前端是为了用户体验，后端是为了业务安全，都要做防重放的

• 資深大佬 : reeco

  分布式悲观锁