一秒内的重复请求如何处理

[twogoods]

一个接口部署了三台机器， Nginx 做负载均衡，重复请求怎么处理，上 zookeeper ， redis 吗？

[amey9270]

这是一个 csrf 的问题啊

[iMouseWu]

赞同 @phpman 观点,这个需要看业务场景。
如果是重试的重复请求,可以通过一个业务 /逻辑唯一 Id 来避免重复提交
还有一种是明显按钮已经灰显了,但是用户通过自己拼的 URL 来强行提交,就把它当做一次正常请求

[ihuotui]

@twogoods 先分析这个过程，因为网络原因，然后前端或者 app 的请求重复了，但是内容一样，所以在请求中增加一个唯一的请求码，然后后台对于记录这个用户的上一次请求码，然后对比，一样就抛弃。先分析原因，再思考解决，然后验证。

[rtx3]

请求带有状态码？能将 session 独立出去在服务器端重新取得状态吗

[rtx3]

弄错了 这个貌似要前段处理

[slixurd]

这种不都是前端控制一下就完事的事情么...
就拿创建订单来说,这个还能加锁?
一个正常的流程就是:用户在购物车点击下单,那么前端应该就把按钮置灰,发送请求,如果请求超时 /失败,就重置按钮状态允许重新下单.
没听说过要在后端做这个请求的去重的...
也没办法判断这个请求是否重复....

[ElmerZhang]

前端在给后端 POST 数据之前，先到后端请求一个 uniqid ， POST 数据时带上这个 uniqid ，后端对于 uniqid 相同的请求只处理一次。
这个机制也可以用来防跨站、防刷

[KoleHank]

前端处理下就好了， underscore 都有类似的工具类方法提供，多长时间内的只执行一次的这种

[billowqiu]

避免重复请求，貌似只能通过请求 ID 来区分了。
如果是前端的重复点击，那么就要保证前端每次传递同一个请求 ID ；
如果用户不走前端页面请求，直接发 URL 改变对应的 ID ，那么只能从后端处理，后端必须验证该 ID 是否有效。
总结：
最保险的就是请求 ID 由后端产生，后端收到请求时验证一下 ID 是否合法，是否重复。

[hobbyliu]

@ElmerZhang +1 ，我们做过一个开放平台，用户下单的流程是： 1 、请求获取订单 id 接口。 2 、带上第一步的订单 id,请求下单接口，