这是一个创建于 1041 天前的主题，其中的信息可能已经有所发展或是发生改变。
举个例子，如果有 100 万人早上 10 点同时抢货，而备货数量只有 1 万，那么注定有 99 万人的服务器抢购提交，是无效提交。
与其让 100 万个并发流入进来，造成网络阻塞，不如直接本地生成一个 100 之类伪随机数，把 90%的人，直接拒之门外。剩余 10%的幸运儿，按照固定 QPS 放进来抽奖，一直到 1 万备货，全部发完为止。
这样别说百万并发，APP 对面突发性千万并发，都能轻松应对。当然不能让那些抢不到的人看出破绽，本地模拟提交页面还是需要的，比如让人误以为正在网络提交，以免打击用户抢购积极性。
与其让 100 万个并发流入进来，造成网络阻塞，不如直接本地生成一个 100 之类伪随机数，把 90%的人，直接拒之门外。剩余 10%的幸运儿，按照固定 QPS 放进来抽奖，一直到 1 万备货，全部发完为止。
这样别说百万并发，APP 对面突发性千万并发，都能轻松应对。当然不能让那些抢不到的人看出破绽，本地模拟提交页面还是需要的，比如让人误以为正在网络提交，以免打击用户抢购积极性。
 | 1 lllllliu 2022-12-09 16:10:55 +08:00 你这被查出来就要废，如果也要请求网络，那么瞬时还是会有那么多基础流量的。 |
 | 2 cando 2022-12-09 16:11:22 +08:00 抽签买口罩 抽签买药 |
 | 3 hahasong 2022-12-09 16:11:35 +08:00 你的想法很创新 十年前抢小米的时候就是这样干的 |
 | 4 terence4444 2022-12-09 16:12:24 +08:00 via iPhone 小米之前好像就是这么搞的，前端发假请求 |
 | 6 isno 2022-12-09 16:14:50 +08:00 你这聪明用到正经处，那得多有前途啊。。 |
 | 7 chairuosen 2022-12-09 16:17:11 +08:00 你可以在网关层拦，这样就看不出来了 |
 | 8 wu00 2022-12-09 16:17:17 +08:00  1 “本地生成一个 100 之类伪随机数，把 90%的人，直接拒之门外” 你这个本地应该是指客户端吧，你以为有超过 100 万人来抢，结果只有 2 万人来抢，备货一万只卖 2000 个？ |
 | 9 tool2d OP @wu00 90%是比例，永远有 10%的幸运儿能挤进来，不是一次性随机数，是每次伪提交前，都会生成一次。 比如有 2 万人来，那就永远有 2 千人能进池子里来，可以一直抽奖，直到把池子里的 1 万个货全部抽完。 |
 | 10 fcfangcc 2022-12-09 16:22:22 +08:00 2 这不是新鲜方案了，但是比例要在后端控制。比如前端直接先随机掉 50%，然后后端网关层再随机调配置的比例，只要网关抗住就行了，真正到后端的请求量已经很少了。而且不容易呗发现 |
 | 11 Xyg12133617 2022-12-09 16:37:36 +08:00 大佬们，我想问，现在的 jd ，tb ，pdd 等电商平台的抢购现在不就是这种情况嘛？ 现在的抢购，要么就是前方拥堵，拥堵的。是不是就是有一部分幸运儿获得了资格呀，大家手速也都是差不多的呀。有些人的脚本也不是百分之百中啊，难道真的是拼的节点到达他们服务器的网速吗？ |
 | 12 elonmask 2022-12-09 17:02:40 +08:00 1 之前抢华为折叠机，我都断网了，点击一下还在抢购中呢， |
 | 13 garlics 2022-12-09 17:10:37 +08:00 本来就是这么做的，不过这个判断是在后端。我记得之前使用抢茅台脚本的时候，作者就说明了返回 A 状态码是参与了抢购，B 状态码就是直接过滤掉的。 肯定不能放在前端，一抓包就露馅了。 |
 | 14 sdwgyzyxy 2022-12-09 17:27:53 +08:00 为什么非要做伪提交呢，网关层不要有复杂逻辑，应该很容易能支持高并发吧。 |
 | 15 bk201 2022-12-09 17:46:40 +08:00 预约完了，直接抽备货数目的用户给予进入真实订单页面的权利，隔段时间计算剩余库存，继续抽取，直至货卖完。其他没权限的用户直接给予固定页面，太繁忙，稍后再试。 |
 | 16 malusama 2022-12-09 18:46:43 +08:00 完全没必要前端过滤啊, 如果一开始就知道这玩意会被抢光订好了一定用户内抽, 那就是抽奖. 多少并发都不是瓶颈啊 怕的是那种. 你不知道哪个 sku 是爆款, 非爆款的你得给用户一个下单了就确定的感觉. 而不是得等一段时间, 不然人家觉得买不到就走了. |
 | 17 giaodadi 2022-12-09 20:46:47 +08:00 不如预约抽奖 |
 | 18 bequt 2022-12-09 20:55:43 +08:00 放心啦，都是把 90%的流量挡在门外 |
 | 19 xiubin 2022-12-09 21:31:19 +08:00 1 百度承包春晚那年 不就是这么干的么，客户端随机连请求都不发 |
 | 20 MarkLazy 2022-12-09 23:46:30 +08:00 两个问题 1. 这个过滤的阈值最好后端配置，前端查询，因为不同的商品抢购程度不一样 2. 稍微懂点代码的人，直接绕过你前端过滤逻辑，直接给你服务器发请求，你如何识别 |
 | 21 Jooooooooo 2022-12-09 23:50:26 +08:00 很正常的操作, 这种参加人数远远超过商品数量的都是在各个环节去丢弃流量. 前端做被人发现会有 pr 风险就拿到后端做, 这种本地随机数判断性能损耗非常小, 可以抗很大的流量. |
 | 22 autoxbc 2022-12-10 01:43:57 +08:00 我看到「限量抢购」都是直接关闭页面，看到支付方式「随机立减」马上换另一种支付 |
 | 23 fackVL 2022-12-10 04:03:53 +08:00 via iPhone 网关随机过滤一下就好 |
 | 24 eason1874 2022-12-10 04:59:01 +08:00 5 恭喜你，你成功悟出来了行业内人尽皆知的秘密 现在比较新的做法是在发给前端的 JWT 里，夹带用户评级，网关在 JWT 鉴权的同时判断用户等级，等级未达标的直接失败，连参与随机的机会都没有。同时也有白名单用户，只要在特定时间内，必定成功 |
 | 25 cnkuner 2022-12-10 08:51:51 +08:00 via Android 一般放网关随机丢弃的，前端不搞，容易被人看出来，也不安全。 |
 | 26 jackma0571 2022-12-10 11:02:30 +08:00 放进来，库存怎么控制，我下单了你锁不锁库存，我超过多少时间没付款，你释不释放，那是不是一直有人在等，要等多久 |
 | 27 needpp 2022-12-10 12:21:44 +08:00 换个思路，原价卖，随机返 |
Select Language