高并发技术面试专题汇总，BAT技术面试不过如此！

本文咱们经过一篇真实的一线面经，带你们去体验一下 BAT 等互联网公司的面试现场氛围！

面试者是笔者之前的下属，多年的好朋友。这是他去年早些时候出去面试，拿到 BAT 等多家一线互联网公司技术专家 Offer 的面试经历。

先介绍一下这位朋友的我的经历：

• 本科毕业，接近 10 年工做经验。跳槽以前，在国内某大型互联网公司里带一个 8 人左右的技术团队。
• 因为公司业务发展较为平缓，因此职业上升机会较少。
• 朋友对其负责的系统架构和技术已经很是熟悉，薪资上也较难有大幅度的增加，至于晋升更高的级别，短时间内也不容易。

所以，在仔细思考一番以后，决定出来看看机会，可否在带团队的规模、技术以及薪资上实现一个突破。

一面

一面是一个猎头给朋友推的一个职位，BAT 中某一个大厂的某个团队，具体就不说是哪一个部门了。

一面就直接过去当面聊了一次，大概从下午 2 点聊到了下午 4 点多，时间很长，炮火至关猛烈。

一面面试官也是专家职级，上来就是先聊项目，针对项目中的各类细节仔细问，就项目展开，并且极其注重细节。

下面的内容，是根据朋友面试以后的回忆，整理出的部分问题：

面试一样是经过互联网公司最喜欢的连环炮形式发问。好比在面试过程当中，聊到了缓存，连环炮以下。接着，面试官继续深扣了不少细节。

面试官：

• 那请说一下，这些请求具体是落在哪些接口上？
• 哪些数据是数据库和缓存双写一份的？
• 双写一致性如何保证？保证一致性的同时如何保证高并发和性能？
• 缓存线上是如何部署的？给了多大的总内存？命中率有多高？
• 缓存抗了多少 QPS？数据流回源会有多少 QPS？
• 是否某个 key 出现了热点缓存致使缓存集群中某个机器的负载太高？如何解决的？
• 是否出现超大 value 打满网卡的问题？如何规避这个问题？
• 线上是否出过缓存集群事故？若是出现了大家怎么解决有什么高可用保障预案？
• 平时如何监控缓存集群的 QPS 和容量？若是要扩容该怎么扩？可否平滑扩容？扩容会致使系统须要停机吗？
• 聊聊 Redis 的集群原理？扩容的时候会不会致使数据丢失？key 寻址算法都了解哪些？
• 你了解一致性 hash 算法吗？画个图说说 Redis 线程模型和内存模型？

朋友：纸笔翻飞，大脑高度运转，一个接一个的回答。。。

如上所述，全部问题，所有结合项目，落地到生产中，同时注重聊技术的不少细节，包括技术的一些原理。

像缓存这样的连环炮提问法，面试官还用来问了 MQ、MySQL 分库分表、高可用、JVM、多线程并发，等各类问题。

简单总结：

• 一面其实关注了技术广度，同时结合项目死扣各类细节。
• 另外也兼顾了必定的技术深度，会就一个技术往深了问下去。

整体来讲，一面还算顺利，毕竟都是结合项目来问的，各类细节平时朋友进行架构设计时，都会仔细考虑过。

并且朋友也作过线上的高并发系统，踩过不少坑，因此这些问题基本都回答的不错。

可是这里给你们提醒一句，通常某个同窗出去面试，回来以后其余人问他面试经验，通常都是问：都有啥面试题？面试官是怎么问的？

说实话，你们看了上面那些问题，可能会以为说，哦，其实我也能够答出来，没什么特别的。

但其实并非这样，若是只是拿高级岗位的 Offer，你的技术会占很大比重。

可是若是要拿专家岗位的 Offer，你到底有没有线上真实的高负载的系统架构经验，很是重要。

一样的问题，普通人会回答的很普通，可是经历过真实几十亿流量请求的人必定会说出大量经验总结、教训以及踩坑。

并且对整套复杂的大型系统究竟是如何抗住高并发的，会了然于胸，熟悉全部的细节。

因此针对一面，通常就是结合项目，深挖细扣，看你到底有多少水平，作过多复杂的系统。

这块说实话，作过就是作过，没作过就是没作过，是不可能做假的。不少同窗可能本身平时也看过不少书和博客，可是看书和博客只是基础，若是没有真实的线上生产环境的历练，是确定不够的。毕竟实践出真知！

二面

一面就顺利经过了，紧接着安排了第二轮面试。二面面试官应该是这个团队的 Leader，P8 级别的，若是进去，应该就是朋友将来的顶头上司。

据朋友讲，二面面试官态度很是好，很和善，看来一面面试官反馈以后，这个 Team 对朋友仍是比较重视的。

技术深度

二面内容就从广度变成深度了，面试官技术实力很深厚，应该是有十几年经验。对相关技术深挖了不少东西。

一样，二面也聊到了缓存相关的问题。问了朋友具体了解过哪些缓存技术，Redis、Memcached，还有阿里开源的 Tair，哪一个了解过内核原理？

朋友以前看过一些 Redis 的内核，就聊了聊 Redis 内核的一些数据结构和实现原理。包括集群、持久化在内核层面的一些东西。

此外在 MQ 这块，朋友正好对 Kafka 作过深刻的研究，就聊了聊 Kafka 的源码。

好比 Kafka Controller 在故障转移这块的源码，日志存储、网络通讯的一些细节。

如何保证磁盘读写的高性能，零拷贝那块的底层实现，leader 和 follower 之间的数据是如何同步的，都是从源码层面来聊。

此外，还聊了 Dubbo 的源码以及 MySQL 内核层面的东西。

系统设计、工程素养、带团队

同时二面很是重视考察系统设计能力、工程素养、带团队的能力。好比面试官就这个部门负责的一块业务，出了一个相关的系统设计题目。

题目细节记不清楚了，大致内容是给出具体的用户量、业务场景、并发量、数据量，而后让你总体负责这个系统的架构设计。

朋友须要阐述本身的总体设计思路，从哪些点来考虑，存在着哪些技术挑战，而且现场画出来具体的架构设计图。

工程素养这块，让朋友聊了聊平时如何作的技术设计、技术评审、编码规范、测试、上线、回滚、灰度、压测、监控等等。

带团队，让朋友说一下，如何招人、面试标准、如何搭建团队的人才梯度，等等。

架构演进

此外，还会问一下，整个系统架构是如何一步一步进行演进的。从 0 到 1 的时候是什么架构？从 1 到 10 的时候是什么架构？从 10 到 100 的时候是什么架构？这块就是看看你的总体架构能力，以及技术规划能力。

说到这里，笔者提一句，若是出去面试，尤为是去 BAT 等大型互联网公司面试，必须精心准备。

包括你的项目的每一个细节，你解决过的各类线上问题和坑，你简历里的技术是否达到必定的深度，你平时其余的工程、设计能力，这些都必定要精心准备一下。

绝对不要裸面！绝对不要裸面！绝对不要裸面！重要的事情说三遍！裸面必败，并且若是一问三不知，那么给人的印象就是不好的。

若是要冲着心仪的大公司去，最起码精心准备 1 个月以上，你们务必记住这一点，这也是朋友此次的一个重要心得，准备充分了，才能有备无患。

三面

二面以后，又等了大概一两周。。。由于越往上面，领导级别越高，平时越忙，有时人家可能出差开会去了，不过等了一两周，那边总算约上了三面。

三面是总监级别的，不太肯定是走的 M 线仍是 P 线。若是是 P 线，那么必定是 P9，可是观察面试风格应该是 M 线的总监。

这一面，聊技术其实并很少，更多的是跟朋友聊过往的各类公司的经历和项目经验，具体负责过哪些比较有挑战的大型的系统。

另外，考察了各类软素质。好比说责任心、抗压能力、自我驱动，让朋友举例说明本身过去的一些事情，来证实软素质。

同时还会聊聊职业价值观，是否愿意加班，等等吧。最后也聊了聊朋友的职场指望，包括这个团队是干什么的，将来的发展方向之类的。

朋友以为最重要的仍是前面两面，其实这一面，只要人品端正，平时干活儿认真负责，通常的都没什么太大的问题。

终面

接着又过了一两个礼拜，由于当时二面面试官，也就是那个将来可能成为朋友 Leader 的人，对朋友仍是比较看重的，私下还短信联系了一段时间，就怕朋友跑去别的公司了。

他告诉朋友说是由于 HR 那边太忙了，因此终面还未安排上。关于 HR 面，朋友印象真是至关之深入，为何呢？

由于 HR 是直接电话聊的，没过去了，过去实在太折腾，并且二面面试官也是去打了招呼。

HR 当时竟然是晚上 11 点打来的电话，人家刚刚加班开会结束，就打来了电话，真是不得不佩服其敬业精神！

并且这位 HR 是至关专业的，若是是普通的 HR 其实随便聊聊就好了，可是这边的 HR 问了不少问题，大概聊了 1 个小时左右。

主要是跟朋友聊了一些价值观的东西，好比以前以为作过最难的事情是啥，怎么克服的，当时啥心态。

还有就是为啥要离职，没有发展空间？那当时没考虑过公司内部 transfer（转岗）吗？为啥很差 transfer？你的绩效平时怎么样？你以为你跟同事相处的怎么样？

终面内容，总结起来，其实仍是一句话，你人品正就行了，通常都问题不大，老老实实的踏实回答。

后来 HR 面了事后，那边的薪资确实给到位了，达到了朋友的指望薪资。可是那边给的规划是将来能够带的团队人数也就是 10 人之内，并且不是配发集团股票，是配发的正在快速发展的这个团队的期权。

因此朋友当时纠结了一下，但仍是先答应了，因而 Offer 就发了过来。

后记

原本朋友想的是，若是没有别的更好的机会，那么这个机会也能够考虑，毕竟薪资上仍是能够的。

可是当时包括 TMD（头条、美团、滴滴）这边，也都有人内推朋友过去试试，因此当时也面了其余的几个一线互联网公司。

其实若是经历了 BAT 这种互联网公司的几轮技术面试洗礼，那么去国内任何一个公司都没什么问题了，因此当时面试也都很顺利，得心应手。

一样，朋友也不出意外的拿到了那些一线互联网公司的 Offer。通过一番对比，朋友最终没有选择去最初面试的那个 BAT 中的某个大厂，而是去了上面说的那几个超级独角兽公司中的其中一个。

缘由是这家超级独角兽公司给出的薪资超出指望以外，并且领导对朋友一样很是重视，配发了大量的期权，承诺能够独立带 20+ 人的团队。

而朋友更看重的是这个超级独角兽公司将来的潜力：

• 公司发展速度快，人员扩张迅猛，因此给到的带团队的机会很是好，能带更大的团队，比朋友当前带的团队规模大了一倍多。
• 虽然 BAT 的那家大厂一样配发了期权，可是这家超级独角兽的期权将来潜力可能更大。事实证实，的确如此。

因此综合考虑了以后，朋友最终仍是根据本身的职业发展选择了独角兽公司，没有再回到 BAT 行列中。

最后

我这里仍是把以前那位大佬分享给个人Java架构思惟路线知识点分享给你们。

一、高性能架构

• 性能优化如何理解
• JVM调优
• JAVA程序性能优化
• Tomcat
• Mysql

二、开源框架解析

• 1.spring概述
• 2.Spring 容器
• 3.Spring AOP
• 4.Spring MVC
• 5.Spring 5新特性
• 6.Mybatis

三、微服务架构

• SpringBoot
• SpringCloud
• Docker虚拟化技术
• Dubbo应用及源码解读

四、架构筑基

• 分布式环境指挥官Zookeeper
• 分布式消息通信 异步与MQ
• 分布式缓存 NoSql
• 数据存储
• 高并发分流技术Nginx
• 分布式文件存储fastdfs

五、团队协做开发

• Git
• Maven
• Jenkins
• Sonar

六、B2C商城项目实战

七、设计模式

若是须要以上高清的技术图的话能够关注一下我，以上知识点这边都有相应的视频讲解，一样能够免费获取。

须要获取Dubbo、Redis、设计模式、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术视频教程资料，架构思惟导图，和BATJ面试题及答案的，都是免费分享的。

能够关注一下我，主页有获取方式