秒杀项目的面试问题记录，求助及欢迎讨论
该帖子在秋招时写的，现在楼主已经上岸了。整理一下答案。
但如果牛友点进来，是想找秒杀项目做。
那我必须说：请不要做秒杀项目。
人均秒杀导致的，不只是简历大量重复。其实真正的问题是：面试官问的问题，已经有很多人回答过，那他肯定听过更好的答案，那你的答案即使原本是合格线的，在面试官看来，也就不及格了。那这样，你就只有提出更好的回答。或者面试官提出难度更高的问题，然后这样一个死循环。
楼主是建议自己去做一些轮子，这里可以推荐另一个牛友的帖子，一个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，来避免这种情况。
当然，该问题的答案是：
单机环境下，把HashMap的范围改为public，补充库存后，直接重置HashMap为true。
集群环境下，就把补充的消息推送到MQ，各个节点进行监听，修改本地的HashMap。或者直接依靠集群的同步机制完成。
直接依靠定时任务，根据redis的库存定时更新HashMap的值。
这种方法缺点也很明显，定时间隔长了，实时性不强。间隔短，性能低
HashMap的问题
线程安全问题：不安全，但不影响。因为后续还是会经过Redis库存判断。
为了线程安全换ConcurrentHashMap之类的，反而不值得
OOM问题：采用Guava，利用其自带的LRU解决。
三、压测相关：
load average高，不一定是CPU资源紧张，如何排查磁盘IO问题，相关命令： vmstat、iostat
(仍然没思路的↓）
如何检测、定位项目的性能瓶颈在哪
答了把方法细拆，分别压测对应方法。但反应不理想
除了CPU占用率外，还有什么能判断是否到底瓶颈？
查看15道真题和解析