说起秒杀，我想你肯定不陌生，从双十一购物到春节抢红包，再到逢年过节抢⻋票，“秒杀”的场景在我们的生活中处处可⻅。简单来说，秒杀就是在同一个时刻有大量的请求，争抢购买同一个商品并完成交易的过程。

不管校招，还是社招，如何设计一个秒杀系统的面试题经常出现，如果懂得其中原理，就可以对答如流，不过涉及到一些瓶颈优化，有些同学就未必都能答出。

面试官：简单说一下秒杀系统的设计思路? 这种题目，小菜是准备过的，巴拉巴拉的说了一堆。 面试官：那这里是怎么保证秒杀成功的？ 小菜：&8^%#

面试官：你这里用了Redis，有什么用？

小菜：#￥&……% 面试官：你用什么测试过这个系统的并发量？ 小菜：&*%$^&. 面试官：你觉得你这个系统还可以再优化么？ 小菜：&%……￥） 面试官：你知道这个系统的瓶颈在哪里吗？如果流量再大10倍，怎么应对？ 小菜：88！

秒杀系统的整体架构可以概括为“稳、准、快”几个关键字。

所谓“稳”，就是整个系统架构要满足高可用，流量符合预期时肯定要稳定，超出预期时也同样不能掉链子，你要保证秒杀活动顺利完成，即秒杀商品顺利地卖出去，这个是最基本的前提。

然后就是“准”，你的业务需求是秒杀10台iPhone XS，那就只能成交10台，多一台少一台都不行。一旦库存不对，那平台就要承担损失，所以“准”就是要求保证数据的一致性。

最后再看“快”，“快”其实很好理解，它就是说系统的性能要足够高，否则你怎么支撑这么大的流量呢？不光是服务端要做极致的性能优化，而且在整个请求链路上都要做协同的优化，每个地方快一点，整个系统就完美了。

所以，一般优化设计思路：将请求拦截在系统上游，降低下游压力。 在一个并发量大，实际需求小的系统中，应当尽量在前端拦截无效流量，降低下游服务器和数据库的压力，不然很可能造成数据库读写锁冲突，甚至导致死锁，最终请求超时。

限流：前端直接限流，允许少部分流量流向后端。

削峰：瞬时大流量峰值容易压垮系统，解决这个问题是重中之重。常用的消峰方法有异步处理、缓存和消息中间件等技术。

异步处理：秒杀系统是一个高并发系统，采用异步处理模式可以极大地提高系统并发量，其实异步处理就是削峰的一种实现方式。

内存缓存：秒杀系统最大的瓶颈一般都是数据库读写，由于数据库读写属于磁盘IO，性能很低，如果能够把部分数据或业务逻辑转移到内存缓存，效率会有极大地提升。

消息队列：消息队列可以削峰，将拦截大量并发请求，这也是一个异步处理过程，后台业务根据自己的处理能力，从消息队列中主动的拉取请求消息进行业务处理。

可拓展：当然如果我们想支持更多用户，更大的并发，最好就将系统设计成弹性可拓展的，如果流量来了，拓展机器就好了，像淘宝、京东等双十一活动时会临时增加大量机器应对交易高峰。

最后，更多关于秒杀系统的解决方案，推荐一个专栏.

如何才能做好动静分离？有哪些方案可选？如何理解QPS、响应时间和线程数之间的关系？如何有针对性地处理好系统的“热点数据”？

转载链接：