考完“2023年度小满春招基础架构研发岗第三批笔试”那天晚上我在备忘录里敲了一行字这张卷子不是在考你会不会写代码而是在考你有没有“架构师视角”。后来我把整场笔试从头到尾复盘了一遍越看越觉得这句话站得住。基础架构岗和业务研发岗的笔试差别非常大。业务岗喜欢出CRUD场景、并发编程、SQL优化基础架构岗则更关注你面对底层问题时的系统设计能力、性能敏感度和边界意识。第三批这套卷子题量不大但每一道都不白给。如果你正在准备类似岗位的校招这篇文章应该能帮你少走一些弯路。1. 从岗位JD看这张卷子基础架构岗笔试到底在筛什么人先交代一下这场笔试的基本盘面。在线笔试平台总时长120分钟题型分成三块单选和多选大概23道覆盖操作系统、网络、数据库、分布式基础两道编程题一道偏数据结构实现一道偏海量数据场景最后还有一道系统设计题要求用文字加伪代码描述方案。整体节奏是前面的客观题不能恋战后面的大题才是拉分项。我在备考阶段认真研究过基础架构研发岗的岗位JD里面有几条高频描述熟悉Linux环境与网络协议栈、理解分布式系统常见理论与组件、具备扎实的编码功底和性能意识、对高并发高可用场景有基本认知。这些能力要求反过来决定了笔试题的出题方向。业务研发岗更看重你“能不能把需求做出来”基础架构岗更看重你“能不能把系统做稳、做快、做可扩展”。这套卷子有很明显的层次感。第一层是“基础题”比如进程与线程的区别、TCP挥手过程、索引失效场景属于学过就能答的送分题第二层是“进阶题”比如缓存一致性、消息队列可靠性、分布式锁选型需要你有过实际项目经验或系统阅读过相关原理第三层是“区分度题”比如那道系统设计题和手写题光背八股不够得能展示出设计取舍和代码实现质量。我在考场上最大的感受是时间够用但思考量很大。客观题里至少有四五道不是直接背结论能答的它给了具体场景比如“某服务在峰值时CPU使用率飙升可能的原因有哪些”这种题需要你做发散性分析。编程题和设计题则需要预留足够时间。如果你按“选择题30分钟、编程题50分钟、设计题40分钟”的节奏分配会比较从容千万不能在前面的八股题上死磕。基础架构方向的笔试还有一个隐藏考察点你在方案设计里能不能表现出对成本和复杂度的敏感。业务代码面向功能基础架构代码面向规模这个差异贯穿整张卷子。2. 设计题拆解一道分布式ID生成器背后的系统设计考点2.1 题目还原与我的第一反应第三批笔试的压轴设计题大概是这样的设计一个分布式ID生成服务要求全局唯一、趋势递增、平均时延低于5ms、可用性不低于99.95%并说明你的方案在时钟回拨、性能瓶颈、扩展性三方面如何处理。这道题非常典型它把“分布式系统设计”这个抽象概念压缩到了“造ID”这个具体的点上但又处处考察你的系统设计功底。我第一反应是雪花算法因为它的“用一个64位long承载时间戳机器ID序列号”的思路在技术上已经被各大厂验证过且能天然满足趋势递增的要求。但我很快意识到如果只写“用雪花算法”这道题大概率只能拿一半分。它问的是“设计一个服务”不是“说一个算法”。基础架构岗设计题的评分点往往藏在细节里我归纳下来至少有四个层次一是方案能不能满足题目给出的硬性指标二是对边界问题的处理是否成体系三是伪代码和架构描述是否清晰四是能不能主动说出方案的局限性和替代方案。2.2 候选方案的取舍逻辑考场上的思考路径应该是一张“方案对比表”把常见方案过一遍而不是直接跳到终极答案。我按这个思路整理过四个方案的对比方案有序性时延表现主要瓶颈适用场景UUID无序低存储索引效率差无需排序的内部标识数据库自增ID强有序中单库性能上限低并发传统业务Redis原子自增强有序低依赖Redis高可用短时效ID雪花算法变体趋势递增极低时钟回拨大规模分布式系统以数据库自增ID为例它能保证绝对有序但在“平均时延低于5ms、可用性不低于99.95%”这个约束下会非常吃力。单库自增扛不住高并发分库分表后又要处理步长和起始值的协调这种方案天然和“大流量下的分布式场景”冲突。UUID则完全不适合它虽然生成快但无序的特征会让数据库的B树索引频繁页分裂写入性能随着数据量增长急剧下降。雪花算法胜出并不在于它性能无敌而在于它把“生成ID”的职责分散到了每个节点上每个节点只用自己的机器ID加本地时间戳和序列号做拼接不需要网络通信这个去中心化的特点让它天然具备高可用性。我当时在卷子上画了一个简单的架构框客户端通过HTTP或者RPC请求ID生成服务服务层由多台无状态节点组成每台节点内部按雪花算法生成ID节点启动时从协调组件申请全局唯一的workerId。服务层前面挂负载均衡整体架构非常简单。2.3 评分点基础架构岗想看的是“边界意识”这道题精妙的地方在于它特意点名了时钟回拨。很多人知道雪花算法但不知道雪花算法有个经典问题它依赖机器本地时间戳一旦机器时钟发生回拨比如NTP校准就可能生成重复ID这在分布式系统里是致命的。我在答题时给出了三层处理策略。第一层是“快速拒绝”如果回拨幅度小于某个阈值比如5ms直接抛出异常或短暂阻塞请求等待时间追平第二层是“备用序列号”当检测到回拨时不再借用时间戳而是复用上一毫秒的序列号空间并用算法规避冲突第三层是“外部协调兜底”如果回拨幅度很大节点应该主动摘除自己从服务注册中心下线避免继续分配可能冲突的ID。这三层策略正好体现了“感知风险、分级处理、兜底恢复”的架构思维。关于性能瓶颈我也强调了一点单节点雪花算法的吞吐上限大约在每秒百万级大多数业务场景已经够用真正的瓶颈不在算法本身而在接入层的连接管理和序列号分配的锁竞争。因此我补充了一个优化方案即每个节点可以同时维护多个序列号空间用分段的方式进一步降低锁的粒度。这道题整个答下来我认为它考察的并不是“你知不知道雪花算法”而是你面对一个真实系统约束时能不能有条理地组织方案、识别风险、给出应对措施。这也是基础架构岗区别于业务岗的核心能力模型。3. 原题复盘缓存、消息队列、分布式锁的高频变体3.1 缓存穿透/击穿/雪崩的处理套路这套选择题和简答题里缓存相关的内容出现了不止一次。有一道多选题是这么问的“某服务引入了Redis缓存来降低数据库压力但在某个大促场景下数据库连接数依然被打满可能的原因有哪些”这道题把缓存穿透、击穿、雪崩三个概念整合进了一个场景里需要你区分清楚。我的答题思路是这样展开的如果大量请求的key在缓存和数据库中都不存在就会绕过缓存直击数据库这是缓存穿透解决方案是缓存空值加短过期时间或者用布隆过滤器在最前面挡一层如果某个热点key在过期瞬间被超高并发请求同时打到数据库这是缓存击穿解决方案是热点数据不设置过期时间、后台异步更新或者用互斥锁控制只有一个请求去回源如果大量key在同一时间集中失效导致数据库瞬时压力飙升这是缓存雪崩解决方案是给过期时间加随机扰动、做多级缓存、利用熔断限流保护下游。这里有一个容易漏掉的点缓存和数据库之间的数据一致性。我在回答中补充了Cache Aside模式的核心逻辑——读的时候先读缓存读不到就读数据库并回填写的时候先更新数据库再删除缓存。删除缓存这一步是关键因为并发场景下更新数据库和写缓存的顺序一旦反了大概率出现脏数据。这道题的教训是基础架构方向的应试不能只背“穿透、击穿、雪崩”六个字面试官和出题人更想看的是你能不能在具体场景里组合使用这些防御手段。3.2 Kafka重复消费与幂等方案消息队列相关的题考了一道简答题大意是“RocketMQ或Kafka在消费端为什么可能收到重复消息如果业务要求消息不能重复生效你会怎么设计”这道题我认为出得非常好因为它考察的是对分布式系统现实约束的理解。首先消息队列的重复消费是一个“理论上无法绝对避免”的问题。Kafka的消费模型里消费端处理完消息后需要提交offset如果消息处理成功但offset提交失败或者消费端在提交前宕机重启后就会从上一个已提交offset重新拉取消息此时业务上就收到了重复消息。这是一个典型的“at least once”语义是很多消息队列的默认选择。针对重复消费我的解决方案是“消费幂等化”加“业务去重表”。幂等化要求业务操作本身天然支持重复执行比如扣减库存时不仅校验数量还要求订单号在业务侧唯一。更通用的做法是引入一张去重表消费端在执行业务逻辑前先以消息的唯一Key比如订单号或消息ID查去重表如果存在就跳过不存在则插入并执行业务利用唯一索引做并发兜底。这里我特意强调了一个细节幂等表必须和业务数据在同一数据库且通过本地事务原子提交。如果去重表在Redis里Redis和数据库之间就没有原子性保证极端情况下会“已记录去重Key但业务数据未更新”反而引发更大的问题。这个细节是我在看过一些实践案例后总结出来的考场上把它写出来会很加分。3.3 分布式锁的三种实现对比分布式锁几乎可以算基础架构方向笔试的必考题。这场的题型没有直接问“分布式锁怎么做”而是给了一个场景“多个实例同时处理定时任务如何保证同一时刻只有一个实例在运行”这就是分布式锁的经典应用。我在答题时做了三个方案的对比并把它们的异同点写清楚了第一种是基于Redis的SETNX加锁。SET key value NX PX 30000这条命令可以原子地完成“不存在才设置”和“设置过期时间”两个动作是最常见的实现方式。但它有两个问题一是锁过期后如果业务还没执行完另一个实例就能抢到锁会对共享资源造成并发访问二是Redis主从切换时可能出现锁丢失。针对前者需要引入看门狗机制在锁快过期时自动续期针对后者需要使用Redlock算法但Redlock本身也有争议我如实指出它并非绝对安全。第二种是基于ZooKeeper的临时顺序节点。客户端创建一个临时顺序节点如果自己是序号最小的那个就获得锁否则监听前一个节点的删除事件。ZooKeeper方案的优势是“客户端异常断开时临时节点自动消失”不会出现死锁劣势是锁的获取和释放需要多次网络RTT性能比Redis低。第三种是基于数据库的唯一索引利用INSERT语句尝试插入一条锁记录插入成功即获锁删除记录即释放锁。性能最差但在强一致场景下简单可靠。最后我给出了一个实战倾向性的建议高并发但允许极小概率锁失效的场景用Redis对强一致要求极高且并发量不夸张的场景用ZooKeeper。在系统设计面试里能给出一套带前提条件的结论比“XX方案一定更好”更有价值。4. 基础题里的硬功夫操作系统与网络方向不能再丢分4.1 零拷贝消息队列高性能的底层抓手这套选择题里有一道关于零拷贝的题问的是“Kafka为什么能支撑高吞吐”。选项里涉及sendfile、mmap、用户态与内核态切换等概念。这道题考的是操作系统层面的IO路径理解。常规的数据读取与发送路径是磁盘文件 - 内核缓冲区page cache - 用户态缓冲区 - Socket缓冲区 - 网卡。数据在内存里被拷贝了四次还经历了四次用户态与内核态的切换每一次拷贝和切换都有成本。零拷贝的思路正是为了干掉这个路径上的冗余环节。sendfile系统调用可以让数据直接在内核空间完成“文件 - Socket”的传输不需要经过用户态也不需要应用进程自己搬运缓冲区只是简单地把文件描述符和Socket描述符传给内核。Kafka的日志读写大量利用了page cache和零拷贝机制所以它能把吞吐做得极高同时CPU占用很低。mmap则是把磁盘文件的映射关系直接放进进程地址空间应用读写内存的某个区域内核在后台负责把脏页刷回磁盘。RocketMQ的存储层对mmap的使用非常经典它将commitlog和ConsumeQueue以内存映射的方式操作兼顾了读写性能和开发便利性。这道题给我的启发是基础架构方向的考生不能只停留在“会用框架”的层面必须能向下拆一层。你用的是Kafka、RocketMQ、Redis但它们的性能优势最终都落到操作系统的内核机制上这正是基础架构研发岗的日常。4.2 IO多路复用为什么面试官总把epoll挂在嘴边网络方向有一道选择题直接问“select、poll和epoll的区别”并给出了几个特征描述让我判断对错。它考到了epoll的三个核心机制红黑树管理监听集合、事件驱动回调机制、mmap发送就绪事件数组。select和poll的底层逻辑都是“轮询”每次调用时把全部文件描述符集合从用户态复制到内核态内核遍历所有fd检查是否有事件发生再把结果复制回用户态应用还要再次遍历才知道哪些fd可读可写。这种方式有两个硬伤一是fd数量大了以后O(n)的遍历开销非常明显二是每次调用都要在用户态和内核态之间拷贝完整集合性能损耗很大。epoll的出现就是针对这两个硬伤做优化。它通过一个epoll_ctl接口把要监听的fd注册进内核的一棵红黑树后续不需要重复全量拷贝内核通过中断回调机制只把真正发生事件的fd放进一个就绪链表应用用epoll_wait时只需要从就绪链表里取出发生事件的fd复杂度从O(n)降到了O(事件数)。Redis为什么能单线程支撑十万级QPS核心之一就是它用了基于IO多路复用的事件循环在等待网络事件时不会被阻塞。Nginx、Netty都是同样的底层思路。基础架构研发岗天天在和这类高并发框架打交道如果不懂epoll看性能问题就会像隔着一层雾。4.3 TIME_WAIT、长连接与连接池的取舍我对这道题印象很深它是一个实际问题场景“某服务通过Nginx对外提供HTTP端口高并发时用ss -s发现系统有大量TIME_WAIT连接服务端处理能力下降应该怎么处理”这是一个典型的生产问题也是基础架构笔试比常规八股题更有意思的地方。TIME_WAIT出现的根源是TCP四次挥手中主动关闭连接的一方需要等待2MSL时间确保最后一个ACK被对端收到防止旧连接的数据包干扰新连接。如果短连接请求量巨大服务端作为主动关闭方系统里就会堆积大量TIME_WAIT连接。大量的TIME_WAIT本身不占用太多内存但会占用本地端口资源达到上限后新连接无法建立。我的解答分了几层。第一层是优先考虑长连接HTTP/1.1的Keep-Alive和HTTP/2的多路复用能显著减少连接建立和断开的频率。从业务形态看长连接能把“每次请求都经历三次握手和四次挥手”的高昂成本摊平。第二层是调整内核参数比如net.ipv4.tcp_tw_reuse允许将处于TIME_WAIT状态的连接用于新的TCP连接或者调低net.ipv4.ip_local_port_range让本地可用端口范围更大但这些参数的调整有前提必须理解其副作用。第三层是引入连接池比如数据库连接池、Redis连接池本质都是复用连接而不是每次新建。这道题最值得学习的地方是它把TCP协议栈的理论问题和实际运维场景打通了。这种“理论落不到实践”的能力恰恰是基础架构岗笔试和面试最看重的。5. 手写题质量LRU与TopK的隐藏评分标准5.1 LRU缓存双向链表之外的并发与面试官心理第三批笔试有两道编程题第一道是手写LRU缓存要求实现get(key)和put(key, value)容量为capacity要求get和put的时间复杂度都是O(1)。这是一道出现频率极高的经典题但我发现很多人对它的理解仅限于“HashMap加双向链表”实际上这道题在基础架构岗笔试中还有更深的考察维度。核心数据结构是HashMap加双向链表。HashMap负责O(1)查找双向链表负责维护访问顺序链表头部是最近访问过的节点链表尾部是最久未使用的节点。get时把命中的节点摘下来放到头部put时先检查key是否存在存在则更新value并移动到头部不存在则判断容量是否已满满了就删除尾部节点并同步从HashMap中删除然后新建节点插入头部。下面是我在考场上写的核心实现支持泛型和容量控制import java.util.HashMap; import java.util.Map; public class LRUCacheK, V { static class NodeK, V { K key; V value; NodeK, V prev; NodeK, V next; Node(K key, V value) { this.key key; this.value value; } } private final int capacity; private final MapK, NodeK, V map new HashMap(); private final NodeK, V head new Node(null, null); private final NodeK, V tail new Node(null, null); public LRUCache(int capacity) { this.capacity capacity; head.next tail; tail.prev head; } public V get(K key) { NodeK, V node map.get(key); if (node null) { return null; } moveToHead(node); return node.value; } public void put(K key, V value) { NodeK, V node map.get(key); if (node ! null) { node.value value; moveToHead(node); return; } if (map.size() capacity) { NodeK, V removed removeTail(); map.remove(removed.key); } NodeK, V newNode new Node(key, value); addToHead(newNode); map.put(key, newNode); } private void moveToHead(NodeK, V node) { removeNode(node); addToHead(node); } private void addToHead(NodeK, V node) { node.next head.next; node.prev head; head.next.prev node; head.next node; } private void removeNode(NodeK, V node) { node.prev.next node.next; node.next.prev node.prev; } private NodeK, V removeTail() { NodeK, V node tail.prev; removeNode(node); return node; } }不难发现所有对链表的修改操作都必须保持和HashMap的一致性这是这道题最容易写错的地方。比如更新已有key时我只改value并把节点移到头部不能新建节点否则HashMap里引用会错乱。删除尾部节点时必须拿它的key去map.remove所以链表的每个节点都要同时持有key和value这一点很容易被忽略。但仅仅“写对”在这道题里不够。基础架构岗的笔试环境通常会额外考察一个细节并发场景下这个LRU是否安全。我在答题时特意注明上述实现是单线程版本如果要在多线程环境下使用可以在get和put方法上加synchronized但性能会下降更优的做法是使用java.util.concurrent.LinkedBlockingQueue等并发容器做组合或者在关键路径上使用读写锁因为读操作远多于写操作。这道题揭示了一个基础架构岗位的隐藏评分标准功能实现是底线并发意识、性能意识和代码可维护性才是加分项。你在卷面上展现出来的思考深度往往比代码本身更能影响最终的评价。5.2 TopK问题海量数据场景的思维分水岭第二道编程题是TopK的变体“给定一个包含数十亿整数的文件单机内存只有512MB找出出现频率最高的100个整数。”这道题表面上是算法题实际上是一道分布式与海量数据处理题它非常符合基础架构岗的定位。最简单的做法是维护一个容量为100的小顶堆遍历所有元素时比较堆顶如果新元素比堆顶大就替换并调整堆。这种方式的时间复杂度是O(n log k)其中k100内存占用只有O(k)完全能处理大规模数据。但是这道题的变体加了“数十亿”和“512MB”两个约束这意味着不能把全部数据一次性加载进内存做排序“读一个处理一个”的方式才是正解。海量数据场景下的推荐思路是**“分而治之”加“外部排序”**。先把大文件切分成若干个小文件每个小文件的大小控制在当前机器可接受的内存范围内然后逐个小文件加载进内存用HashMap统计每个整数在文件内的频次得到每个小文件的TopK候选集最后把所有小文件的结果再做一次汇总。关键词“外部排序”和“多路归并”应该出现在你的思路里因为它们体现了你对“内存放不下”这个前提的敬畏。有一个很典型的错误思路是直接用Java的HashMapInteger, Long countMap装所有整数的频次。在数十亿数据规模下这个map会占用远超512MB的内存直接OutOfMemoryError。这道题真正的价值就在这里——它逼着你从单机内存的物理限制出发思考方案的可行性这正是基础架构研发岗日常里做容量评估和性能优化的核心能力。我在答题时也补充了一个工程化细节切分文件时不能只按顺序读固定字节否则同一个整数会被拆到两个文件里计数就会出错。应该按“整数边界”切分或者用哈希取模的方式把相同整数映射到同一个分片。哈希分片的另一个好处是天然支持多机并行比如用hash % M把数据分到M台机器每台机器独立统计后汇聚就把单机TopK扩展成了分布式TopK。这个思路一旦点出来就会显得你站在系统设计的角度思考问题而不仅仅是在做一个算法题。6. 考后的复盘清单基础架构方向校招笔试的准备路径6.1 从往年JD反推考点优先级第三批笔试考完之后我把所有考点和岗位JD做了一次对照得到了一个相对清晰的复习优先级。如果你是准备基础架构研发岗笔试的在校生这个清单可以直接参考。优先级考点方向典型题目复习资源建议高操作系统与Linux零拷贝、进程线程、内存管理经典教材的IO与进程章节高网络协议栈TCP/UDP、TIME_WAIT、IO多路复用Wireshark抓包对照复习高分布式系统原理一致性、分布式锁、消息可靠、缓存系统设计类博客与PDF高算法与数据结构LRU、TopK、海量数据处理刷题平台高频题Tag中数据库索引、事务隔离级别、锁数据库原理课程中编程语言底层JVM内存、GC、集合源码对应语言的性能调优文档从优先级分布可以看出基础架构岗笔试不是“数据库大厂刷题”的思路它更看重计算机底层原理的扎实程度。操作系统和网络之所以排在前面是因为所有分布式组件都构建在这两层之上。你不理解page cache就没法真正理解Kafka的写入性能你不理解TCP状态机就没法排查线上大量的TIME_WAIT问题。数据库方向我把它排在中优先级是因为大部分基础架构岗位对数据库的要求更偏向“能用、懂原理、能排查慢查询”不会像DBA岗那样深挖存储引擎源码。但索引失效、事务隔离级别、MVCC这些仍然要烂熟于心因为它们在选择题里出现的频率非常高。6.2 时间分配与做题节奏我在这批笔试里踩过的一个小坑是在选择题上花了超过40分钟导致最后设计题只写了35分钟左右时间偏紧张。这个问题在复盘时让我印象很深。后来我给自己定了一套更合理的时间分配策略对基础架构岗这种“前快后重”的卷子比较适用。常规策略是“选择题30分钟、编程题50分钟、设计题40分钟”。选择题部分如果一道题超过90秒还没有确定思路就先标记跳过不要恋战大部分客观题都是单选蒙一个之后做记号等后面有回旋余地再回头检查。选择题的目标不是满分而是快速拿到该拿的分把时间留给真正的硬骨头。编程题我坚持“先写测试用例再写实现”的顺序。先用三个用例把输入输出边界理清楚比如空输入、单元素、容量为1、满容量覆盖然后再动笔写核心逻辑。手写题最常见的丢分点不是思路错误而是边界处理不到位。设计题则要坚持“先列评估指标再画架构最后写伪代码”的顺序。哪怕时间不够架构和指标写出来了评分老师也能看到你的思考框架如果只倒在一段代码里可能连方案的完整性都看不出来。6.3 我踩过的坑和后续复习调整复盘时我发现自己在基础题部分丢了两个不该丢的分这里如实分享一下大家当反面教材。第一个坑是“学过不等于能辨析”。选择题里有一道关于进程和线程的题选项写道“线程是资源分配的基本单位”我一眼扫过去觉得“说得对”正选就选了它结果这是错的。进程才是资源分配的基本单位线程是CPU调度的基本单位。这种题考得非常细而且它是以“辨错”的方式出现的。我的教训是复习基础知识时不能只背结论要能主动说出“为什么是A不是B”可以自己给自己出这种改错题。第二个坑是“对方案设计题的认识太浅”。我最初以为设计题只要把主流方案比如雪花算法写出来就行考完之后才意识到方案设计题得分的关键在于“多版本演进”。你只给出最终方案老师只能看到你记住了答案你给出“从简单方案到复杂方案”的演进过程并说明每个版本为什么被淘汰老师才能看到你的系统设计能力。比如分布式ID那题你可以先提UUID再说它无序再提数据库自增再说它瓶颈最后引出雪花算法并说明你对时钟回拨的应对。这个“排除法”本身就是设计能力的体现。考完之后我的复习重心做了三个调整一是把操作系统和网络的基础概念做成“正误辨析卡片”每天抽一遍二是刷题时不再只求AC而是给每个手写题补充“并发版本”和“内存优化版本”锻炼自己从不同层面思考同一个问题三是每看完一个分布式组件的知识点就尝试用一张A4纸画出它的架构和核心流程画不出来的地方就是复习盲区。这套调整在后续的笔试和面试中帮助很大也推荐给正在准备基础架构方向的同学。回到这场笔试本身我个人的体会是基础架构研发岗的考察重心从来不在“你知道多少新框架”而在“你对底层原理的理解能否支撑你在复杂系统中做出正确的架构决策”。一张笔试卷未必能完全反映一个人的能力但它至少能帮你看清自己的知识盲区在哪里。如果你也在准备类似的岗位不妨找一套往年的笔试题目卡着时间完整做一遍再按照上面提到的“考点优先级”和“踩坑清单”逐项过一遍这个过程本身的价值可能比刷十套题都要大。