高并发技术面试专题汇总，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架构思维路线知识点分享给大家。

1、高性能架构

性能优化如何理解

JVM调优

JAVA程序性能优化

Tomcat

Mysql

2、开源框架解析

1.spring概述

2.Spring 容器

3.Spring AOP

4.Spring MVC

5.Spring 5新特性

6.Mybatis

3、微服务架构

SpringBoot

SpringCloud

Docker虚拟化技术

Dubbo应用及源码解读

4、架构筑基

分布式环境指挥官Zookeeper

分布式消息通讯 异步与MQ

分布式缓存 NoSql

数据存储

高并发分流技术Nginx

分布式文件存储fastdfs

5、团队协作开发

Git

Maven

Jenkins

Sonar

6、B2C商城项目实战

7、设计模式