这是一个创建于 722 天前的主题，其中的信息可能已经有所发展或是发生改变。
举个例子，如果有 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
qaqLjj 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