由某东抢购商品，联想到一个解决服务器大并发的方法。

16个回复

• 

  lllllliu 会员

  2022年12月9日 08:14
  你这被查出来就要废，如果也要请求网络，那么瞬时还是会有那么多基础流量的。
  0 0
  评论

• 

  cando 会员

  2022年12月9日 08:14
  抽签买口罩 抽签买药
  0 0
  评论

• 

  hahasong 会员

  2022年12月9日 08:14
  你的想法很创新 十年前抢小米的时候就是这样干的
  0 0
  评论

• 

  terence4444 会员

  2022年12月9日 08:14
  小米之前好像就是这么搞的，前端发假请求
  0 0
  评论

• 

  Xyg12133617 会员

  2022年12月9日 09:14
  大佬们，我想问，现在的 jd ，tb ，pdd 等电商平台的抢购现在不就是这种情况嘛？ 现在的抢购，要么就是前方拥堵，拥堵的。是不是就是有一部分幸运儿获得了资格呀，大家手速也都是差不多的呀。有些人的脚本也不是百分之百中啊，难道真的是拼的节点到达他们服务器的网速吗？
  0 0
  评论

• 

  elonmask 会员

  2022年12月9日 09:14
  之前抢华为折叠机，我都断网了，点击一下还在抢购中呢，
  0 0
  评论

• 

  garlics 会员

  2022年12月9日 09:14
  本来就是这么做的，不过这个判断是在后端。我记得之前使用抢茅台脚本的时候，作者就说明了返回 A 状态码是参与了抢购，B 状态码就是直接过滤掉的。 肯定不能放在前端，一抓包就露馅了。
  0 0
  评论

• 

  giaodadi 会员

  2022年12月9日 13:16
  不如预约抽奖
  0 0
  评论

• 

  bequt 会员

  2022年12月9日 13:16
  放心啦，都是把 90%的流量挡在门外
  0 0
  评论

• 

  xiubin 会员

  2022年12月9日 13:45
  百度承包春晚那年 不就是这么干的么，客户端随机连请求都不发
  0 0
  评论

• 

  qaqLjj 会员

  2022年12月9日 16:15
  两个问题 1. 这个过滤的阈值最好后端配置，前端查询，因为不同的商品抢购程度不一样 2. 稍微懂点代码的人，直接绕过你前端过滤逻辑，直接给你服务器发请求，你如何识别
  0 0
  评论

• 

  Jooooooooo 会员

  2022年12月9日 16:15
  很正常的操作, 这种参加人数远远超过商品数量的都是在各个环节去丢弃流量. 前端做被人发现会有 pr 风险就拿到后端做, 这种本地随机数判断性能损耗非常小, 可以抗很大的流量.
  0 0
  评论

• 

  autoxbc 会员

  2022年12月9日 18:15
  我看到「限量抢购」都是直接关闭页面，看到支付方式「随机立减」马上换另一种支付
  0 0
  评论

• 

  fackVL 会员

  2022年12月9日 20:14
  网关随机过滤一下就好
  0 0
  评论

• 

  eason1874 会员

  2022年12月9日 21:14
  恭喜你，你成功悟出来了行业内人尽皆知的秘密 😂 现在比较新的做法是在发给前端的 JWT 里，夹带用户评级，网关在 JWT 鉴权的同时判断用户等级，等级未达标的直接失败，连参与随机的机会都没有。同时也有白名单用户，只要在特定时间内，必定成功
  0 0
  评论

• 

  cnkuner 会员

  2022年12月10日 01:16
  一般放网关随机丢弃的，前端不搞，容易被人看出来，也不安全。
  0 0
  评论