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

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

     于是就引出了今天要讨论的问题,如何处理重复提交的问题。
    首先看看准确的出现重复请求问题的原因(容老夫ctrl+v一段文字):

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

前台操作的抖动,快速操作,网络通信或者后端响应慢,都会增加后端重复处理的概率。

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

 但前端的限制仅能解决少部分问题,且不够彻底,后端自有的防重复处理措施必不可少,义不容辞。      嗯,啰嗦的原因交代完毕,下面来讲讲具体的solution:     我们说是基于redis缓存的处理重复请求的方式,重复请求就是在很短的时间内发送多次请求,这个时间是相当短的,以至于你进行数据库查询来验证都没法取阻挡。这样的话,我们就可以使用一个缓存的计数器来阻止这个问题的发生。在接口的开始,定义一个缓存计数器(该缓存的时间可以是几秒,几十秒或者一两分钟,能完成短时间内多个请求的这个短时间的时间就行),同一个会员的每个进来一个请求就将这个计数器+1(当然就是用会员的id+一些特定的字符串做key),对于大于1的请求不予受理。这样在这个缓存进行的时间段内就能唯一确保只有一个。嗯,具体的实现方式就是这样。(亲测有效)     下面推荐几种处理方式(基本上还是redis缓存机制最好,当然我也是主要从这里借鉴的):
    http://mogu.io/prevent-duplicate-requests-4  
  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Nginx和Redis都是在高并发场景下常用的工具。Nginx是一个高性能的Web服务器和反向代理服务器,而Redis是一个高性能的键值存储数据库。 当涉及到高并发时,Nginx可以用作负载均衡器,将请求分发给多个后端服务器,从而提高系统的吞吐量和性能。Nginx使用事件驱动的异步架构,可以处理大量并发连接,同时具有较低的资源消耗。 Redis作为一个内存数据库,具有快速读写的能力,适合处理大量的并发请求。它支持多种数据结构和丰富的功能,例如缓存、消息队列和分布式锁等,可以帮助应对高并发场景下的数据存储和处理需求。 在高并发环境中,可以通过以下几点来优化Nginx和Redis的性能: 1. Nginx: - 合理配置Nginx的工作进程数和连接数,使其适应并发请求的压力。 - 使用Nginx的缓存功能,减轻后端服务器的压力。 - 配置合适的超时时间,避免请求长时间占用连接资源。 - 使用Nginx的Gzip压缩功能,减小传输数据量,提高响应速度。 - 使用Nginx的Keepalive机制,减少TCP连接的建立和关闭开销。 2. Redis: - 合理设计数据模型,减少数据存储和检索的复杂度。 - 使用Redis集群或主从复制,提高读写性能和数据的可用性。 - 配置适当的内存策略,例如使用LRU算法来淘汰冷数据。 - 使用Redis的Pipeline和批量操作来减少网络延迟和降低通信开销。 - 避免频繁的大批量写入操作,可以通过异步或者缓存策略来优化性能。 综上所述,Nginx和Redis高并发场景下可以发挥其优势,通过合理的配置和优化可以提高系统的性能和稳定性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值