『互联网架构』软件架构-解密电商系统-秒杀安全优化与限流防刷(80)

本次主要说说秒杀系统安全相关的优化,比方说秒杀系统的地址如何的隐藏,不让别人刷我的秒杀下单的接口,加验证码,接口做一个限流。本次要说的重点。

(一)极端优化

极端情况下, 用户已经下单成功,但还没有在缓存中插入,这时库存已经为了0,返回给用户已经抢完了,但是实际上用户已经下单成功了,在订单列表中,可以看到。时间差的问题。

解决方案:如果通过redis接口的检验后,放入异步消息队列中,也就是基本放入消息队列的情况下,不出意外都可以可以下单的。后端队列慢慢处理。在加入队列增加一个排队的标记miaosha_wait_userId_productId,设置一个合理的超时时间。先看看是否有排队标记,有就继续轮训,没有查订单, 有订单返回成功,没有订单说明异常了。

  • 秒杀环境使用map,不要使用HashMap
    > 使用ConcurrentHashMap。2分钟让你懂为什么hashMap线程不安全。本身hashmap都是通过链表指针的形式来完成的。
  1. hashMap里面有2个方法hashcode和equals方法,hashmap可以无限长,它有扩容因子和每次扩大多少个,默认16个。
  2. 开始实验,比如hashmap存放的有2个格子(A,B),hashmap内部有三个元素(A格子放一个aa,B格子里面放入2个bb,cc),假定达到了它的扩容条件,变成了4个格子(A,B,C,D),扩容后重新定位发现bb,cc还是在B格子里面(A格子放一个aa,B格子放入bb、cc,C格子放入一个新的cc,D格子没有数据)。这是单线程加入一个元素没有问题。
  3. 开始多线程并发实验,A线程put第五个元素,直接放入D格子里面。B线程也对原始的put第六个元素,A在放入第五个元素的时候扩容没有完成,B也进入这个put方法里面了也进行扩容操作,A做完之后放入了第4个格子里面。但是B线程直接把cc连接到了bb上边去了,本来B线程进入后,如果放入B格子应该bb,cc后面的null,next直接没有指向null,指向了cc了,成环型了。
  4. 总结:扩容就很容易出现死循环。代码的方式,一旦使用缓存,里面涉及到的内容代码都是要增加的,但是一旦使用缓存代码的TPS和QPS都增加了。代码没有什么对不对,好不好,只有适合与否,讨论代码的时候最好针对一个特定的环境!

(二)秒杀安全

  • 地址隐藏

    地址中加入一个令牌的概念,当进入秒杀页面的时候,需要请求后端生成对应得一个token令牌(令牌token放入redis中),当下单的时候需要校验这个token是否存在如果存在才可以下单,地址的隐藏,下单校验的时候完毕后删除redis令牌。类似防止表单重复提交。

  • 地址隐藏,验证码

    分控系统控制验证码,如果验证码发生多次请求,就调用其他验证码算法。如果继续被破解,直接锁定IP。

  1. 输入完成验证码,完成校验
  2. 校验完成后,收到对应的token
  3. 拿到token直接调用秒杀接口。
  • 限流方案
  1. nginx限制请求的线程数量
  2. redis原子性的计数器。(url+userId) >10,万能的redis

PS:有老铁说你这都不是问题,在黑客面前,其实在BAT大型网站都有风控团队,风控团队就是处理紧急问题。小公司可能你感觉技术可以所有的秒杀系统的功能都完成了,但是在大公司可能一个小功能就是一个团队一起完成的。

>>原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!
>>原文链接地址:『互联网架构』软件架构-解密电商系统-秒杀安全优化与限流防刷(80)
上一篇: 下一篇:

发表评论

电子邮件地址不会被公开。 必填项已用*标注