最近在进行压力测试的时候发现在高并发下，有些接口很可能因为重复请求导致对数据库操作出来的数据不是你想要的那个样子。比如，用户签到，你只想让用户一天签到一次，为了防止签到多次，你对于每次强求，都去查询数据库今天是不是已经签到了，如果签了，就不让继续签到，如果没签到，插入签到数据，更新积分数据什么的。但是数据库操作是有时间的，在高并发下这种方式明显是不能限制重复请求提交的，有可能一个用户一天签到好几次，只要这个提交时间在很短的范围内就行（亲测确实是这样的）。
于是就引出了今天要讨论的问题，如何处理重复提交的问题。
首先看看准确的出现重复请求问题的原因（容老夫ctrl+v一段文字)：
在业务开发中，我们常会面对防止重复请求的问题。当服务端对于请求的响应涉及数据的修改，或状态的变更时，可能会造成极大的危害。重复请求的后果在交易系统、售后维权，以及支付系统中尤其严重。
前台操作的抖动，快速操作，网络通信或者后端响应慢，都会增加后端重复处理的概率。
前台操作去抖动和防快速操作的措施，我们首先会想到在前端做一层控制。当前端触发操作时，或弹出确认界面，或disable入口并倒计时等等，此处不细表。
但前端的限制仅能解决少部分问题，且不够彻底，后端自有的防重复处理措施必不可少，义不容辞。
嗯，啰嗦的原因交代完毕，下面来讲讲具体的solution：
我们说是基于redis缓存的处理重复请求的方式，重复请求就是在很短的时间内发送多次请求，这个时间是相当短的，以至于你进行数据库查询来验证都没法取阻挡。这样的话，我们就可以使用一个缓存的计数器来阻止这个问题的发生。在接口的开始，定义一个缓存计数器（该缓存的时间可以是几秒，几十秒或者一两分钟，能完成短时间内多个请求的这个短时间的时间就行），同一个会员的每个进来一个请求就将这个计数器+1（当然就是用会员的id+一些特定的字符串做key），对于大于1的请求不予受理。这样在这个缓存进行的时间段内就能唯一确保只有一个。嗯，具体的实现方式就是这样。（亲测有效）
下面推荐几种处理方式（基本上还是redis缓存机制最好，当然我也是主要从这里借鉴的）：