利用redis缓存解决高并发下后端重复请求措施

 最近在进行压力测试的时候发如今高并发下，有些接口极可能由于重复请求致使对数据库操做出来的数据不是你想要的那个样子。好比，用户签到，你只想让用户一天签到一次，为了防止签到屡次，你对于每次强求，都去查询数据库今天是否是已经签到了，若是签了，就不让继续签到，若是没签到，插入签到数据，更新积分数据什么的。可是数据库操做是有时间的，在高并发下这种方式明显是不能限制重复请求提交的，有可能一个用户一天签到好几回，只要这个提交时间在很短的范围内就行（亲测确实是这样的）。

     因而就引出了今天要讨论的问题，如何处理重复提交的问题。
    首先看看准确的出现重复请求问题的缘由（容老夫ctrl+v一段文字)：

     在业务开发中，咱们常会面对防止重复请求的问题。当服务端对于请求的响应涉及数据的修改，或状态的变动时，可能会形成极大的危害。重复请求的后果在交易系统、售后维权，以及支付系统中尤为严重。

前台操做的抖动，快速操做，网络通讯或者后端响应慢，都会增长后端重复处理的几率。

 前台操做去抖动和防快速操做的措施，咱们首先会想到在前端作一层控制。当前端触发操做时，或弹出确认界面，或disable入口并倒计时等等，此处不细表。

 但前端的限制仅能解决少部分问题，且不够完全，后端自有的防重复处理措施必不可少，责无旁贷。

  嗯，啰嗦的缘由交代完毕，下面来说讲具体的solution：

  咱们说是基于redis缓存的处理重复请求的方式，重复请求就是在很短的时间内发送屡次请求，这个时间是至关短的，以致于你进行数据库查询来验证都无法取阻挡。这样的话，咱们就可使用一个缓存的计数器来阻止这个问题的发生。在接口的开始，定义一个缓存计数器（该缓存的时间能够是几秒，几十秒或者一两分钟，能完成短期内多个请求的这个短期的时间就行），同一个会员的每一个进来一个请求就将这个计数器+1（固然就是用会员的id+一些特定的字符串作key），对于大于1的请求不予受理。这样在这个缓存进行的时间段内就能惟一确保只有一个。嗯，具体的实现方式就是这样。（亲测有效）

  下面推荐几种处理方式（基本上仍是redis缓存机制最好，固然我也是主要从这里借鉴的）：