蘑菇街PaaS笔试复盘：从Java基础到容器与分布式架构

前阵子帮几个学弟复盘蘑菇街2019届实习生PaaS开发工程师的笔试题目聊下来发现一个共性误区大家提到PaaS第一反应就是“容器平台、上Kubernetes”然后考前猛刷容器编排题结果拿到卷子才发现真正决定能不能进下一轮的反而是那些看起来不太“PaaS”的基础题。蘑菇街的PaaS团队不是做底层云产品的而是把基础设施能力沉淀成平台供商品、交易、社区这些业务方使用。所以笔试卷子既考Java基础、算法、网络、操作系统也考分布式中间件最后还会留一道大设计题。这篇就把这套题背后的能力要求拆开聊按模块逐类梳理考点、典型题型和解题思路末尾再给一份针对性的备考建议。无论你现在正在准备校招笔试还是想补一补PaaS方向的知识体系都可以直接拿这份框架去用。1. 蘑菇街PaaS笔试到底在考什么一份能力地图应届实习生的笔试不可能指望候选人有真实的平台落地经验所以笔试真正考察的无非三件事基础功底够不够扎实计算机底层原理有没有吃透以及面对开放问题时有没有“平台级”的抽象思维。1.1 考卷的整体风格与模块分布从常见的考题版本来看整套卷子基本会覆盖下面几个模块题量在八到十道左右笔试时长一般是一个半小时到两个小时。模块常见题型建议用时Java基础与并发程序输出题、概念简答题20分钟数据结构与算法手写代码题30分钟网络与操作系统简答、场景分析题20分钟分布式与中间件概念题 场景题20分钟PaaS场景设计综合设计题20分钟这个分配是我按常见迭代版本估的不同年份可能有浮动。但大方向很明确试卷不偏科基础题和平台题几乎各占一半。很多同学复习时喜欢直接钻进Kubernetes的Pod调度细节里这其实是个误区。基础模块中的Java并发、算法题、网络问题才是刷掉人最多的部分。原因也简单——PaaS平台最终服务的是业务系统如果你连上层业务是怎么用Java写出来的、一次RPC调用底层经历了什么都不知道就不可能真正做好一个面向业务的基础平台。1.2 为什么电商公司的PaaS岗位这么考蘑菇街的核心系统是Java技术栈这一点决定了笔试第一关必然是Java基础。电商业务的特点是流量波动大、大促场景多所以Redis、消息队列、分布式锁、限流降级这些中间件知识几乎是必考。PaaS团队在电商内部承担的职责是把部署、发布、隔离、弹性伸缩、监控这些能力组件化让业务方不需要关心机器和容器的细节。这样一来候选人必须具备跨层知识往下要懂容器、操作系统、网络往上要懂微服务、中间件、业务模型。笔试里的“大而全”本质上就是在筛选这种跨层能力。1.3 与普通后端笔试的区别普通后端笔试题更偏“业务接口怎么实现”“SQL怎么写”而PaaS岗位笔试题会更偏“资源如何被抽象”“系统如何被调度”“故障如何被隔离”。同样是一道分布式锁的题后端岗位可能会问“如何防止库存超卖”PaaS岗位则可能追问“分布式锁在节点宕机时怎么保证不产生死锁锁的自动续期机制怎么设计”。同样是设计题后端岗位是“设计一个订单系统”PaaS岗位是“设计一个多租户隔离的部署平台”。考题的出发点和落点完全不同复习时不能只按普通后端的路子准备。2. 基础题复盘语言、算法与计算机基础这个模块虽然不直接涉及PaaS概念却是整套卷子的淘汰重灾区。要是前三十分钟的题做不顺后面的设计题心态很容易崩。2.1 Java基础与并发编程程序输出题是怎么挖坑的Java部分常见的题型有两类。一类是给你一段代码判断输出结果另一类是并发编程的概念题比如volatile和synchronized的区别、线程池的核心参数、双检锁单例为什么需要volatile。程序输出题最喜欢拿下面这几个点挖坑Integer的缓存范围。Integer a 127; Integer b 127; a b 为true但128就不相等了。不少同学栽在这个细节上。String的不可变与常量池。字符串拼接会生成新对象但常量池内的字符串会在编译期被优化。static代码块、构造代码块、构造器的执行顺序。会先执行父类静态代码块再子类静态代码块然后是父类构造块和构造器最后才是子类构造块和构造器。try-catch-finally中return的执行顺序。finally是在return表达式执行之后、真正返回之前执行的所以如果finally里也有return会覆盖掉try中的返回值。重点说一下双检锁单例这道题在平台方向出现频率极高public class Singleton { private static volatile Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }为什么要加volatile因为instance new Singleton()在JVM层面不是原子操作它会被拆成三步分配内存、调用构造器初始化、把引用赋值给变量。如果不加volatile第二步和第三步可能被指令重排导致线程A还在初始化对象时线程B就已经判断instance ! null并直接返回了一个半初始化的对象。这类题背后考察的是对JVM内存模型的理解而不仅仅是背结论。建议复习时把《Java并发编程的艺术》里关于volatile和指令重排的章节读透。2.2 数据结构与算法题为什么LRU缓存出现频率这么高算法题的范围比较常规常见的有单链表反转、合并两个有序链表、二叉树层序遍历、最长不重复子串、两数之和。PaaS相关岗位的卷子里手写LRU缓存几乎是标配题。LRU最近最少使用缓存之所以受欢迎是因为它同时考察了数据结构组合运用和复杂度分析而且和平台开发的实际场景非常贴近——镜像缓存、配置缓存、服务发现本地缓存底层都需要淘汰策略。实现思路是HashMap加双向链表。HashMap负责O(1)的查找双向链表负责O(1)的删除和移动。get时把节点移动到链表头部put时如果容量已满淘汰链表尾部的节点。注意双向链表的节点里要同时存key和value因为淘汰尾部节点时需要根据key去删除HashMap里的记录。如果你能把这道题的复杂度分析讲清楚并且顺手提出“可以改用LinkedHashMap实现但需要重写removeEldestEntry”说明你对JDK集合类的理解是到位的。2.3 网络与操作系统PaaS工程师的眼睛网络题里最经典的一道是“从浏览器输入URL到页面展示中间发生了什么”。这道题要答全链路DNS解析、TCP三次握手、TLS握手如果是HTTPS、发送HTTP请求、服务端处理、返回响应、浏览器渲染。PaaS工程师尤其要注意理解HTTP和TCP的关系因为平台上的微服务之间大量使用HTTP/RPC通信排查问题时经常要分析连接状态。比如抓包看到大量TIME_WAIT意味着主动关闭连接的一方在大量短连接场景下回收不及时这时候常见的优化手段是修改tcp_max_tw_buckets参数或开启tcp_tw_reuse。操作系统部分进程和线程的区别、虚拟内存和物理内存的关系、缺页中断是什么、上下文切换的开销这些都比较常考。Linux命令里top看CPU和负载、free看内存、df看磁盘、netstat和ss看端口监听、ps看进程状态要能熟练组合使用。比如排查一个容器反复重启你要么用docker logs看日志要么用top看容器内进程CPU是否被打满再用dmesg看是不是OOM Kill。这些底层知识对理解容器至关重要。容器本质上是操作系统层面的隔离机制不理解进程、文件系统、网络命名空间就谈不上真正理解Docker和Kubernetes。3. PaaS核心概念与应用题容器、编排与微服务治理这里开始进入PaaS岗位的主战场。这个模块不只是背名词而是要把每个概念讲清楚“是什么、解决什么问题、在电商场景里怎么落地”。3.1 容器与镜像的底层原理Docker相关的概念题问得最多的是镜像分层。一个镜像由多个只读层叠加而成每一层对应Dockerfile中的一条指令。当容器运行时会在这些只读层之上加一个可写层。多个容器共享基础镜像的只读层所以启动快、占用空间小。对比容器和虚拟机时可以从隔离维度看虚拟机通过Hypervisor虚拟化硬件每个虚拟机有独立的Guest OS隔离性强但资源开销大容器通过Namespace做视图隔离、Cgroups做资源限制共享宿主机内核启动快但隔离性弱于虚拟机。这个区别在Kubernetes的节点安全加固里非常关键因为容器逃逸本质上就是突破Namespace和Cgroups的限制去访问宿主机资源。再深一层Namespace解决的是进程“能看见什么”的问题Cgroups解决的是进程“能用多少”的问题。容器内PID 1的进程也很重要如果PID 1进程退出整个容器就会停止。写Java应用镜像时如果直接使用java命令作为入口子进程会被优雅接管但如果你用shell脚本作为入口僵尸进程问题会很难缠。3.2 Kubernetes调度与资源模型Kubernetes部分笔试常见的是概念关系题。Deployment负责声明期望状态ReplicaSet负责维持副本数Pod是调度的最小单位。给Pod加Service是为了提供稳定的访问入口Ingress负责七层流量接入。ConfigMap和Secret用于配置解耦Secret的base64编码也要能认得出来。requests和limits的区别是高频考点。requests是调度时的资源预约Kubernetes的调度器会检查节点剩余可分配资源是否满足所有Pod的requests总和limits是运行时资源上限由Cgroups强制执行。只设置limits不设置requests可能导致调度器过度调度节点资源被打满。反过来只设置requests不设置limits则可能出现某个Pod无限使用CPU把同节点的其他Pod饿死。健康检查方面livenessProbe失败会导致容器被杀掉重启readinessProbe失败则会把Pod从Service的Endpoints列表中摘除。实际部署中readinessProbe比livenessProbe更容易被忽视但它在发布和扩缩容时更重要因为如果Pod还没就绪就被纳入负载均衡流量就会打到未启动完成的进程上。调度器的工作流程也可以简单说一遍Pod创建后进入调度队列调度器经过过滤Filter找到满足资源、亲和性、污点容忍条件的节点候选集再通过打分Score选出最优节点。熟悉这个流程对后续做弹性伸缩设计很有帮助。3.3 微服务治理PaaS平台为什么离不开这层能力PaaS平台在微服务架构里的角色是把服务注册、配置下发、流量治理、可观测性这些能力收口成平台能力。注册中心要答清楚“服务启动时注册、客户端定期拉取/订阅、通过心跳检测故障”这个基本流程。负载均衡算法可以列一下轮询、加权轮询、最小连接数、一致性哈希。一致性哈希在缓存类场景里尤其重要它能让节点变化时只有少量key发生迁移。熔断、降级、限流三者的区别值得重点解释限流是在请求入口直接控制流量速率比如单机QPS超过200就拒绝一部分请求熔断是下游依赖连续出错达到阈值时主动切断调用快速失败降级是关闭非核心功能比如大促时把首页推荐接口临时降级为静态数据保住交易主链路。再往后可以提到Service Mesh核心思路是把服务通信能力从业务进程里剥离成Sidecar代理业务只写业务逻辑流量控制、认证、可观测性全部下沉到基础设施层。与之对应的还有Istio的控制面组件负责下发配置给所有Sidecar。这个方向近年热度有所变化但底层思想依然是PaaS平台演进的重要路径。4. 分布式系统必考模块存储、缓存、消息与一致性PaaS平台做的是分布式系统的底座所以分布式中间件知识几乎是必问的。这个模块的题往往不让你直接背概念而是给一个电商场景让你分析用哪个组件、怎么解决。4.1 Redis缓存穿透、击穿与雪崩怎么区分Redis相关的题出现频率最高的是“缓存穿透、缓存击穿、缓存雪崩”很多人背了定义但还是答不完整主要问题出在没把场景和数据流向讲清楚。缓存穿透是查询一个不存在的key每次请求都会穿过Redis打到数据库。解决思路是缓存空值或者用布隆过滤器先判断key是否存在。布隆过滤器有一个代价很小的内存结构缺点是有一定的误判率但只会有“假阳性”而不会“假阴性”。缓存击穿是某个热点key过期的一瞬间大量并发请求同时打到数据库。解决思路是加互斥锁重建缓存或者设置热点key的逻辑过期时间让过期后第一个请求去重建其他请求先拿旧值。缓存雪崩是大批key同时过期或者Redis节点整体不可用导致请求压到数据库。解决思路是整个时间上打散随机过期时间或做多级缓存再或者对Redis做高可用架构从主从复制升级到集群模式。缓存一致性也是一个常见追问。如果先更新数据库再删除缓存删除失败会导致数据不一致但业务上一般会接受这种短时不一致或者通过延迟双删来兜底。如果先删缓存再更新数据库则在读并发较高时会有更大窗口的不一致。比较好用的思路是Cache Aside模式配合消息队列重试确保删除缓存的操作最终执行。4.2 消息队列为什么会出现在PaaS卷子里消息队列的作用可以概括成三个词异步、削峰、解耦。电商大促场景是典型的削峰场景同时下单请求和支付回调产生的流量直接打到数据库中间往往隔着一个高吞吐的Kafka。Kafka的核心概念要掌握Topic是消息的逻辑分类Partition是物理分片每个Partition内消息有序Consumer Group负责消息的负载均衡消费同一个Partition在同一时间只会被组内的一个消费者消费。答题时要注意两个容易踩坑的点。如何保证消息不丢失生产者端开启ack机制broker端配置多个副本并设置min.insync.replicas消费者端手动提交offset。如何保证不重复消费更关键的是让消费方具备幂等性——不管消息被消费几次最终结果一致常见的做法是消费端记录已处理的消息ID或业务主键。顺序消息则要尽量让同一业务ID的消息进同一个Partition配合单消费者去消费。4.3 分布式一致性与事务的答题框架这一块需要把握好“理论优先实例佐证”的原则。CAP理论是说在分布式系统中一致性、可用性、分区容错性这三者最多同时满足两个。在分布式存储和中间件设计中网络分区是无法避免的所以P和C或A之间必须做取舍。BASE理论是对CAP的延伸强调基本可用、软状态、最终一致性。分布式事务常见方案有2PC、TCC、本地消息表和最终一致性。2PC虽然能保证强一致但协调者单点和阻塞问题严重TCC把事务拆成Try、Confirm、Cancel三个阶段适合跨系统调用场景本地消息表加上消息队列重试是很多电商系统的最终一致性方案强调的是“业务操作和消息发送放在同一个本地事务里”。分布式锁也是高频考点。Redis分布式锁用SET NX EX实现要注意给锁设置超时时间防止死锁还需要考虑锁的自动续期ZooKeeper分布式锁靠临时顺序节点和watch机制可靠性更高但性能弱于纯Redis。笔试题里如果问“两个节点同时抢锁一个节点在执行业务时GC停顿了另一个节点拿到锁了怎么办”本质上是考锁安全性和续期策略而不是只看加锁和解锁那几行代码。5. 场景设计题实战电商PaaS平台的几类经典题目设计题是整套卷子区分度最大的一道题。PaaS岗位的设计题通常会给定一个电商平台建设中的实际场景让候选人给出架构和关键细节。5.1 多租户与资源隔离设计题目形式大概是平台需要同时接入商品、交易、社区等多个业务方请设计一个多租户资源隔离方案。答题时先明确“租户”这个词这里的租户可以是一个业务线也可以是一个团队。核心需求是租户之间互不影响任何一个租户的异常流量都不能拖垮整个平台。第一层是资源隔离对应到Kubernetes就是Namespace加ResourceQuota加LimitRange。每个租户分配独立NamespaceResourceQuota限制该Namespace下的总CPU和内存额度LimitRange限制单Pod的资源范围。这样即使某个租户疯狂创建Pod也不会把节点资源耗尽。第二层是数据隔离需要根据业务数据量去选方案数据量小时用独立Schema数据量大时用独立数据库实例最敏感的业务数据甚至可以独立集群。第三层是权限隔离用RBAC控制谁能操作哪个Namespace配合审计日志记录所有变更操作。答设计题的加分项是讲清楚“共享池”机制。纯粹的硬隔离会导致资源浪费可以设计一个共享备用资源池租户配额用完之后允许在共享池有空闲时临时借用一部分资源但需要设置抢占优先级高优先级的租户可以优先取回。这个思路很符合电商行业的实际情况是区分“背过八股”和“真做过平台”的关键细节。5.2 发布平台与灰度发布设计第二类经典设计题是设计一个支持灰度发布和快速回滚的发布平台。题目的背景是业务方希望频繁发版但又要保证发版过程不影响线上流量。所以发布流程的核心是可控和可回退。发布流程可以拆成几个阶段。首先构建镜像并推送到镜像仓库接着在Kubernetes中创建新版本的Deployment但不要直接把所有流量切过去。然后通过Ingress或Service的流量权重配置把比如1%、5%、10%的流量逐步切到新版本。每切换一档都要等待一段时间观察新版本的错误率、RT、CPU等指标。如果指标异常立即把流量全部切回旧版本或者直接扩容旧版本副本。灰度策略可以按用户维度做比如按用户ID取模只把某个范围内的用户流量打到新版本也可以按环境维度做比如内部员工先试用。这里要提到一个细节灰度发布需要一个发布单系统来管理当前版本、目标版本、灰度策略、回滚操作PaaS平台要做的正是这套流程的自动化。回滚设计是很多人容易忽略的点。资源层面Kubernetes的Deployment自带Rollback能力但前提是上一版本的镜像还要保留在镜像仓库里流量层面回滚不是把Deployment恢复到旧版本Pod而是把入口流量重新切到旧版本Service后面的Pod。答到这里顺便提一句“发布过程中要把新旧版本的pod同时保留一段时间便于快速切换”面试官就会知道你踩过真实的发布坑。5.3 高可用与弹性伸缩设计第三类题是系统流量在短时间内突增如何设计弹性伸缩方案保证系统不被打垮。先明确弹性伸缩的链路指标采集、策略判断、执行伸缩、稳定保护。指标采集通常包含CPU使用率、QPS、响应时间、队列堆积长度大促场景下还要考虑业务自定义指标比如下单请求量。扩容策略要区分“定时扩容”和“动态扩容”。电商大促是典型的定时扩容场景提前按预估流量扩容好资源而不是等流量到了再扩因为Pod启动和镜像拉取需要时间。动态扩容则是由指标连续超过阈值一段时间触发避免因为短时抖动频繁扩缩容。缩容要更保守缩容太快会导致系统仍然在高峰期但资源被回收设置冷却时间是必要的。数据库层的弹性伸缩是整个系统的难点。应用层可以无脑扩Pod但数据库连接数是有限的扩容后所有新Pod都去连同一个数据库往往会把数据库打挂。所以设计里要包含连接池上限、读写分离以及热点数据尽量走缓存只有最终落库请求才打到数据库。这道题的用意很明显PaaS平台不是只把Pod拉起来就算完而是要让整个系统在流量剧增时仍然稳定可用。有经验的人会把限流、降级和弹性伸缩放在一起讲因为它们是你中有我、我中有你的保护手段。6. 复盘后的几条备考建议这套卷子刷下来最直观的感受是PaaS岗位的笔试不是靠短期突击就能过的它考察的是计算机基础体系的完整程度。以下几条是我根据实际带人经验总结出来的备考方向可以少走不少弯路。6.1 基础模块一定要复习到原理层Java基础、算法、网络、操作系统这些内容看起来庞杂但每个方向都有高频考点。Java重点复习集合类源码、并发工具、JVM内存模型算法坚持每天刷两三道重点练链表、二叉树、动态规划、哈希表网络把TCP握手挥手、HTTP协议栈、DNS流程完整过一遍操作系统重点看进程线程和虚拟内存。原理层的意思是不仅要能说出“是什么”还要能解释“为什么”。比如知道ConcurrentHashMap是分段锁或CAS加synchronized还要知道它为什么比HashTable并发性能好。这些“为什么”才是笔试中显示区分度的地方。6.2 场景题要训练“从业务反推架构”的能力不要只背中间件概念养成一个习惯拿到一个电商场景先问“这个场景的流量特征是什么”“数据一致性要求有多高”“故障的影响半径有多大”再决定选用什么组件、如何设计架构。比如设计秒杀系统就会自然引入Redis预扣库存、消息队列削峰、限流降级、独立部署。这个过程练多了笔试设计题会越答越顺。即使遇到没见过的题也可以用这套方法论去分析而不是死记硬背答案。6.3 答题策略和时间分配拿到卷子先花两分钟把全部题目扫一遍标记难度。算法题如果五分钟没有思路先跳到后面的简答题等做完其他题目再回头来写。很多人在算法题上死磕半小时最后设计题只能草草写几句反而丢了更大的分。简答题尽量分点作答先给结论再展开。设计题一定要画系统结构哪怕只是简单方块和箭头也比纯文字有优势。注意把异常场景写进去比如“如果Redis挂了怎么办”“如果发布到一半失败怎么回滚”这些往往是阅卷人最看重的地方。我自己看过不少笔试答卷发现一个规律能进面试的同学未必是最快写出最优算法的人但一定是面对开放设计题时能把边界条件和异常流程都想清楚的人。PaaS岗位尤其如此因为平台上的一个小故障会被放大到所有业务方。准备过程中多替业务方想想“系统到底会发生哪些故障、平台怎么兜底”比单纯刷题更接近这个岗位的本质。