这种题目，小菜是准备过的，巴拉巴拉的说了一堆。
面试官：那这里是怎么保证秒杀成功的？
小菜：&8^%#
面试官：你这里用了Redis，有什么用？
小菜：#￥&……%
面试官：你用什么测试过这个系统的并发量？
小菜：&*%$^&.
面试官：你觉得你这个系统还可以再优化么？
小菜：&%……￥）
面试官：你知道这个系统的瓶颈在哪里吗？如果流量再大10倍，怎么应对？
小菜：88！
秒杀系统的整体架构可以概括为“稳、准、快”几个关键字。
所谓“稳”，就是整个系统架构要满足高可用，流量符合预期时肯定要稳定，超出预期时也同样不能掉链子，你要保证秒杀活动顺利完成，即秒杀商品顺利地卖出去，这个是最基本的前提。
然后就是“准”，你的业务需求是秒杀10台iPhone XS，那就只能成交10台，多一台少一台都不行。一旦库存不对，那平台就要承担损失，所以“准”就是要求保证数据的一致性。
最后再看“快”，“快”其实很好理解，它就是说系统的性能要足够高，否则你怎么支撑这么大的流量呢？不光是服务端要做极致的性能优化，而且在整个请求链路上都要做协同的优化，每个地方快一点，整个系统就完美了。
所以，一般优化设计思路：将请求拦截在系统上游，降低下游压力。
在一个并发量大，实际需求小的系统中，应当尽量在前端拦截无效流量，降低下游服务器和数据库的压力，不然很可能造成数据库读写锁冲突，甚至导致死锁，最终请求超时。
限流：前端直接限流，允许少部分流量流向后端。
削峰：瞬时大流量峰值容易压垮系统，解决这个问题是重中之重。常用的消峰方法有异步处理、缓存和消息中间件等技术。
异步处理：秒杀系统是一个高并发系统，采用异步处理模式可以极大地提高系统并发量，其实异步处理就是削峰的一种实现方式。
内存缓存：秒杀系统最大的瓶颈一般都是数据库读写，由于数据库读写属于磁盘IO，性能很低，如果能够把部分数据或业务逻辑转移到内存缓存，效率会有极大地提升。
消息队列：消息队列可以削峰，将拦截大量并发请求，这也是一个异步处理过程，后台业务根据自己的处理能力，从消息队列中主动的拉取请求消息进行业务处理。
可拓展：当然如果我们想支持更多用户，更大的并发，最好就将系统设计成弹性可拓展的，如果流量来了，拓展机器就好了，像淘宝、京东等双十一活动时会临时增加大量机器应对交易高峰。
最后，更多关于秒杀系统的解决方案，推荐一个专栏.
- 如何才能做好动静分离？有哪些方案可选？
- 如何理解QPS、响应时间和线程数之间的关系？
- 如何有针对性地处理好系统的“热点数据”？
- 秒杀减库存的方案应该如何设计？
作者：占小狼
链接：https://www.jianshu.com/p/06479ea2dc46
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。