搜到了一个repo体量大体思路还是比较清晰的给他打个广告吧 https://github.com/qiurunze123/miaosha
1
melonzzz OP top
|
2
binux 2019-04-13 09:38:06 +08:00 via Android
把名额分配给自己,前段直接 setTimout ("已售销")
|
3
whileFalse 2019-04-13 09:45:11 +08:00 4
让大部分用户的请求到不了数据层。
一是学小米,在页面 js 做手脚,开始秒杀后让大部分人直接结束,不需要发送请求到后端。 二是请求到了后端 web 层之后,在进入 app 层排队之前就随机丢弃一部分,剩下的再要不是进队列啊要不直接走 DB 都行了。 如果做得精细点,还可以使用在线统计的方式,秒杀开始前一分钟拿到在线数量,计算出页面和 web 层丢弃的比例,传给页面或 web 层。确保 web 层和 app 层不被压垮。 |
4
whileFalse 2019-04-13 09:49:40 +08:00
如果说页面连个请求都不发就直接结束太 tm 假了,那好办,web 端按某种方式随机到 100 个后端 api 地址上;其中只有 10 个是真的 api,另外的 90 个都返回静态的“秒杀未开始或已经售罄”即可🐶
|
5
dongisking 2019-04-13 09:58:37 +08:00 via Android
超卖超买,锁这些吧
|
6
Dounx 2019-04-13 09:59:42 +08:00 via Android
redis 缓存?
|
7
supuwoerc 2019-04-13 10:00:31 +08:00
"需要很大一部分的前端屠宰" =。=
|
8
uyhyygyug1234 2019-04-13 10:03:20 +08:00
那感觉不是秒杀,是在抽奖啊
|
9
guyujiezi 2019-04-13 10:12:42 +08:00
把 90%的请求拦截在前端
|
10
luozic 2019-04-13 10:21:38 +08:00
層層削峰。隔離部署,容量規劃和熔斷要搞好。 --- 高可用
防止黃牛 刷票的要搞好,其他的都是細節。--- 安全 |
11
pathbox 2019-04-13 11:01:16 +08:00 via iPhone
用尽可能少的机器来做 本身就是错误的方向
|
12
cxtrinityy 2019-04-13 11:07:02 +08:00 via Android
前端屠杀这个过分了,这特么感情不是比手速网速,是比幸运值么
|
13
carlclone 2019-04-13 11:09:41 +08:00
缓存,队列,分布式...数据库分片...超买超卖优化方案..
|
14
melonzzz OP @whileFalse 要考虑的地方着实很多 上次看到过一篇秒杀设计写的很透彻,忘了收藏
|
15
murmur 2019-04-13 11:12:50 +08:00
直接前端随机返回失败,或者后端恒定 error,我相信个大互联网公司的举报系统都是这么设计的
|
17
lhx2008 2019-04-13 11:13:25 +08:00 via Android
如果要公平,用中间件硬抗也可以的,前端先发请求申请一个指标,最快的拿到指标,其他放掉。
但是还是抽奖比较简单 |
19
lhx2008 2019-04-13 11:16:33 +08:00
像小米的话,放指标用的别的队列,几分钟后推回来,这样用户体验比较差,不过成本比较低,也可以兼顾到后面支付和减库存的压力。
|
20
lhx2008 2019-04-13 11:17:25 +08:00
淘宝的就比较狠,因为时时刻刻都在秒杀,所以根本没什么策略,也可能是我还没到那个水平
|
21
death00 2019-04-13 11:22:57 +08:00
长知识了,原来秒杀还有抽奖一说
|
25
Fitz 2019-04-13 13:01:18 +08:00
这 小米真的是在前端就给判死刑了吗?
|
26
Emmanuel1989 2019-04-14 22:31:17 +08:00
@lhx2008 小米确实是真的无良,欺骗你在排队,浪费感情,白白等半天。还不如直接 fail fast 来的痛快。
|
27
usingnamespace 2019-04-15 00:43:47 +08:00 via iPhone
java 的没意思。。。
|
28
tonghuashuai 2019-04-19 19:15:59 +08:00
秒杀其实就是个抽奖,大部分的请求被 js 拦截了,根本到不了后端
|