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

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
一个致命的 Redis 命令,导致公司损失 400 万!!
最近安全事故濒发啊,前几天发生了《顺丰高级运维工程师的删库事件》,今天又看到了 PHP 工程师在线执行了 Redis 危险命令导致某公司损失 400 万。。 什么样的 Redis 命令会有如此威力,造成如此大的损失? 具体消息如下: 看完这个消息后,我心又一惊,为什么这么低级的问题还在犯?为什么线上的危险命令没有被禁用?这事件报道出来真是觉得很低级。。。 且不说是哪家公司,发生这样的事故,不管是大公司还是小公司,我觉得都不应该,相关负责人应该引咎辞职!!! 对 Redis 稍微有点使用经验的人都知道线上是不能执行keys *相关命令的,虽然其模糊匹配功能使用非常方便也很强大,在小数据量情况下使用没什么问题,数据量大会导致 Redis 锁住及 CPU 飙升,在生产环境建议禁用或者重命名! 还有哪些危险命令? Redis 的危险命令主要有以下几个: keys 客户端可查询出所有存在的键。 flushdb 删除 Redis 中当前所在数据库中的所有记录,并且此命令从不会执行失败。 flushall 删除 Redis 中所有数据库中的所有记录,不只是当前所在数据库,并且此命令从不会执行失败。 ...
- 下一篇
各种系统架构图与详细说明
原文: 各种系统架构图与详细说明 共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面: 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合,完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类,具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源,我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源,我们将通过全面的接口管理体系进行相应资源采集模板的搭建,采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现,具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布,相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不...
相关文章
文章评论
共有0条评论来说两句吧...