用尽可能少的机器来做一次秒杀活动?主要是问需要怎么设计
只说了限流,削峰,CDN 缓存,还有什么需要考虑的嘛
只说了限流,削峰,CDN 缓存,还有什么需要考虑的嘛
This topic created in 2761 days ago, the information mentioned may be changed or developed.
Supplement 1 · Apr 13, 2019
搜到了一个repo体量大体思路还是比较清晰的给他打个广告吧 https://github.com/qiurunze123/miaosha
 |
1
top
|
 |
binuxApr 13, 2019 via Android
2
把名额分配给自己，前段直接 setTimout ("已售销")
|
 |
3
让大部分用户的请求到不了数据层。
一是学小米，在页面 js 做手脚，开始秒杀后让大部分人直接结束，不需要发送请求到后端。 二是请求到了后端 web 层之后，在进入 app 层排队之前就随机丢弃一部分，剩下的再要不是进队列啊要不直接走 DB 都行了。 如果做得精细点，还可以使用在线统计的方式，秒杀开始前一分钟拿到在线数量，计算出页面和 web 层丢弃的比例，传给页面或 web 层。确保 web 层和 app 层不被压垮。 |
4 |
whileFalseApr 13, 2019
4
如果说页面连个请求都不发就直接结束太 tm 假了，那好办，web 端按某种方式随机到 100 个后端 api 地址上；其中只有 10 个是真的 api，另外的 90 个都返回静态的“秒杀未开始或已经售罄”即可🐶
|
 |
dongiskingApr 13, 2019 via Android
5
超卖超买，锁这些吧
|
 |
DounxApr 13, 2019 via Android
6
redis 缓存？
|
 |
supuwoercApr 13, 2019
7
"需要很大一部分的前端屠宰" =。=
|
 |
uyhyygyug1234Apr 13, 2019
8
那感觉不是秒杀，是在抽奖啊
|
 |
guyujieziApr 13, 2019
9
把 90%的请求拦截在前端
|
 |
luozicApr 13, 2019
10
層層削峰。隔離部署，容量規劃和熔斷要搞好。 --- 高可用
防止黃牛 刷票的要搞好，其他的都是細節。--- 安全 |
 |
pathboxApr 13, 2019 via iPhone
11
用尽可能少的机器来做 本身就是错误的方向
|
 |
cxtrinityyApr 13, 2019 via Android
12
前端屠杀这个过分了，这特么感情不是比手速网速，是比幸运值么
|
 |
carlcloneApr 13, 2019
13
缓存,队列,分布式...数据库分片...超买超卖优化方案..
|
|
14
@whileFalse 要考虑的地方着实很多 上次看到过一篇秒杀设计写的很透彻,忘了收藏
|
 |
murmurApr 13, 2019
15
直接前端随机返回失败，或者后端恒定 error，我相信个大互联网公司的举报系统都是这么设计的
|
 |
lhx2008Apr 13, 2019 via Android
17
如果要公平，用中间件硬抗也可以的，前端先发请求申请一个指标，最快的拿到指标，其他放掉。
但是还是抽奖比较简单 |
|
lhx2008Apr 13, 2019
19
像小米的话，放指标用的别的队列，几分钟后推回来，这样用户体验比较差，不过成本比较低，也可以兼顾到后面支付和减库存的压力。
|
|
lhx2008Apr 13, 2019
20
淘宝的就比较狠，因为时时刻刻都在秒杀，所以根本没什么策略，也可能是我还没到那个水平
|
 |
death00Apr 13, 2019
21
长知识了，原来秒杀还有抽奖一说
|
 |
FitzApr 13, 2019
25
这 小米真的是在前端就给判死刑了吗?
|
 |
Emmanuel1989Apr 14, 2019
26
@lhx2008 小米确实是真的无良，欺骗你在排队，浪费感情，白白等半天。还不如直接 fail fast 来的痛快。
|
 |
usingnamespaceApr 15, 2019 via iPhone
27
java 的没意思。。。
|
 |
tonghuashuaiApr 19, 2019
28
秒杀其实就是个抽奖，大部分的请求被 js 拦截了，根本到不了后端
|
Select Language