之前的面试题，现在突然想起来了。

我：使用可靠消息发送 MQ （同步写数据库），库存服务消费 MQ 扣减

面试官：多一次数据库写入，性能低，不行

我：不扣减库存，秒杀活动结束后，扫描活动期间的所有订单，根据订单中的数据统计库存

面试官：扫描订单太多，不行

最后，美国服务器我问了一下要怎么处理，他说 发 MQ 就行，只要 MQ 服务器不崩就可以。他说他之前是 MQ 存储不够，导致消息发送失败。

我说万一失败怎么办，他说后面会有对账之类的系统（他们现在没有）。

所以，到底应该保证事务消息，还是后期处理？

目前我们系统也做了类似的业务,不做用的 redis 做的扣减

秒杀的设计方案大体都是削峰，怎么削就要看具体情况了
这种面试官问的也不太合理

库存无限的话为什么还要扣减库存，连一致性都不用保持了。
我个人的想法是：
秒杀前把库存无限的商品 ID 先从数据库中提前提取到 Redis 里缓存。
用户请求到达服务端后连接 Redis 判断一下商品是不是都属于无限库存的，是的话异步发送一个订单生成消息给订单服务然后直接返回成功，消息队列这块还要保证可用性（订单不丢失之类的）。

库存无限的话为什么还要扣减库存

库存无限还减什么库存啊，做加法啊

秒杀的关键在于动静分离、提前校验。
1. 根据 db 规格做好进程内限流，预留一倍升级空间。
2. 静态数据（商品属性）提前预热至缓存，缓存过期时间为秒杀结束时间。
3. 各种校验提前做，特别是库存校验。
4. 库存怎么扣减
- 提前预热库存数据至 redis，原子 DECR 扣减库存，扣减成功 mq 同步 db 库存。
5. 如何下单？
- 校验成功通过 mq 抛出下单事件，做好耗时监控，前端页面 hold 一下。
6. 超时未支付怎么办？
- 下单成功时抛出抛出延时消息，比如 30 分钟。到期检测订单状态，失败 INCR 把库存还回去。
7. 如何防刷？
- uid 固定时间限流
8. 如何反止链接提前泄露？
- 产品 id 哈希
9. 如何反止暴力遍历？
- 产品 id 经过布隆过滤器校验一下

看到对账，考虑用事件模型？订单请求生成事件，事件一边入库用于对账，另一边入 mq 发起库存扣减、订单生成等事务操作。

redis，mq 一把梭:D

这面试官的答案莫名其妙。
1 、说依赖消息，但怎么证明当前的消息队列 or 缓存一定是正确的（与订单系统结果一致）？
2 、消息队列出错就去对账（账单 /订单），那不还是和 lz 的事后方案一致？
所以我支持 lz 的事后撸订单的逻辑。既准确，又安全，还消峰。

不好意思，没描述清楚，也不是说真正的库存无限，可以理解为库存很多，理论上卖不完

这面试官水平不高嘴倒是挺硬

直接下订单不就行了，都不用管超售

明知道卖不完。。。为什么还要费时间和空间去管它库存的问题

这个面试官...

每单加一，用单机 mysql 都能撑起来上万并发吧。

库存无限哪来的秒杀，是个单子就能下

面试官问出这么水的问题，你还想去这样的公司吗

如果库存理论上用不完，感觉可以 redis 计数，定时刷库存

秒杀 和 库存无限 是矛盾的...... 面试题有问题...