(1)尴尬的面试现场:第一幕面试
(2)尴尬的面试现场:第二幕数据库
(3)别让你学的技术成为空中楼阁缓存
(4)千方百计的 “虐虐” 本身架构
“ 这篇文章,给你们说一个一样是不少人都很迷惑的问题,由于实在是太多同窗来问我相似的问题了,因此写一篇文章给你们来讲一下。并发
事情的原由是这样子的:不少好学的同窗,都会本身平时研究不少的技术,好比常见的就是买书看书,参加在线培训课程,购买一些知识付费的专栏,或者购买一些视频课程。分布式
可是这些好学的同窗在学了不少东西以后,出去面试都遇到了这样的一个痛点问题:微服务
这些同窗简历上写了不少高大上的技术,可是其实本身可能没机会,或者还没来得及在本身手头负责的项目里用过,并且本身负责的项目好像也没很么用户量和并发量。高并发
因而面试官和候选人可能会展开以下一系列的问题:
学习
面试官设计
你说大家系统用了Redis,那你说说大家项目目前有多少用户?
候选人
这个。。。。好像大概就几百或者几千?(或者有的人是小互联网公司的,可能会说,大概有个百万级的用户量)
面试官
好吧,那你说一下大家系统天天日活是多少?
(解释一下日活:若是一个公司的产品有100万注册用户,但确定不是天天每一个人都会来用你的系统的啊!就好像注册了一个APP,可能半年才会用一次!这个日活,就是天天到底多少人来用)
候选人
啊?天天多少人来用?我这个还真的没统计过啊。。大概可能有几千或者几万我的?
面试官
行吧,那大家天天几千或者几万我的来用,那天天的请求量有多大?
候选人
这个我还真的没统计过啊,很差意思啊!
面试官
纳尼?那你知道大家的系统高峰期QPS有多大码?(QPS,Query Per Second,也就就是每秒有多少请求)
候选人
(内心感受快哭了,由于以为这个面试要黄,为啥什么技术都没问题,直接来这些啊)我真的不知道啊。。。
面试官
那你什么都不知道,你说说大家系统为何要用Redis缓存?还要搭建一个3台机器组成的Redis Cluster,这缘由何在?
若是不用Redis,直接就用MySQL来抗能不能抗的住?
候选人
咱们当时用Redis。。。。咦?到底为啥要用啊?我好像也忘了,就感受能够把这个技术用一下,毕竟咱们花了时间来调研,因此以为能够用就用一下。
面试官
你这是典型的为了用而用啊!那你简历上说,你熟悉高并发相关技术,包括Redis、RocketMQ,等等,那你到底作太高并发系统没有啊?
候选人
好吧,我错了,我确实不知道什么是高并发,我就是学了这些技术而后就写在简历上了。
面试官
(内心活动)咋回事,搞半天是没相关经验的,都是本身学了一下啊,好吧,那来压一压薪资,看来不能当资深码农来对待了 ,就当作普通的来面一下好了
因而两我的进入了一系列的技术问答,可是面试官内心有数,这个候选人最多就是给一个普通工程师的职位,由于其实他并无过技术在项目如何落地的一些经验。
这个候选人痛定思痛,回来改了一下简历,说本身负责的系统,日活用户几十万人,高峰期QPS能够达到5000/s+。
而后心想,这回不会像上次同样,把这个事儿给聊黄了吧。到了面试现场坐下来开始了跟面试官下面的对话:
面试官
大家用户量多大?日活多少?天天请求量多大?高峰期QPS多高?
候选人
(成竹在胸,嘴角挂着迷之微笑。。。)注册用户100万,天天日活几十万用户,天天请求量有几千万,高峰期QPS最大有5000/s+。
面试官
奥,那大家线上的部署架构是怎么作的,给我画图看看?
而后大家一共有哪些服务,每一个服务部署了多少台机器?每台机器是什么配置?CPU和内存有多大?你的机器部署是怎么抗住每秒5000请求的?
候选人
(心理活动)公司实际没啥请求量,每一个服务就部署一台机器,连配置本身都没关注过,天知道每秒5000请求须要多少机器能够抗住啊。。。
面试官
咦?你怎么支支吾吾的,本身项目线上部署状况都不清楚?
那若是大家从网关入口层进来的请求是5000/s的话,那你能画图说一下你负责的每一个服务的接口的QPS是多少?
而后大家的各个中间件,MySQL、Redis、ES、RocketMQ,他们各自的QPS都是多少?以及他们各自都部署了多少机器,每一个机器什么配置?
候选人
这个。。。。我历来没考虑过,我还真的不知道啊!
面试官
那你简历说你系统能够抗5000/s的并发请求,你根本不知道系统架构是怎么抗住的啊!
候选人
…………
上面说的两个面试场景,其实真的是很是真实的两个场景,是不少不少同窗频繁给我反馈的尴尬面试现场。
由于这些同窗学了不少东西,可是本身没准备好技术在项目里怎么落地的,结果就惨了,出去面试就各类尴尬。
由于学了的技术没落地过,那不至关于空中楼阁,你面试内心能不慌吗?
因此这里要给你们说的一点,就是本身平时会学不少的技术,可是必定要注意把这些技术尽可能尝试落地用到本身手头负责的项目里去。
另外,光用是不行的,你平时得考虑好,假设你的项目的用户量有百万级,而后天天有几千万请求,高峰期每秒有好几千请求。
那么这个时候,你的每一个服务会有多高的QPS?每一个服务须要部署多少台机器才能够抗住?机器的配置是多高?
而后系统会对背后的MySQL、Redis、ES、RabbitMQ等数据库以及中间件,产生多高的QPS?这些中间件须要部署多少台机器,用多高配置的机器?
这些东西实际上是很是很是重要的,也是你在学习了N多技术以后,把技术真正转化为本身的东西须要作的不少消化性的事情。
因此,但愿你们平时好好准备,多实践,多动手。实际工做中多思考,多给本身设计各类场景,push本身去解决这些场景的技术难题。
你在平时工做中多 “虐虐” 本身,面试才能表现的更加成竹在胸、云淡风轻。
一大波微服务、分布式、高并发、高可用的原创系列文章正在路上,
欢迎关注公众号:石杉的架构笔记
周一至周五早八点半!精品技术文章准时送上!!!
十余年BAT架构经验倾囊相授