我印象里映客2020年春招研发A卷在当年几个直播平台的笔试题里属于很能反映业务形态的一套。它不像纯互联网公司那样只堆算法题也不像传统软件公司那样全考八股而是把高并发、实时链路、数据一致性这些直播业务里真正会碰到的问题揉进了试卷里。如果你准备投的是直播、音视频、社交这类方向的研发岗这套卷子的考点分布和答题思路很值得认真拆一遍。这篇文章我不打算只给你列“考了什么”而是想从这套卷子背后的技术逻辑讲起——为什么它会这样出题、每类题目实际上在考察什么能力、你拿到类似试卷时应该按什么顺序做、哪些地方容易丢分。后面我还会附上一些算法和系统设计题的答题模板以及我整理过的高频考点对照表方便你直接拿去备战。1. 拿到这份A卷先读懂映客在考什么1.1 直播业务的技术全景从开播到连麦一条请求链路背后有多少环节很多人第一次看直播公司的笔试题会懵觉得题目范围特别散有算法、有数据库、有网络、甚至还有Linux命令。但如果你把一条直播请求链路完整走一遍就明白这些考点全是业务里真实存在的环节。先说最简单的观看场景。用户打开App进到直播间客户端先要做的是拉取房间信息、主播信息、礼物配置这类静态数据这对应的是接口设计、缓存策略。接着要拉流这就涉及CDN调度、流媒体协议、首帧秒开。用户看了一会儿开始发弹幕、点关注、送礼物这些操作全部落到后端对应的是高并发写入、消息推送、排行榜实时更新。主播端那边推流要经过采集、编码、上传对应的是音视频处理。也就是说直播平台的后端研发实际上要同时面对三类问题面向C端的高并发读写、面向主播的流媒体链路、面向运营的数据分析。映客这套A卷几乎把这三条线都覆盖了。所以你在准备时不能只刷LeetCode得把每个技术栈和直播场景的对应关系搞清楚。1.2 为什么是A卷春招研发笔试的出题逻辑春招和秋招的笔试其实有微妙差别。秋招是海投高峰笔试更多承担筛选功能题量偏大、难度偏高目的是快速淘汰。春招则往往是补录或者提前批HR已经有一批简历池笔试除了筛选还要兼顾“评估候选人能否快速上手业务”这个目标。所以A卷这类命名通常对应的是“面向研发通用岗的第一套题”。它不是针对某一个细分岗位出的而是想看你的计算机基础扎不扎实、有没有系统设计的基本sense、能不能在有限时间内写出可运行的代码。这也解释了为什么卷子里会出现一些“看起来简单但坑很多”的题——比如考虑并发扣款、缓存穿透、消息乱序这些都是生产环境里出了事故才会深刻理解的东西。1.3 岗位视角这份卷子主要筛选什么人从我这几年看直播行业校招的情况来说行测题都是浮云技术笔试真正想筛选的是下面这三类能力第一基础功。 数据结构、操作系统、网络协议这些底子决定了你后面能不能看懂复杂系统。第二工程思维。 同样一个“获取直播间热度”的功能新手会直接查数据库有经验的人会想到多级缓存、异步聚合、降级方案。笔试题里那些“你怎么设计”的开放题就是在筛这个。第三业务敏感度。 你有没有想过为什么一个爆款直播间能扛住百万在线为什么围观人数多但弹幕量却不线性增长为什么连麦延迟比普通直播更敏感如果你把A卷错过的题复盘一遍再对照上面这三点会发现自己薄弱在哪个维度。我自己带过的实习生里能拿到满意offer的几乎都是在这三方面做了充分准备的。2. 高并发与数据一致性直播场景绕不开的两座山2.1 这类卷子最扎心的考点热点请求打在同一个直播间直播业务和普通互联网业务最大的一点不同在于流量分布极度不均。普通电商虽然也有秒杀但热点商品分散在各个SKU上直播间不是一个头部主播开播几百万人同时涌进同一个房间这个房间就是单一热点。我记得这轮笔试的题目里有好几道题都暗含了这个前提。比如“某个直播间突然涌入大量请求如何保证服务不挂”比如“粉丝团排行榜实时更新如何做到毫秒级展示”再比如“礼物特效消息如何保证不丢不重不乱序”。它们本质上考的是同一个东西面对单点热点你的系统架构有没有分流和缓冲设计。我当时整理过一个处理思路笔试和面试都能用层级方案解决什么问题接入层LVS/Nginx负载均衡按直播间ID做哈希路由把流量分散到多台机器应用层本地缓存分布式缓存Redis多级兜底避免请求全部打到数据库消息层引入消息队列削峰填谷异步处理关注、点赞等非关键操作存储层分库分表按房间维度拆分防止单库连接数被打满如果你能把这个层级模型答全再在每个层里补充一两个细节比如“Redis缓存为什么要用本地缓存兜底”“消息队列消费失败怎么重试”这道题的得分会比写一大段空话高很多。2.2 缓存的三种典型用法以及它们各自埋的坑缓存是直播研发笔试题里的常客十道里有八道会涉及。但同样的“用Redis”不同场景的用法完全不一样你得先判断题目问的是哪种。只读型缓存。 比如房间基础信息一旦创建几乎不改。这种场景最简单设置合理的过期时间即可注意别把过期时间设成全公司统一值否则大量Key同时失效数据库会被击穿。读写型缓存。 比如热度值、在线人数写入频繁但允许秒级延迟。标准做法是先更新数据库再删缓存或者用异步任务批量刷新。强一致型缓存。 比如余额、礼物数量这类数据理论上不应该走缓存但如果非要抗压就得用分布式锁保证只有一个请求能写其余请求排队或降级。我在实际项目中踩过一个坑热度排行用了Redis的ZSet看起来非常合理但开播瞬间几万人同时加入ZSet的写操作全部集中在同一个Key上单分片CPU直接飙到100%。后来改成多Key分片每个分片存一部分用户的热度值再定时合并排序才把压力降下来。笔试里如果遇到类似的题你除了说出“用Redis ZSet做排行榜”最好主动补一句“ZSet单Key写入有瓶颈可以按用户ID哈希分片再异步归并”这个信息量直接甩开一大半候选人。2.3 数据一致性送礼物流水和余额扣减为什么不能只走缓存直播业务的虚拟礼物消耗本质是一个账户扣款问题。虽然单笔金额不大但QPS极高再加上直播间的社交氛围用户连点送礼物的频率很夸张这就把并发扣款的矛盾暴露得很明显。先想一个最简单的方案用户送礼后端收到请求查余额够就扣不够就返回失败。如果两个请求并发到达都查到余额充足然后就都执行了扣减余额就变成负数了。这就是典型的丢失更新。笔试里答这道题你至少要给出三种解决思路乐观锁。 在余额表加version字段更新时带上前一次查到的versionupdate语句返回影响行数为0则说明version变了重新重试。数据库原子操作。 用update account set balance balance - ? where uid ? and balance ?让数据库保证原子性扣款失败则返回余额不足。强一致存储Lua脚本。 把余额操作放到Redis里用Lua脚本原子执行再异步同步到数据库。我个人比较推荐用Lua脚本方案因为纯数据库乐观锁在高并发下会有大量无效重试。Redis的Lua脚本可以保证多个命令原子执行又不会有事务回滚的复杂问题很适合礼物这种高频小额扣款。你可以在卷子上写一段伪代码-- 扣减余额key: user:{uid}:balance local balance tonumber(redis.call(GET, KEYS[1])) local cost tonumber(ARGV[1]) if balance nil or balance cost then return -1 end redis.call(DECRBY, KEYS[1], cost) return balance - cost同时给出后续的补偿说明Lua执行成功的流水写入消息队列由消费者批量更新数据库账单如果Redis宕机则降级到数据库扣减。这道题基本就稳了。2.4 从笔试到面试怎么把一致性方案讲成亮点笔试只是第一关很多公司笔试过了之后面试官会直接拎着你笔试里的答案追问。你对一致性的理解如果只停留在“加锁”“加版本号”这种名词层面很容易在追问中露馅。我建议你不管笔试题目有没有要求都主动把方案背后的取舍想清楚。这里有一套可以复用的思考框架这个方案允许数据延迟多久 比如热度允许1分钟延迟余额不允许延迟。这个方案在故障时怎么降级 比如Redis挂了能不能直接降级到数据库。这个方案的一致性级别是什么 是最终一致、读己之写还是强一致。你把这个框架套在任何一道题上回答都会显得很有体系。面试官听完通常不会再往深里扎因为你的思考层次已经到架构层面了。3. 从点赞到弹幕实时链路的题目设计与答题套路3.1 实时互动题最典型的几种考法直播间的实时互动是映客这类平台区别于一般App的核心场景。所以这套A卷里关于实时互动的题目占比不小经典考法有这些设计一个直播间弹幕系统要求支持万人同时在发。点赞数如何做到毫秒级更新又不能让数据库被打爆。连麦时如何保证音画同步延迟控制在多少以内。用户进入直播间在线人数如何统计退出后如何保证准确的在线状态。看到这类题先别急着写代码而是要在脑子里构建一条数据链路客户端产生事件 - 接入网关 - 业务逻辑处理 - 消息分发 - 其他客户端渲染。这条链路的每一环都有对应的技术选型和坑。3.2 推模型和拉模型怎么选很多人一开始就答反了弹幕系统设计题里最核心的一个分叉点是消息从服务端到客户端用推、用拉、还是推拉结合。大多数人先入为主会选WebSocket推觉得实时性好。但如果你把生产环境考虑进去就会发现纯推模式有很多问题连接数太多导致网关压力大网络抖动时消息容易丢客户端离线期间的消息没法补。所以实际生产环境往往采用推拉结合。比如弹幕既可以用WebSocket长连接推送实时消息又可以在客户端进入直播间时先通过HTTP拉取最近50条历史弹幕填满聊天区域防止一开始界面空荡荡。在线人数和热度的更新则没必要用长连接客户端定期轮询或者用SSE接收服务端推送即可。笔试答题时建议你画一张简单的模块图文字描述也行标明哪个模块用推、哪个模块用拉、各自的理由是什么。这样子的答案比只写“用WebSocket实现实时弹幕”要丰富得多。3.3 WebSocket和HTTP轮询的取舍千万不要只谈技术这里有一个很多新人会犯的错把WebSocket当成实时场景的唯一解。实际上技术选型要结合业务场景来定。如果消息频率很高而且要求双向通信比如弹幕、连麦信令选WebSocket。如果消息频率低或者主要是服务端单向推送比如通知、在线人数SSE更轻量还自带断线重传。如果只是偶尔拉一下状态比如每次进直播间拉一次礼物面板HTTP轮询就够了。另外无论用什么协议都要考虑弱网环境。移动端直播场景最常见的问题是网络切换导致连接断开。你可以在卷子上补充客户端断线后要自动重连重连后需要增量同步离线期间丢失的消息服务端要为每个连接维护一个消息序号客户端用序号去重。这个细节一出来面试官就知道你确实在移动端上踩过坑。3.4 答到点子上画架构、写关键代码、给数据给一道真实出现在类似卷子里的题做示范题目大意是设计一个直播间的点赞功能要求百万级用户同时点赞时计数器不掉精度前端展示能实时更新。这道题你如果只写“用Redis INCR”只能拿基础分。完整答案是分三层的第一层接入层。 点赞请求先打到Nginx网关网关按直播间ID做一致性哈希保证同一个直播间的请求固定落在同一台业务机上方便做本地聚合。第二层聚合层。 每台业务机在本地维护一个点赞计数器每攒满100次或者每100ms就批量把增量提交到Redis用INCRBY更新直播间的总点赞数。这样Redis的写入量直接降了两个数量级。第三层展示层。 前端每5秒通过接口拉取一次当前点赞总数或者通过WebSocket接收服务端推送的聚合数值。不需要精确到每秒钟因为用户根本看不清百万级别的个位数变化。你再补充一句“为了防止重启导致本地计数丢失需要周期性把本地计数持久化到磁盘或备份到Redis”这个答案的完成度就很高了。4. 答题顺序与时间管理研发笔试题的隐形分4.1 先做算法还是先做系统设计用两分钟快速判断很多人拿到试卷就开始按顺序做这不是好习惯。我的习惯是花两分钟浏览整张卷子把所有题扫一遍标出三类能马上做出来的送分题、需要动脑写代码的核心题、篇幅很长的系统设计题。对于映客这套A卷我的建议是先做算法题。原因是算法题看的是正确率和运行效率写完之后只要用例能过分数基本就锁定了不容易受后面状态影响。而系统设计题和问答题弹性大就算你花了40分钟写一大篇也不一定能拿到满分。顺序大概这样安排5分钟快速浏览全卷标记题目类型。15-20分钟做2道简单/中等算法题确保AC。20-25分钟做1道压轴算法题能做多少做多少写对核心思路也有分。剩余时间全部给系统设计题和问答题尽可能多写。4.2 算法题的难度分布和压轴题常客从题库的整体难度看春招研发卷的算法题一般呈现“两道基础一道拔高”的分布。基础题主要以数组、字符串、链表、二叉树为主难度对标LeetCode简单到中等拔高题则偏向动态规划、贪心、双指针、滑动窗口或者带一点业务背景的模拟题。我建议你重点准备这几类题型因为它们出现频率最高滑动窗口/双指针。 适合用来解“连续子数组”“最长不重复子串”这类题代码短、容易写对。TopK问题。 用一个固定大小的堆解决面试笔试都爱考。二叉树遍历变体。 层序遍历、最近公共祖先、路径和这三兄弟几乎场场都有。简单的动态规划。 最长上升子序列、背包问题、爬楼梯变体练熟转移方程推导方法。压轴题如果带业务背景通常不会太难但题干会长需要你从文字里提取出核心数学模型。例如“主播A在时间段内收到N个礼物每种礼物有不同的连击倍数求总收益最大值”这种本质上是一个区间DP或者贪心问题。写作时耐心拆题干把约束条件列出来再套算法模型好过盲目从第一句话开始写代码。4.3 题目问“怎么设计”时别只写概念要落到模块和接口系统设计题是很多研发岗候选人的丢分重灾区。原因很简单平时没真的设计过系统只能堆概念。例如题目让你“设计一个直播间评论系统”有人的答案就两句话用WebSocket推送存MySQL。这个答案约等于零分。你要做的是把系统拆开讲清楚每个模块的职责接入层用什么网关、怎么鉴权、怎么限流。消息处理评论内容先过一遍敏感词过滤再把消息写入消息队列。消息存储MySQL存全量Redis按直播间存最近N条用于新用户进入时拉取。消息分发基于长连接网关做广播按直播间维度维护订阅关系。可靠性发送失败怎么重试、消息重复怎么去重。如果能再给出消息体的大致结构加分效果更明显{ room_id: 123456, user_id: 98765, nickname: 小鹿, content: 主播好棒, timestamp: 1585123456789, msg_id: a1b2c3d4-e5f6-7890 }笔试答题时不一定能写完整套设计但至少要把模块划分和关键数据结构列出来让面试官一眼看出你有架构意识。这种能力不是临场能编出来的需要平时多看多画强烈建议你用“直播业务”作为练手场景把房间、礼物、弹幕、排行榜分别做一遍设计练习。5. 算法题之外的软性得分点往往决定了你能不能进面试5.1 代码风格你写出来的代码像不像能上生产环境很多阅卷人不只看代码能不能跑通还会看你的代码风格。线上阅卷系统虽然会自动跑测试用例但在分数边界模糊时人工复核看的就是代码的整洁度。我总结过几个加分细节变量名要有语义。 写for (int i 0; i n; i)没问题但如果能把i改成roomIndex、windowStart评价会高不少。函数拆解要合理。 一道题的逻辑如果超过30行就应该拆成两个函数比如一个负责主流程一个处理边界条件。不要把所有逻辑全塞进一个main函数。提前return优于多层if嵌套。 能把判断条件反着写减少嵌套深度通常说明思考更清晰。代码是对你思维过程的映射。在公司里功能上线后读代码的次数远多于写代码的次数可读性就是生产力。5.2 草稿和注释把你的思考过程显性化在线笔试平台一般都提供草稿纸但很多同学忽略了一个用法把题目的关键约束、测试用例写在草稿上。作用有两个。第一防止看漏条件。比如题目里写了“如果数组为空返回-1”你如果没注意代码里就没有这个分支测试用例直接挂掉。写在草稿上就不会忘。第二监督自己别跑偏。有时候写着写着会沉浸在自己的逻辑里忘了题目原始需求。草稿上那两三行要点能帮你随时拉回来。注释方面不用写废话但在关键算法步骤前写一行注释很有必要。比如“// 此处用二分查找优化到O(logn)”可以让阅卷人快速理解你的思路即使代码有小bug也可能因为思路清晰而被酌情给分。5.3 边界条件面试官最爱盯的隐藏考点边界条件是研发笔试里“看着简单但极易失分”的地方。我见过太多人主流程逻辑全部正确最后挂在输入为空、数字溢出、负数、重复元素这些边界上。准备边界条件有一个基本套路输入规模为0或1时代码是否正常输入中有重复值时逻辑是否还成立数值运算结果是否可能溢出int范围数组下标是否会越界特别是两个指针同时移动时如果题目要求排序排序的稳定性是否影响结果例如题目让计算某直播间同时在线人数的峰值你不仅需要考虑用户进入直播间的时刻还要考虑同一秒有人进有人出的情况。很多人会漏掉“同一时刻进出怎么算”这个细节而这恰恰是测试用例里必有的坑。5.4 复盘比刷题更重要给你一套错题整理方法关于备战最后想多说一句。纯刷题的数量不重要我见过刷了300题依然笔试挂掉的也见过只刷80题但每次复盘特别到位的学生轻松过关。区别就在复盘。我自己的错题整理维度是这样的这道题考的是哪个基础知识点我在哪一步开始出错是没看懂题还是思路错了还是代码实现bug这类题有没有通用的解题模板如果面试官加一个限制条件比如O(1)空间我还能不能做出来用这个方式复盘每道题都有立体收获。特别是那些你花40分钟才做出来的题复盘价值远大于5分钟秒杀的题。6. 写在最后直播研发的真实要求比笔试更立体把映客2020春招研发A卷的考点拆到这里想跟你说一句实话笔试只是入场券真正决定你能不能接住这份工作机会的是后续的面试和实际项目。直播研发岗位每天面对的是真实的线上流量、真实的网络抖动、真实的用户情绪你写在卷子上的方案最终都要经得起生产环境的检验。如果你这次笔试准备时间有限优先抓三样高并发下缓存与数据库的一致性方案、实时消息推送的推拉模式选型、算法题里的滑动窗口和TopK。这三样覆盖了直播研发笔试60%以上的分数。另外直播行业的技术面试往往很看重候选人对业务的理解。你可以多花点时间想想为什么直播间要区分游客和房管为什么不同城市看到的推荐内容不一样为什么有的直播间画质清晰有的模糊这些问题背后都是技术决策。当你开始用技术视角审视一个直播产品时你就已经走在正确的路上了。祝顺利。