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

[tool2d]

举个例子，如果有 100 万人早上 10 点同时抢货，而备货数量只有 1 万，那么注定有 99 万人的服务器抢购提交，是无效提交。

与其让 100 万个并发流入进来，造成网络阻塞，不如直接本地生成一个 100 之类伪随机数，把 90%的人，直接拒之门外。剩余 10%的幸运儿，按照固定 QPS 放进来抽奖，一直到 1 万备货，全部发完为止。

这样别说百万并发，APP 对面突发性千万并发，都能轻松应对。当然不能让那些抢不到的人看出破绽，本地模拟提交页面还是需要的，比如让人误以为正在网络提交，以免打击用户抢购积极性。

[lllllliu]

你这被查出来就要废，如果也要请求网络，那么瞬时还是会有那么多基础流量的。

[cando]

抽签买口罩
抽签买药

[hahasong]

你的想法很创新 十年前抢小米的时候就是这样干的

[terence4444]

小米之前好像就是这么搞的，前端发假请求

[tool2d]

@lllllliu 1 万备货是货真价实，这应该不算欺骗吧。

[isno]

你这聪明用到正经处，那得多有前途啊。。

[chairuosen]

你可以在网关层拦，这样就看不出来了

[wu00]

“本地生成一个 100 之类伪随机数，把 90%的人，直接拒之门外” 你这个本地应该是指客户端吧，你以为有超过 100 万人来抢，结果只有 2 万人来抢，备货一万只卖 2000 个？

[tool2d]

@wu00 90%是比例，永远有 10%的幸运儿能挤进来，不是一次性随机数，是每次伪提交前，都会生成一次。

比如有 2 万人来，那就永远有 2 千人能进池子里来，可以一直抽奖，直到把池子里的 1 万个货全部抽完。

[fcfangcc]

这不是新鲜方案了，但是比例要在后端控制。比如前端直接先随机掉 50%，然后后端网关层再随机调配置的比例，只要网关抗住就行了，真正到后端的请求量已经很少了。而且不容易呗发现

[Xyg12133617]

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

[elonmask]

之前抢华为折叠机，我都断网了，点击一下还在抢购中呢，

[garlics]

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

[sdwgyzyxy]

为什么非要做伪提交呢，网关层不要有复杂逻辑，应该很容易能支持高并发吧。

[bk201]

预约完了，直接抽备货数目的用户给予进入真实订单页面的权利，隔段时间计算剩余库存，继续抽取，直至货卖完。其他没权限的用户直接给予固定页面，太繁忙，稍后再试。

[malusama]

完全没必要前端过滤啊, 如果一开始就知道这玩意会被抢光订好了一定用户内抽, 那就是抽奖.
多少并发都不是瓶颈啊

怕的是那种. 你不知道哪个 sku 是爆款, 非爆款的你得给用户一个下单了就确定的感觉. 而不是得等一段时间, 不然人家觉得买不到就走了.

[giaodadi]

不如预约抽奖

[bequt]

放心啦，都是把 90%的流量挡在门外

[xiubin]

百度承包春晚那年 不就是这么干的么，客户端随机连请求都不发

[qaqLjj]

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