企业官网建设流程全解析

每年校招季，核心系统工程师的笔试题都是被讨论最多的一类，因为岗位本身处在“底层基础设施”和“业务架构”的交界处，考察范围宽、深度要求也不低。百度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 常见问题速查表

4.2 我的备考复习路径

如果你现在才开始准备，我建议的复习路径是这么三步，顺序不能乱。

第一步：拉通知识体系，而不是零散刷题。找一个周末，把操作系统、网络、数据库、分布式这四块的主干思维导图画出来，每个节点只写关键词。画完你会发现自己的知识地图哪里有洞，后面再针对洞去补。这一步花的时间最长，但是回报最大。

第二步：针对高频考点做专项突破。高频考点不用我多说，网上总结一大堆：进程线程模型、内存管理、TCP/IP、DNS、HTTP、索引优化、事务隔离级别、CAP、一致性哈希、分布式事务、消息队列。每个考点不用看太多资料，找到一篇讲得透彻的文章吃透就够了，关键是找一台机器动手试一下。

第三步：做模拟题，严格限时。找一套风格接近的笔试题目，给自己定好时间，选择题限制在30分钟内完成，留下大块时间给设计题和编程题。做完之后无论分数多难看，一定要做复盘，把每道错题都整理成“我的错误—问题出在哪个知识点—正确解法是什么”的三段式笔记。

关于资料，我不建议上来就买一堆大部头。先看《深入理解计算机系统》的虚拟内存和异常控制流章节，《Linux高性能服务器编程》里的IO模型和Reactor模式，数据库部分重点看《高性能MySQL》的前半部分，分布式入门看看Raft的动画演示或者中文解读文章，就够了。等这些基础打牢，再想精进，再去看更深的源码级内容。

4.3 考场上的时间分配技巧

看到试卷先别急着做题，花5分钟整体浏览一遍，把题目按照“肯定会做的”“需要想想的”“完全没思路的”分类标号。答题顺序建议是：先做会做的，再做需要想想的，最后蒙完全没思路的。这样做的好处是保证基础分先到手，后面有剩余时间再啃硬骨头。

设计题如果没有思路，也要尽量写点东西。写一些基本需求分析，哪怕只是把条件列出来，也比留空白强得多。阅卷的时候，至少能看出你有分析框架。

编程题如果时间紧张，优先保证代码能编译运行，再谈优化。很多时候一部分用例跑过就能拿到可观分数，别因为追求最优解而把自己卡死在细节里。

5. 笔试之后的路：从做题到真正做事

很多人以为过了笔试就万事大吉，其实笔试只是第一道门槛。核心系统工程师这个岗位，面试时大概率还会再追问笔试中的某个设计题，让你细化某一部分，或者聊聊你自己做过的项目经历。如果笔试时只是临时背了一堆概念，没真正理解，面试时很容易露馅。

我在实际复习中带人的时候，发现了一个有意思的现象：能把笔试题里的某个知识点讲成一个完整故事的候选人，通过率明显更高。什么意思？比如讲“缓存穿透”，不只说“用布隆过滤器解决”，而是能讲出“之前在某次大促预热阶段，运营扫了一批不存在的商品ID直接打到数据库，我们当时怎么发现、怎么临时加的布隆过滤器、后来又怎么通过监控报警不断完善”的真实案例。这种结合实践的表达，比任何标准答案都有说服力。

建议所有准备这个岗位笔试的朋友，在刷题之外，一定要主动找机会动手做点小项目。比如自己搭一个高并发的短链服务、写一个简单的Raft共识算法Demo、用eBPF工具分析一次真实的性能瓶颈，这些实践经历会变成你笔试和面试中最宝贵的素材。

要特别提醒的是，不要陷在“面试套路”里不能自拔。核心系统工程师这个方向有一个很朴素的衡量标准：你是不是真的理解你维护的系统。如果你能说清楚一个请求从客户端到服务端的完整链路，能解释清楚每一个环节可能出现的问题，能给出对应的监控和容灾手段，那你不管是笔试还是面试都不会太差。

这套“百度2019校招核心系统工程师笔试题（第二批）”的复盘就到这里。最后再分享一个小技巧：每次做完一套题，别急着对答案，先尝试“自己出题”。把这道题的背景和答案倒过来，站在出题人角度想想“如果我需要检验别人会不会这个知识点，我会怎么出题”。当你能够出题时，考点就真正变成你自己的东西了。