假如你是一名面试官、对于秒杀系统你会问哪些问题?

[love2020]

等回答。

[murmur]

秒杀系统不是八股文么，真的秒杀系统在秒杀开始之前大局已定，很多人就是没有抢购资格，然后剩下的人随机失败一部分

留下的并发就很小了

[love2020]

1. 如何应对突发流量 [数据库负载、带宽、DNS 、限流、过载保护] 2. 并发-安全 [库存、恶意攻击、接口动态化] PS: 网上抄的

[jorneyr]

这个问题面试中能回答出来的方案，一定是不可用的方案。

[simonlu9]

如果没做过秒杀真不要问这种问题，显得自己高人一等的样子

[dwlovelife]

有几个人 做电商业务 有几个电商业务场景需要秒杀 需要电商业务又需要秒杀场景 然后这个活给你做 再经历过真实生产环境的考验

[meteor957]

劳资先秒面试官的🐴

[love2020]

@meteor957 一个字，牛逼

[no1xsyzy]

纯看速度的秒杀其实不够公平，比如机器人下单，比如网络有快有慢。而且会导致踮脚效应。
如 #2，本质是先摇号。
当然你也可以真的摇号，但是用户体验不佳，因为用户明确地意识到自己没有任何办法增加自己得到购买资格的可能性
所以要表面拼手速，本质摇号的表里不一。
但其实还有一种更优秀、更赚钱而且表里如一的做法，但因为 1. 太过好用； 2. 不够道德，所以我是不会公开指出的。不过这个做法很传统，营销人员大多是早已知道的。
想找我对答案或者买答案的话，可以给我发邮件（邮箱请自己想办法找到）。

这是 UX 设计的技术问题，不是计算机或软件工程的技术问题。

[no1xsyzy]

@no1xsyzy 不全：
这是 UX 设计的技术问题，不是计算机或软件工程的技术问题。
如果你面试程序员，不要问这个问题。
如果你面试的是 UX 设计师或者营销策划，才可以问这个问题。

[fkdog]

都 2021 年了还搁着秒杀.....
能不能与时俱进一点.

[lei2j]

@meteor957 你牛逼

[lscexpress]

@jorneyr 一定？你说一定，全部都一定？

[CodeCodeStudy]

通通都拦在外面，只有内部人士才能秒杀中

[maxiaofeng]

@fkdog 与时俱进，现在都是啥啊，，大佬

[qping]

@no1xsyzy #10 邮件发你了... 标题是穿山甲到底说了啥, 有时间的话看下邮件吧~挺好奇

[ch2]

@qping #16 弹个框说正在排队，实际上没中

[krixaar]

@qping #16 “今天你的秒杀成功难度：*转盘*困难……一般……超容易！”
“AI 大数据预测你今天的秒杀成功率：1%……50%……99%！”
“你还需要邀请几位好友助力：*转盘*6……4……1 ！”
“你附近的好友[xxx] [yyy] [zzz]已秒杀成功！”

[rpman]

真有人用技术来做秒杀?

[qping]

@krixaar #18 怎么一股 pdd 的味道 (狗头)

[ciddechan]

不会让系统中有秒杀，因为会浪费资源

[Poko]

问这种的都是培训班出来的

[qq976739120]

问秒杀红包之类的问题,基本上是半吊子

[no1xsyzy]

@qping 我没说清楚。
要么拿着你的解一换一我的解，要么拿（不少的）钱换我的解。
几个空手来问的我都移 Spam 了。
非常传统的营销策略，不必通过我，多跑跑商场就能知道了，基本策略他们大概还在用。

不过 #18 已经差不多了，但缺乏了秒杀的形态。
不过，说回来，秒杀确实根本就不应该出现，这东西连营销上都不算上乘，ROI 非常低，甚至不如直接打折。
问题就是，开发秒杀系统的技术开销不算营销的开销，降不了报表 ROI，那些纯粹当个分母、之后消失无踪的人却计算为营销的收益，凭空增加报表 ROI 。实际就是，垃圾的市场营销为了自己的而非企业的利益，割运维开发的韭菜。如果一次秒杀不能借此将你的服务宣传到全网皆知，那就是失败的。

[comoyi]

秒杀==盲盒

[darksword21]

@meteor957 握🌿，🐂🍺

[Jface]

啊哈哈哈 笑出声

[wangt21]

我会甩两道 leetcode hard，因为我是高贵的字节面试官

[461990781]

@wangt21 我是你哥哥

[new1viewer]

@maxiaofeng 某多那一套呗

[docx]

@krixaar #18 有拼多多那味了

[thinkingbullet]

兄弟别在卷了,找份工作容易吗?我问你 tcp 挥手都是四次吗,如果不是说说为什么.

[Dragonphy]

@meteor957 #7
朴实无华

[2kCS5c0b0ITXE5k2]

学小米啊.前端先过滤一半

[crclz]

使用 redis 只能保证不超卖——这个答案是网上随便查得到的。

完美答案是：
假设有 N 个库存，那么就得分配 N 个 token （例如 GUID ），token 放在 redis 上面以供获取。token 作为 mongo 的_id 就可以将压力平均分散到各个 shard 。shard 越多，压力越小。如果有 100 个 shard，那么压力就变为 1/100 。再用 mongo 的_id 做幂等，保证一个 token 只用一次，保证不超卖。最后通过订阅 binlog or 业务代码 将用过的 token 同步到 redis 进行标记。并且根据数据库的压力的不同可以在 redis 中对同一个 token 使用分布式锁来缓解压力，类似于避免惊群 /击穿的方案。
本方案既能保证先来后到公平性，又能保证不超卖 /少卖，还可以支持临时加库存的情况下依然能保证上述特性。

这个方案我之前面试的时候用过了，面试官挑不出刺。当然一次别说完了，不然面试官可能理解不了，挑“token+幂等”这个重点就行了。

[namelosw]

秒杀方案都太过鸡贼，感觉如果是纯技术的话其实可以换个问题，比如拍卖。

其实国外很多搞高可用的架构师都是搞拍卖或者菠菜出身的。

[chenyu0532]

现在淘宝 京东 这些还有秒杀吗？？这种是 10 年前有的吧。现在有的话也就是双 11 了。。

[realpg]

@crclz #35
15 年前做一种特殊的秒杀（不是卖东西，但是逻辑跟秒杀没区别），那时候还没有 redis，没有 memcache 。
当时的方案是纯 MYSQL，那时还没有云计算弹性扩容
当时就可以很容易的解决秒杀问题，而且严格不能超售。
多开 webserver，mysql 堆 ram 扩大连接数不让他死掉

比如秒杀商品是 100000 件每人限购一件限购一单，直接预先生成 100000 个订单，不在主订单表内，每个秒杀做一个独立的订单表，引擎 memory(heap)

简略的单一项目秒杀独立订单表如下
order_id user_id，……………………其中 user_id 挂唯一索引

所有订单 user_id 预先都设置成 0
秒杀逻辑就是大家拼命往里堆执行
update [table] set user_id = [Your user id] where user_id = 0 limit 1;

秒杀完成后（ 30 秒级），直接预置一个逻辑，把这个特殊表按规则合并到主订单表

缺点就是，30 秒内，[我的订单]看不到秒杀成功的订单……


如果不想依赖手速网速，或者不像搞死最大连接数只有 800 左右的单机 MYSQL，就在前面下概率控制，随机数有一定概率往数据库里写。随机数可以引入时间加权。

[Feiex]

@no1xsyzy 秒杀的 roi 低吗？
一换一：想问下你是什么行业的秒杀活动呢？复购、库存、客群是怎样的？

我们这秒杀品的复购率非常可观（可能我们的客群覆盖比较精准）。
坐标某厂餐饮供应链营销技术

[no1xsyzy]

@Feiex 不是卖方，看过灰黑产（这算黑产还是灰产？）用假人，本人不想涉及灰黑产就没合作。
问下尖峰 QPS ？是否有控制变量对比？顺便，我有部分是夸张的暴言。
而且做供应链的话，我怀疑可能是套了「秒杀」之名的「一般限时限量促销」，可能是方便给老板解释就直接叫秒杀了。这其实不需要技术专门处理，体量小一个 MySQL 单例都行，大的 MSSQL 或者 Oracle 完全跟得上。这不算割运维开发韭菜，算收老板的智商税。不需要技术挠破头皮的都不算真秒杀，回到本主题的话确实也不需要面软件技术的时候提这问题。

[murmur]

@chenyu0532 有啊，前多少的享受优惠价，不过都是那种不太有名的商品，如果是个半价苹果基本上是到时间就结束了

----------
顺便

国内的秒杀都是纯业务问题，比如 pdd，别人就不考虑并发，因为可以砍单，真是从来没设想过的道路，秒杀有并发，但是砍单没有啊

[Feiex]

@no1xsyzy 不同情况的秒杀 qps 不好估量，我们一般都声称“支持单品 35w qps”，但其实这是公司中间件和 redis 的性能峰值。
热品一般会触发各种降级，所以实际上的 qps 没那么夸张。
你说的对，供应链流量没那么大，就是「一般限时限量促销」。没有用 mysql 。面试时候还会要问一下（不然怎么好意思说自己在做营销）

[no1xsyzy]

@Feiex 这倒是，一直有看到说法认为，面试有必要以一种差不多有效的方式尽可能快地筛掉大部分人。
想来面试这件事本身也讲究个 ROI