秒杀项目的面试问题记录，求助及欢迎讨论

该帖子在秋招时写的，现在楼主已经上岸了。整理一下答案。

但如果牛友点进来，是想找秒杀项目做。

那我必须说：请不要做秒杀项目。

人均秒杀导致的，不只是简历大量重复。其实真正的问题是：面试官问的问题，已经有很多人回答过，那他肯定听过更好的答案，那你的答案即使原本是合格线的，在面试官看来，也就不及格了。那这样，你就只有提出更好的回答。或者面试官提出难度更高的问题，然后这样一个死循环。

楼主是建议自己去做一些轮子，这里可以推荐另一个牛友的帖子，一个RPC框架。

一个简易的rpc框架实现完整教程

再次提示，做秒杀，三思而后行。

如果牛友是来讨论秒杀的问题、答案，可以继续往后看了。

首先先总结一下我的简历中秒杀项目的知识点

Redis分布式缓存的实现
Redis预减库存
内存标记（HashMap）标记是否已结束
RabbitMQ入队

上面都是基础点了，我额外有

RabbitMQ可靠性传输的实现（发送方，broker ，接收方）三方
RabbitMQ的消息幂等性实现
Jmeter进行的压测
对异常消息的入库记录及Redis对预减库存的补偿

秒杀代码的逻辑就是

1.查看内存标记HashMap，看是否已结束

2.判断这个秒杀订单形成没有，避免重复秒杀

3 setnx，判断该用户是否请求过，返回提示"等待结果"

4 Lua脚本，判断Redis是否有库存，有就扣。没有设置HashMap已结束

5 正常入队MQ

我也写了博客，记录相关的实现，有需要的可以看一下，跳转

（有些问题，博客还没来得及更新，谨慎参考)

先指出个本质设计上的问题：

如果库存为N，其实Redis不应该放N，而应该是2N、3N等。

因为放N，若有X条异常消息，无法正常消费

会出现少卖：有库存，买不到
如果回补库存，则设计内存标识的重新开放。

虽然可以通过MQ实现，但其实有延迟，而且成本大

而对于秒杀场景，关键就是前几秒，因此MQ的延迟实现意义不大。

（而且这样处理后，其实异常数据就不需要回补了，因为你设置的并不是N，少量的异常数据不会导致少卖）

(此处需要呼吁大佬们提供一下解决思路，挺多问题都没解决的)

面试问题

针对单个商品，有10w+的库存，怎么优化Redis？

综合下评论区老哥的答案。

大概想法是多个相互独立的Redis集群。

比如10w个库存，10个Redis集群，一个集群分1w。

存在的问题：某个集群卖完了，但实际其他集群还有。

楼主认为类似上述的放x倍N的思想，每个集群放2W或3W，再

配合nginx的最少访问负载策略，能很大程度解决这个问题。

但感觉并不是最优解。
如何保证不超卖的情况下，提高效率

推荐阅读：写的很好，秒杀系统优化方案（上）吐血整理
项目本身是否多线程

这里说的不是多线程访问，而是指程序本身是否多线程。

答了无额外处理，依靠springboot的调度。

楼主查阅资料，只有一个跟多线程扯上的。

是一位牛友告知的，队列泄洪的概念。

我感觉跟常规的理解有点区别。

这种用的是多线程来限制访问，表象上看反而是降低了访问速度，但可能是出于大量请求等导致的崩溃的问题，这块不太清楚。因此具体请百度

二、内存标识HashMap的相关问题

对Redis库存进行补充后（异常或退款），如何反馈到内存标记
上面已经说了，已经放X倍的N，来避免这种情况。

当然，该问题的答案是：
1. 单机环境下，把HashMap的范围改为public，补充库存后，直接重置HashMap为true。
2. 集群环境下，就把补充的消息推送到MQ，各个节点进行监听，修改本地的HashMap。或者直接依靠集群的同步机制完成。
3. 直接依靠定时任务，根据redis的库存定时更新HashMap的值。
  
  这种方法缺点也很明显，定时间隔长了，实时性不强。间隔短，性能低