每年校招季核心系统工程师的笔试题都是被讨论最多的一类因为岗位本身处在“底层基础设施”和“业务架构”的交界处考察范围宽、深度要求也不低。百度2019校招核心系统工程师笔试题第二批在网上流传度很高评论区一半人在喊难一半人在对答案。我陆续整理过好几版也拿这套题给团队里准备跳槽的候选人做过模拟越看越觉得它很适合作为系统工程师岗位的“通用能力体检表”。这篇文章不打算按“标准答案”一条条念而是把第二批试题当做一个样本拆一拆它到底在考什么、为什么这么考、以及你复习时应该怎么准备。虽然时间过去几年了但这类岗位的笔试底层逻辑基本没变考点还是那些考点套路也还是那些套路。无论你是准备校招、社招跳槽还是单纯想验证自己的系统知识体系有没有漏洞这篇内容都值得认真看一遍。1. 考题全貌第二批笔试到底在筛选什么人先说整体感受。百度2019校招核心系统工程师笔试题第二批给我的第一印象是客观题部分覆盖面很广主观题部分动手味道很重。它不像很多公司那样靠十几道选择题应付了事而是专门留了比较大篇幅的场景分析题和系统设计题这点和“核心系统工程师”这个岗位的定位是直接挂钩的。1.1 试卷结构与考察逻辑从网上能拼凑出来的信息看第二批试卷大致分成四个板块基础题、系统原理题、场景设计题、编程题。基础题以选择题和填空题为主集中在操作系统、计算机网络、数据库原理系统原理题偏向Linux内核、存储、虚拟化场景设计题则是给一个具体的业务背景让你设计方案编程题通常是算法题但比纯算法岗位的难度要低一些更注重工程实现能力。这里面的考察逻辑很清晰它不是在找“背八股文最熟练的人”而是在找“能理解系统运行机制、能定位线上故障、能独立做技术方案”的工程师。所以你会发现像“进程和线程的区别”“TCP三次握手”这类基础题通常只占很小一部分真正拉开分数差距的是后面那些需要综合知识的题目。1.2 岗位画像决定考点范围核心系统工程师在百度内部属于技术基础设施方向负责的东西往往是大规模分布式存储、计算资源调度、网络架构、CDN、数据库集群这一类“离业务稍微有点远但一旦出问题就是重大事故”的系统。这个岗位画像是很清晰的它需要三类硬技能对操作系统和计算机体系结构有深入理解因为很多性能问题最终都要落到CPU调度、内存分配、磁盘IO这些底层机制上对分布式系统有系统性的认知包括一致性协议、容错、负载均衡、缓存策略等具备很强的动手排查能力能熟练使用各种系统工具分析线上问题。第二批试题基本就是按照这个画像来出题的覆盖面广但重心突出考的东西都有明确指向性。2. 高频考点逐个拆边拆边说解题逻辑接下来的内容我按照“考点—典型考查方式—解题逻辑”三个维度来复盘。不要死记答案要重点理解背后的思考链条因为同类岗位的笔试再怎么变底层考点是那几块。2.1 操作系统从原理背书写到参数调优操作系统在试卷里占了相当大的比重。除了“进程与线程的区别”“虚拟内存的作用”这类入门题目有价值的是那些交叉考察的题比如给一段多线程代码让你分析并发访问共享变量时可能出现的结果给你一个系统负载很高的场景让你判断瓶颈究竟在CPU、内存还是磁盘IO考察Linux下某个系统调用或内核参数的作用比如mmap、epoll、swappiness等。解题逻辑上这类题目考察的是你“能不能用原理来解释现象”。以多线程的题目为例单纯的“加锁”只是标准答案的皮毛更好的回答应该包含为什么需要锁原子性和可见性、锁的粒度怎么选择是锁整个大对象还是缩小临界区、乐观锁和悲观锁各自的适用场景。我见过很多候选人选择题能拿高分但一到分析题就露馅因为习惯把课本上的优缺点背下来却很少结合真实场景去解释。比如问到你线上遇到过CPU使用率100%但业务延迟不高怎么排查很多人的第一反应是看top但进一步问为什么top显示用户态CPU高和内核态CPU高处理思路完全不同用户态高大概率是业务逻辑或计算密集而内核态高可能涉及系统调用频繁、锁竞争甚至硬件中断处理方向完全不一样。2.2 网络协议不能只背握手挥手网络部分的题目同样有层次感。基础题可能让你填TCP报文的头部字段或者判断滑动窗口的作用进阶题则贴近生产环境比如假如客户端访问服务端超时你怎么一步步排查为什么TIME_WAIT状态大量出现怎么优化解释HTTP/2的多路复用和TCP队头阻塞问题。网上关于TIME_WAIT的讨论很多第二批试题里也出现过类似场景。很多人一股脑说“调小TIME_WAIT超时时间和端口复用参数”但实际场景中这种操作并不总是正确的。如果你负责的是一个高并发的短连接服务端口耗尽才是真正的问题net.ipv4.tcp_tw_reuse在一些内核版本下可能有副作用修改之前得先搞清楚链路是NAT还是直连。遇到网络类题目时我建议在脑子里建立一个“端到端排查链”从客户端DNS解析开始到TCP连接建立、TLS握手、服务端接收、处理、返回再到客户端收到响应。任何一个环节都可能出问题答题时把这条链路讲清楚分数自然就上去了。2.3 分布式系统一致性、容错和性能的铁三角情景设计题中分布式系统是绝对重点。比如给一个分布式KV存储的场景要求你设计一个高可用方案或者给一个微服务调用链要求你分析可能出现的数据不一致问题。常见的考点包括CAP理论如何落地既然三者不可兼得你的系统要优先保证什么一致性协议的基本思想Raft的Leader选举、日志复制、安全性的本质是什么分布式缓存和数据库的一致性问题先更新缓存还是先更新数据库缓存为什么会被穿透、击穿、雪崩怎么解决分布式锁用Redis还是ZooKeeper各自的优势和坑是什么拿“先更新数据库还是先删除缓存”这道经典题来说简单版本里大家都会说“先更新数据库再删除缓存”但深挖进去其实有一堆问题删除缓存失败了怎么办如果采用延迟双删延迟时间设置为多少比较合理是否可以用订阅数据库binlog的方式异步删除缓存能不能接受短时间内的不一致这说明分布式考察的不是结论而是权衡。在答这类题时有一个很重要的思维习惯先明确约束条件再给方案。你的方案取决于数据一致性要求、并发量、成本预算。没有这些约束任何方案都可以被挑毛病。2.4 场景题别一上来就写方案第二批试卷的场景设计题中有一类非常典型的考法给你一个具体业务比如数亿用户的大规模消息推送系统要求你设计整体架构。很多候选人的第一反应是画一个包含Nginx、Redis、Kafka、数据库的架构图但图其实只是结果。好的回答应该首先把需求搞清楚推送的实时性要求多高消息大小和频率如何用户在线和离线的处理逻辑是什么需要保证消息顺序吗失败重试的机制怎么做这些问题问完之后架构方案自然就出来了。这个“先澄清需求再设计方案”的能力恰恰是校招生最容易缺的也是面试官在笔试环节最想看的能力。3. 实操复盘一道系统设计题从思路到落地的完整过程很多刚准备笔试的人有一个误区主观题就是“写作文”把自己的想法写上去就行。实际上场景设计题的得分点有很大一部分隐藏在“有没有考虑边界条件”和“方案能否落地”上。我拿一道和第二批风格很像的题目展开分析帮你看清楚什么叫“完整作答”。3.1 题目与初步分析假设题目是设计一个分布式短链服务要求支持高并发写入和读取短链不能重复访问时能够快速跳转。看到这个题脑子里第一时间应该冒出几个关键问题短链生成的算法是什么用什么保证不重复存储层选什么关系型数据库还是NoSQL读多写少还是写多读多需要什么样的缓存策略短链的过期策略是什么怎么清理如果能在答题纸上把这些约束条件列出来再开始设计就已经领先大多数人了。3.2 分模块设计我会把方案拆成四个子模块来写发号器、存储、读取链路、清理任务。发号器是短链服务的核心。最简单的方案是用数据库自增ID但高并发下数据库单点压力大。更常见的做法是用号段模式发号服务每次从数据库取一批ID比如1000个在内存里分配用完了再去取达到降低数据库压力的效果。再加上多节点部署时引入“步长区分”或者使用Snowflake算法生成全局唯一ID就能保证发号阶段不重不漏。存储选型上短链场景读多写少、key-value访问特征非常明显所以一般用Redis做缓存层底层存储用MySQL或者TiDB这类分布式数据库。写的时候先落库再写缓存读的时候先查缓存未命中再查库并回填。读取链路需要注意的问题有两个缓存穿透和热点key。缓存穿透可以用布隆过滤器在访问前过滤不存在的短链或者把空值也缓存短时间热点key可以用多级缓存或者把同一key的副本分散到不同节点减少单个Redis实例的压力。清理任务可以用延迟队列或者定时扫描两种方式处理过期短链。定时扫描容易产生无效扫描延迟队列更精准但需要额外引入消息队列组件复杂度会上升。3.3 答题时的加分细节加分的细节往往藏在“容灾”和“一致性”上。比如发号器挂了怎么办有没有备用发号通道数据库主从切换时缓存里的数据和库数据不一致怎么办短链跳转要埋点统计吗如果系统要统计点击量异步上报的链路怎么设计这些内容不一定每个都写在最终答案里但只要能覆盖两三个就能让阅卷人看出你的系统思维。4. 常见错误与备考避坑指南这部分是我最想聊的。我带过不少校招生复习发现他们的错法高度一致而且很多错误在即使用同一套题做了三遍之后依然存在。这里不藏私直接列出来。4.1 常见问题速查表典型错误具体表现正确思路只背结论不给推导答“用B树做索引”但不说清为什么B树适合磁盘存储补充磁盘预读特性、页大小、多路搜索树降低IO次数场景题不澄清需求直接画架构图忽略数据的量级、一致性要求等关键约束先列问题清单再给方案忽略边界情况分布式锁只讨论正常加锁解锁不讨论锁过期、羊群效应补充锁续期、看门狗、重入场景的思考误以为讲得多就得分把了解到的所有方案全堆上去围绕“最核心的限制条件”组织答案突出取舍操作题靠想象让你写一条排查命令凭记忆默写不确定参数含义平时多敲多跑边跑边看man文档理解每个字段4.2 我的备考复习路径如果你现在才开始准备我建议的复习路径是这么三步顺序不能乱。第一步拉通知识体系而不是零散刷题。找一个周末把操作系统、网络、数据库、分布式这四块的主干思维导图画出来每个节点只写关键词。画完你会发现自己的知识地图哪里有洞后面再针对洞去补。这一步花的时间最长但是回报最大。第二步针对高频考点做专项突破。高频考点不用我多说网上总结一大堆进程线程模型、内存管理、TCP/IP、DNS、HTTP、索引优化、事务隔离级别、CAP、一致性哈希、分布式事务、消息队列。每个考点不用看太多资料找到一篇讲得透彻的文章吃透就够了关键是找一台机器动手试一下。第三步做模拟题严格限时。找一套风格接近的笔试题目给自己定好时间选择题限制在30分钟内完成留下大块时间给设计题和编程题。做完之后无论分数多难看一定要做复盘把每道错题都整理成“我的错误—问题出在哪个知识点—正确解法是什么”的三段式笔记。关于资料我不建议上来就买一堆大部头。先看《深入理解计算机系统》的虚拟内存和异常控制流章节《Linux高性能服务器编程》里的IO模型和Reactor模式数据库部分重点看《高性能MySQL》的前半部分分布式入门看看Raft的动画演示或者中文解读文章就够了。等这些基础打牢再想精进再去看更深的源码级内容。4.3 考场上的时间分配技巧看到试卷先别急着做题花5分钟整体浏览一遍把题目按照“肯定会做的”“需要想想的”“完全没思路的”分类标号。答题顺序建议是先做会做的再做需要想想的最后蒙完全没思路的。这样做的好处是保证基础分先到手后面有剩余时间再啃硬骨头。设计题如果没有思路也要尽量写点东西。写一些基本需求分析哪怕只是把条件列出来也比留空白强得多。阅卷的时候至少能看出你有分析框架。编程题如果时间紧张优先保证代码能编译运行再谈优化。很多时候一部分用例跑过就能拿到可观分数别因为追求最优解而把自己卡死在细节里。5. 笔试之后的路从做题到真正做事很多人以为过了笔试就万事大吉其实笔试只是第一道门槛。核心系统工程师这个岗位面试时大概率还会再追问笔试中的某个设计题让你细化某一部分或者聊聊你自己做过的项目经历。如果笔试时只是临时背了一堆概念没真正理解面试时很容易露馅。我在实际复习中带人的时候发现了一个有意思的现象能把笔试题里的某个知识点讲成一个完整故事的候选人通过率明显更高。什么意思比如讲“缓存穿透”不只说“用布隆过滤器解决”而是能讲出“之前在某次大促预热阶段运营扫了一批不存在的商品ID直接打到数据库我们当时怎么发现、怎么临时加的布隆过滤器、后来又怎么通过监控报警不断完善”的真实案例。这种结合实践的表达比任何标准答案都有说服力。建议所有准备这个岗位笔试的朋友在刷题之外一定要主动找机会动手做点小项目。比如自己搭一个高并发的短链服务、写一个简单的Raft共识算法Demo、用eBPF工具分析一次真实的性能瓶颈这些实践经历会变成你笔试和面试中最宝贵的素材。要特别提醒的是不要陷在“面试套路”里不能自拔。核心系统工程师这个方向有一个很朴素的衡量标准你是不是真的理解你维护的系统。如果你能说清楚一个请求从客户端到服务端的完整链路能解释清楚每一个环节可能出现的问题能给出对应的监控和容灾手段那你不管是笔试还是面试都不会太差。这套“百度2019校招核心系统工程师笔试题第二批”的复盘就到这里。最后再分享一个小技巧每次做完一套题别急着对答案先尝试“自己出题”。把这道题的背景和答案倒过来站在出题人角度想想“如果我需要检验别人会不会这个知识点我会怎么出题”。当你能够出题时考点就真正变成你自己的东西了。