该帖子在秋招时写的,现在楼主已经上岸了。整理一下答案。
但如果牛友点进来,是想找秒杀项目做。
那我必须说:请不要做秒杀项目。
人均秒杀导致的,不只是简历大量重复。其实真正的问题是:面试官问的问题,已经有很多人回答过,那他肯定听过更好的答案,那你的答案即使原本是合格线的,在面试官看来,也就不及格了。那这样,你就只有提出更好的回答。或者面试官提出难度更高的问题,然后这样一个死循环。
楼主是建议自己去做一些轮子,这里可以推荐另一个牛友的帖子,一个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占用率外,还有什么能判断是否到底瓶颈?
全部评论
(37) 回帖