说起秒杀,我想你肯定不陌生,从双十一购物到春节抢红包,再到逢年过节抢⻋票,“秒杀”的场景在我们的生活中处处可⻅。简单来说,秒杀就是在同一个时刻有大量的请求,争抢购买同一个商品并完成交易的过程。
不管校招,还是社招,如何设计一个秒杀系统的面试题经常出现,如果懂得其中原理,就可以对答如流,不过涉及到一些瓶颈优化,有些同学就未必都能答出。
面试官:简单说一下秒杀系统的设计思路?
这种题目,小菜是准备过的,巴拉巴拉的说了一堆。
面试官:那这里是怎么保证秒杀成功的?
^%#
面试官:你这里用了Redis,有什么用?
&……%面试官:你用什么测试过这个系统的并发量?
小菜:&*%$^&.
面试官:你觉得你这个系统还可以再优化么?
小菜:&%……¥)
面试官:你知道这个系统的瓶颈在哪里吗?如果流量再大10倍,怎么应对?
小菜:88!
秒杀系统的整体架构可以概括为“稳、准、快”几个关键字。
所谓“稳”,就是整个系统架构要满足高可用,流量符合预期时肯定要稳定,超出预期时也同样不能掉链子,你要保证秒杀活动顺利完成,即秒杀商品顺利地卖出去,这个是最基本的前提。
然后就是“准”,你的业务需求是秒杀10台iPhone XS,那就只能成交10台,多一台少一台都不行。一旦库存不对,那平台就要承担损失,所以“准”就是要求保证数据的一致性。
最后再看“快”,“快”其实很好理解,它就是说系统的性能要足够高,否则你怎么支撑这么大的流量呢?不光是服务端要做极致的性能优化,而且在整个请求链路上都要做协同的优化,每个地方快一点,整个系统就完美了。
所以,一般优化设计思路:将请求拦截在系统上游,降低下游压力。
在一个并发量大,实际需求小的系统中,应当尽量在前端拦截无效流量,降低下游服务器和数据库的压力,不然很可能造成数据库读写锁冲突,甚至导致死锁,最终请求超时。
限流:前端直接限流,允许少部分流量流向后端。
削峰:瞬时大流量峰值容易压垮系统,解决这个问题是重中之重。常用的消峰方法有异步处理、缓存和消息中间件等技术。
异步处理:秒杀系统是一个高并发系统,采用异步处理模式可以极大地提高系统并发量,其实异步处理就是削峰的一种实现方式。
内存缓存:秒杀系统最大的瓶颈一般都是数据库读写,由于数据库读写属于磁盘IO,性能很低,如果能够把部分数据或业务逻辑转移到内存缓存,效率会有极大地提升。
消息队列:消息队列可以削峰,将拦截大量并发请求,这也是一个异步处理过程,后台业务根据自己的处理能力,从消息队列中主动的拉取请求消息进行业务处理。
可拓展:当然如果我们想支持更多用户,更大的并发,最好就将系统设计成弹性可拓展的,如果流量来了,拓展机器就好了,像淘宝、京东等双十一活动时会临时增加大量机器应对交易高峰。
最后,更多关于秒杀系统的解决方案,推荐一个专栏.
关键一点的是,这个专栏只要九块九,9.9你买不了吃亏,9.9你买不了上当。