 |
lllllliuDec 9, 2022
1
你这被查出来就要废，如果也要请求网络，那么瞬时还是会有那么多基础流量的。
|
 |
candoDec 9, 2022
2
抽签买口罩
抽签买药 |
 |
hahasongDec 9, 2022
3
你的想法很创新 十年前抢小米的时候就是这样干的
|
 |
terence4444Dec 9, 2022 via iPhone
4
小米之前好像就是这么搞的，前端发假请求
|
 |
isnoDec 9, 2022
6
你这聪明用到正经处，那得多有前途啊。。
|
 |
chairuosenDec 9, 2022
7
你可以在网关层拦，这样就看不出来了
|
 |
8
“本地生成一个 100 之类伪随机数，把 90%的人，直接拒之门外” 你这个本地应该是指客户端吧，你以为有超过 100 万人来抢，结果只有 2 万人来抢，备货一万只卖 2000 个？
|
 |
9
@wu00 90%是比例，永远有 10%的幸运儿能挤进来，不是一次性随机数，是每次伪提交前，都会生成一次。
比如有 2 万人来，那就永远有 2 千人能进池子里来，可以一直抽奖，直到把池子里的 1 万个货全部抽完。 |
 |
10
这不是新鲜方案了，但是比例要在后端控制。比如前端直接先随机掉 50%，然后后端网关层再随机调配置的比例，只要网关抗住就行了，真正到后端的请求量已经很少了。而且不容易呗发现
|
 |
GnnbbDec 9, 2022
11
大佬们，我想问，现在的 jd ，tb ，pdd 等电商平台的抢购现在不就是这种情况嘛？
现在的抢购，要么就是前方拥堵，拥堵的。是不是就是有一部分幸运儿获得了资格呀，大家手速也都是差不多的呀。有些人的脚本也不是百分之百中啊，难道真的是拼的节点到达他们服务器的网速吗？ |
 |
12
之前抢华为折叠机，我都断网了，点击一下还在抢购中呢，
|
 |
garlicsDec 9, 2022
13
本来就是这么做的，不过这个判断是在后端。我记得之前使用抢茅台脚本的时候，作者就说明了返回 A 状态码是参与了抢购，B 状态码就是直接过滤掉的。
肯定不能放在前端，一抓包就露馅了。 |
 |
sdwgyzyxyDec 9, 2022
14
为什么非要做伪提交呢，网关层不要有复杂逻辑，应该很容易能支持高并发吧。
|
 |
bk201Dec 9, 2022
15
预约完了，直接抽备货数目的用户给予进入真实订单页面的权利，隔段时间计算剩余库存，继续抽取，直至货卖完。其他没权限的用户直接给予固定页面，太繁忙，稍后再试。
|
 |
malusamaDec 9, 2022
16
完全没必要前端过滤啊, 如果一开始就知道这玩意会被抢光订好了一定用户内抽, 那就是抽奖.
多少并发都不是瓶颈啊 怕的是那种. 你不知道哪个 sku 是爆款, 非爆款的你得给用户一个下单了就确定的感觉. 而不是得等一段时间, 不然人家觉得买不到就走了. |
 |
giaodadiDec 9, 2022
17
不如预约抽奖
|
 |
bequtDec 9, 2022
18
放心啦，都是把 90%的流量挡在门外
|
 |
19
百度承包春晚那年 不就是这么干的么，客户端随机连请求都不发
|
 |
MarkLazyDec 9, 2022
20
两个问题
1. 这个过滤的阈值最好后端配置，前端查询，因为不同的商品抢购程度不一样 2. 稍微懂点代码的人，直接绕过你前端过滤逻辑，直接给你服务器发请求，你如何识别 |
 |
JoooooooooDec 9, 2022
21
很正常的操作, 这种参加人数远远超过商品数量的都是在各个环节去丢弃流量.
前端做被人发现会有 pr 风险就拿到后端做, 这种本地随机数判断性能损耗非常小, 可以抗很大的流量. |
 |
autoxbcDec 10, 2022
22
我看到「限量抢购」都是直接关闭页面，看到支付方式「随机立减」马上换另一种支付
|
 |
fackVLDec 10, 2022 via iPhone
23
网关随机过滤一下就好
|
 |
24
恭喜你，你成功悟出来了行业内人尽皆知的秘密 😂
现在比较新的做法是在发给前端的 JWT 里，夹带用户评级，网关在 JWT 鉴权的同时判断用户等级，等级未达标的直接失败，连参与随机的机会都没有。同时也有白名单用户，只要在特定时间内，必定成功 |
 |
cnkunerDec 10, 2022 via Android
25
一般放网关随机丢弃的，前端不搞，容易被人看出来，也不安全。
|
 |
jackma0571Dec 10, 2022
26
放进来，库存怎么控制，我下单了你锁不锁库存，我超过多少时间没付款，你释不释放，那是不是一直有人在等，要等多久
|
 |
needppDec 10, 2022
27
换个思路，原价卖，随机返
|
1
Select Language