斗鱼后端面试全记录：Java并发、弹幕系统与高并发架构实战

1. 拿到面试邀请后我先干了这几件事斗鱼的面试流程不算特别长整体节奏比较紧凑。我在收到邀约到正式面试之间大概有一周左右的准备时间这一周我没有盲目刷题而是先花了两天把简历里涉及的项目重新盘了一遍。这里说一句实话很多人挂在面试上不是因为八股文背得少而是因为简历里写的项目经不起追问面试官一旦往下深挖就露馅。我当时第一步是列了一个项目问题清单。把简历里每个项目涉及的技术点、业务背景、个人职责、技术选型理由全写下来每个点都预设两到三个追问场景。比如我写到用过消息队列解耦那面试官大概率会追问为什么不用RPC直接调用消息丢失怎么处理重复消费怎么保证幂等这些追问我全部提前准备好了答案而且不是背答案是理解清楚之后用自己的话讲出来。第二步是针对性看斗鱼的业务特点。斗鱼是直播平台那它的技术栈一定绕不开高并发、低延迟、弹幕系统、礼物系统、直播流分发这些场景。我专门去看了斗鱼的技术博客和公开分享了解到他们主要用的是Java技术栈中间件涉及Kafka、Redis、MySQL这些常规组合但直播场景下的IM消息、弹幕协议、房间热度计算这些肯定会有特殊设计。基于这个判断我把准备重点放在了两块一是Java基础和并发编程二是高并发场景下的系统设计题。第三步才是刷题。我这里说的刷题不是盲目刷LeetCode而是针对直播业务常见的高频题做专项练习。比如TopK问题、限流算法、LRU缓存这类都是直播场景高发考点。后面我会专门讲算法环节的细节这里先不展开。这里顺便说一个非常重要的心得准备面试不要只看目标公司要看目标公司的业务。同样是后端岗电商公司和直播公司的考察重点完全不一样。电商必问秒杀、订单状态机、库存扣减直播必问弹幕协议、礼物并发、房间热度。你提前把业务的特殊性吃透面试时给出来的回答会让面试官觉得你是做过功课来的。2. 一面干货Java基础和并发编程的考察方式与追问链斗鱼的一面通常是技术面面试官会一边看简历一边问问题整体风格比较务实不会刻意刁难但追问链条会拉得比较长。这一面主要考察的是基础功底和项目真实性我把自己实际遇到的题目和参考答案贴出来。2.1 HashMap的底层原理被问到什么程度HashMap是Java面试的必问题我自己在斗鱼一面就被问到了而且问的方式不是直接问“HashMap底层是什么”而是给了一个场景让我分析。面试官的问法是“一个直播间有大量用户进入退出我用HashMap存用户信息在并发场景下会不会有问题怎么改进”这个问法其实就是考察你知不知道HashMap在JDK 7和JDK 8的区别以及并发扩缩容的安全问题。我的回答分了三层第一层HashMap底层是数组加链表JDK 8之后当链表长度超过8且数组长度超过64时会转成红黑树。它本身线程不安全多线程同时put时可能发生数据覆盖JDK 7里还会出现扩容时的死循环问题JDK 8改进了resize逻辑死循环问题解决了但数据丢失和覆盖问题依然存在。第二层并发场景下通常用ConcurrentHashMap替代。JDK 8的ConcurrentHashMap抛弃了JDK 7的Segment分段锁改用CAS加synchronized锁住桶头节点的方式锁粒度更细并发度更高。第三层结合直播场景补充了一句如果用户信息的key是userId热点用户可能会集中在少数几个桶里这时候可以考虑用LongAdder之类的方案做计数但单纯存用户信息ConcurrentHashMap已经够用。面试官听完点了点头没有继续深挖红黑树的左旋右旋但我知道很多面试官会继续追所以也准备了。如果你被追问红黑树的旋转细节至少要能说清楚插入时为什么要变色、为什么要左旋右旋核心目的就是保持黑节点平衡保证最长路径不超过最短路径的两倍。2.2 volatile和synchronized的底层语义别只知道可见性问到并发编程时面试官这次是从一个弹幕计数的场景切入的。他说“多个线程同时往一个房间的热度值里累加用volatile修饰能不能保证正确为什么换成synchronized呢”这个问题第一反应是很多人会说volatile能保证可见性所以能。但实际上是错的volatile解决的是可见性和有序性不解决原子性。count这个操作是读改写三步volatile只能保证读的时候看到的是最新值但三个线程同时读到一样的最新值再同时写回就会互相覆盖。正确做法要么是用AtomicLong要么用synchronized包住整个累加操作要么用LongAdder做高并发下的累加。我当时回答完之后面试官又问了一句“volatile的底层屏障怎么实现的”这块我讲了两个层面的内容。JMM层面volatile的写操作会插入StoreStore屏障和StoreLoad屏障读操作会插入LoadLoad屏障和LoadStore屏障目的是禁止指令重排保证读取到的值一定是最新的。具体到实现其实是通过lock前缀指令来触发缓存一致性协议。也就是说volatile变量写的时候会强制把当前处理器缓存行的数据写回主内存同时其他处理器核对缓存行时发现失效就重新从主内存加载。2.3 线程池的核心参数与拒绝策略结合实际场景说斗鱼一面问线程池的方式也比较实战问的是“如果一个直播间的弹幕需要异步处理你会怎么设计线程池核心线程数怎么定”这题在考核心参数的理解和实际场景的估算能力。我先答了七个核心参数corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler。然后重点讲了核心线程数的估算逻辑。如果是CPU密集型任务核心线程数设为CPU核数加一比较合理因为CPU密集型任务多了线程反而会频繁切换。如果是IO密集型任务核心线程数可以设大一些参考公式是CPU核数乘以二再加一但我补充了一句纯粹套公式不够严谨更靠谱的做法是通过压测来调。弹幕处理这个场景属于IO密集型和短任务型的混合体任务本身耗时很短但频率极高所以队列可以选择SynchronousQueue或者容量很小的有界队列让多余的任务直接触发拒绝策略。如果队列太大任务积压会导致弹幕延迟越来越高直播场景里用户感知极其明显。拒绝策略我给出了四种AbortPolicy直接抛异常、CallerRunsPolicy让调用线程执行、DiscardPolicy直接丢弃、DiscardOldestPolicy丢弃最老的未处理任务。弹幕场景下我会选CallerRunsPolicy或DiscardOldestPolicy前者把压力反馈给上游后者保证消息流不会无限积压。这里我主动补充了一个容易被忽略的细节线程池里的线程异常退出后ThreadPoolExecutor会通过addWorker方法补充新线程所以线程数不会因为某个任务抛出异常就越来越少。这个细节面试官一般不会直接问但你说出来会显得源码功底扎实。2.4 数据库索引这块斗鱼是真的会问底层一面结束时面试官抽空问了一个MySQL索引的问题“联合索引a、b、c查询条件是b? and a? and c?会不会走索引为什么”这个问题的本质是考察最左前缀原则。很多人只记住了“最左前缀”四个字遇到查询条件顺序变化就懵了。MySQL的优化器会做条件重排把a?放到最前面所以b? and a? and c?和a? and b? and c?是等价的都会走联合索引。但如果是b? and c?没有a的等值条件就没办法走这个联合索引。不过要注意MySQL 8.0引入了Skip Scan优化某些情况下即使没有最左列也可能走索引但那是特殊情况面试时先答标准规则再补充这个优化点会显得知识面广。还有一个常考的点是回表。走联合索引a、b、c时如果查询字段只有a、b、c那索引覆盖不需要回表。如果查询条件是a? and b?查询字段是c和id也没问题。但如果查询字段里有非索引列比如name那就需要回表查主键索引。3. 二面核心直播高并发场景设计题这样答才完整二面是整场面试的分水岭也是我准备最久的部分。斗鱼二面的面试官偏架构方向问的问题几乎全是场景题几乎没有纯八股。我遇到的题目是“如果让你设计一个直播间的弹幕系统你会怎么设计请从架构层面完整描述。”这道题说实在话单独可以撑起一场专栏。我把它拆解成四个层级来回答也推荐你们按这个思路组织答案。3.1 第一层弹幕的端到端链路我先描述了完整的数据流用户A在客户端发送一条弹幕客户端通过WebSocket或者TCP长连接把消息推送到接入层网关网关校验之后发给后端的消息系统消息系统做持久化和分发最终实时推送到同一个房间的所有在线用户。这里要注意弹幕系统的核心诉求是“低延迟高吞吐”。用户发弹幕到看到自己弹幕出现在屏幕上这一整个RTT不能超过几百毫秒否则体验很差。所以长连接的选型很关键WebSocket是最常规的方案因为它在HTTP协议之上做一次升级握手之后就是全双工通信比轮询省太多。我在这里补充了接入层网关的细节网关要做协议解析、鉴权校验、流量控制还要维护和客户端的长连接状态。当一个房间有几十万人在线时网关集群要支持水平扩容并且要按照房间维度做哈希路由尽量让同一个房间的连接落在同一组网关实例上这样推送链路更短。3.2 第二层弹幕的存储设计弹幕要不要持久化答案是分情况。弹幕作为一种短时效内容一般只需要保留最近一段时间的历史。我在回答里给出了一个具体的存储方案MySQL存全量但只保留最近几天的数据过期数据定期清理Redis用Sorted Set或者List存最近N条的热点弹幕比如每个房间只存最近1000条用户进入房间时可以快速拉取。为什么用Sorted Set因为弹幕天然有时间顺序用score存时间戳就能很方便地做时间范围内的查询。如果用户进房要回看最近一分钟的弹幕直接ZREVRANGEBYSCORE拉数据就行性能非常高。分库分表要考虑到弹幕表的写入量非常大可以按房间ID做水平分片也就是哈希取模。同时因为弹幕查询基本都是按房间加时间来查这个分片键和查询条件是非常匹配的。3.3 第三层消息推送的实时通道弹幕的实时推送是系统设计中技术含量最高的部分。市面上常用的是推拉结合模式推模式是服务端主动把弹幕推给客户端走长连接实时性最好拉模式是客户端定时去服务端拉取增量弹幕实时性差一些但实现简单。直播场景对实时性要求极高所以核心用推模式。但纯推模式有个问题如果某个房间弹幕量特别大服务端推送压力会非常大。我的方案是推拉结合加本地缓存。客户端和边缘节点之间建立WebSocket长连接服务端把弹幕推送到边缘节点边缘节点再推给客户端。当弹幕量爆发式增长时客户端自动降级为拉模式通过HTTP轮询接口拉取增量弹幕服务端在Redis里缓存最近几秒的弹幕数据。这样既保证了正常状态下的低延迟也在极端情况下避免了服务端被打爆。3.4 第四层高并发下的限流和降级弹幕系统的并发极不均匀明星开播时一个房间可能同时涌入几百万弹幕。这种场景下如果不对流量做管控整个集群都会雪崩。我设计的限流方案分为两层。第一层是接入层限流用Sentinel或自研的计数器限流按照房间维度设置每秒最大弹幕数超过阈值直接丢弃或合并弹幕。第二层是内核限流Kafka消费端按房间维度的并发度做限速保证消费速度不会压垮下游存储。降级方案要从两个维度考虑弹幕延迟升高时优先丢弃低优先级的弹幕比如普通用户的弹幕可以延迟发送礼物特效和主播公告必须优先推送。存储故障时直接把弹幕投递到本地文件或临时队列等存储恢复后再异步回放。这里我额外分享了一个真实场景下的心得弹幕系统最怕的不是量太大而是突发流量下的雪崩效应。如果限流直接丢弃所有超量弹幕用户体验会断崖式下降。更好的做法是“漏桶令牌桶”的组合拳令牌桶控制入口速率漏桶控制消费速率突发流量先打在缓冲里而不是一上来就丢。我把这个方案完整讲完之后面试官明显比较满意后续又问了一个关于消息队列选型的问题。他问“你用的是Kafka还是RocketMQ为什么”我回答的是Kafka原因有两点弹幕场景追求的是高吞吐Kafka的吞吐量在消息队列里属于第一梯队另外Kafka的消费模型天然适合广播多个消费者组可以同时消费同一条弹幕流做不同的处理。但是我也提到了Kafka的短板消息可能重复消费所以在消费端必须有幂等设计比如按消息ID去重。4. 算法环节斗鱼的高频题和手写代码注意事项斗鱼的算法环节不全是LeetCode原题有些题会和业务场景强相关。我遇到的算法题是“设计一个限流器”要求写代码实现固定窗口限流。题目本身不复杂但考查的代码功底非常细。先给参考答案。固定窗口限流的核心逻辑是维护一个计数器和窗口起始时间请求进来时如果还在当前窗口内就加一超过阈值就拒绝如果当前时间已经超过窗口起始时间加窗口大小就重置计数器和起始时间。public class FixedWindowRateLimiter { private final int maxRequests; private final long windowSizeInMillis; private long windowStart; private int requestCount; public FixedWindowRateLimiter(int maxRequests, long windowSizeInMillis) { this.maxRequests maxRequests; this.windowSizeInMillis windowSizeInMillis; this.windowStart System.currentTimeMillis(); this.requestCount 0; } public synchronized boolean tryAcquire() { long now System.currentTimeMillis(); if (now - windowStart windowSizeInMillis) { windowStart now; requestCount 0; } if (requestCount maxRequests) { requestCount; return true; } return false; } }代码写完之后面试官问我“这个实现有没有问题怎么优化”我指出了两个问题。一是synchronized锁住了整个方法高并发下性能会有损耗可以用AtomicInteger加CAS来替代。二是有边界突刺问题固定窗口在窗口切换的瞬间可能出现两倍的请求量通过比如窗口大小1秒限流100那在第999毫秒和第1001毫秒之间的那几毫秒理论上最多能放行200个请求。优化方向是滑动窗口或者漏桶/令牌桶。我重点讲了滑动窗口把时间切分成更细的格子比如把1秒切分成10个格子每个格子100毫秒维护最近10个格子的计数总和超过阈值就拒绝。这样窗口是平滑移动的突刺问题被明显削弱。面试官追问“令牌桶和漏桶有什么区别什么时候选哪个”令牌桶是桶里维护令牌以固定的速率往桶里放令牌请求进来必须拿到令牌才能通过桶满时令牌溢出。漏桶是请求以固定的速率流出桶不管上游请求多快下游消费速率恒定。令牌桶的特点是允许一定的突发流量因为桶里可以积攒令牌。漏桶的特点是绝对平滑但无法应对突发流量。直播场景里的限流我倾向于令牌桶因为直播间开播瞬间会有大量用户涌入这些流量其实是要处理的只是在总量上做约束。漏桶更适合下游保护场景比如数据库写入。这轮算法题面试官还问了一道概率题题目大意是有一个函数可以随机返回1到7的整数如何用它实现一个随机返回1到10的整数这题是经典的概率拒绝采样思路。先调用两次rand7得到一个均匀分布的1到49的随机数如果结果在1到40之间就直接对10取余加1否则拒绝采样重新生成。面试时能把拒绝采样的概率讲明白通过率会很高。5. 三面和HR面项目复盘、稳定性考察和谈薪技巧如果有三面通常会是一个组长或者总监级别的面试官重点不再是具体技术细节而是看你的系统设计能力、项目推进能力和软素质。我遇到的题目是“讲一个你最有成就感的项目从背景到上线复盘”。这个环节有个很容易踩的雷很多人讲项目像报流水账背景是什么、我做了什么、上线了什么。面试官听完毫无感觉。正确做法是结构化复盘项目背景-目标-难点-方案-结果-个人思考。其中难点要讲得具体方案要有比较结果要能量化。我当时讲的是一个订单系统的性能优化项目。背景是高峰期订单接口RT从200ms涨到2秒核心难点是热点商品导致的数据库连接池被打满。方案我做了两组对比一组是本地缓存加Redis多级缓存一组是引入消息队列削峰填谷。最后我选择了多级缓存加热点隔离RT降到80ms数据库连接池使用率从90%降到40%。讲完结果之后我补充了一句个人的复盘思考当时如果早点做压测这个问题的发现时间能提前两周。这句话让面试官觉得我是真的在复盘而不是背稿子。HR面的问题相对传统我当时遇到的几个问题分别是为什么从上一家公司离职、期望薪资多少、能不能接受加班、未来三到五年的职业规划是什么。前三题我答得比较顺畅这里重点说一下谈薪。HR问期望薪资时我报了一个比当前薪资高30%的区间同时补充了依据我对直播业务做了调研这个职级在市场上的普遍薪资范围是多少我的项目经验和技能匹配度在哪里所以期望在这个区间偏上的位置。这里有个小技巧不要报一个固定的数字要报一个区间而且这个区间的最低值要是你能接受的下限。HR如果压价也不会低过你的下限太多。如果HR问“目前薪资是多少”可以大方报出真实情况但要强调除了薪资之外你看重的还有业务方向和技术成长空间这样显得你不是单纯为了钱跳槽。6. 复习路上的三个教训和面试当天的实战心得从我自己的经历来说有几件事是实打实的教训写出来给后面准备斗鱼面试的同学参考。第一个教训是不要忽略数据库锁的知识点。我准备的时候重点放在了并发编程和缓存上结果一面面试官问到“MySQL的行锁和间隙锁分别是怎么实现的”我答得不够完整。间隙锁是RR隔离级别下为了解决幻读引入的锁机制它锁住的是一个范围而不是具体的行两个事务插入相同范围的数据时会互相阻塞。这个点后来我复盘时才彻底搞清楚。第二个教训是项目经验一定要“讲出来”而不是“背出来”。我认识一些朋友准备了几十页的笔记可真上考场时一紧张背的内容全乱了。我自己做了个模拟面试拉了朋友充当面试官一遍一遍地讲项目。讲到第三遍的时候我发现自己的表述自然了很多追问时也能临场组织语言。第三个教训是反问环节也要提前准备。面试官在最后通常会问“你有什么想问的”这绝不是一个客气话而是真的在考察你对公司和岗位的兴趣度。我当时问的是三个问题斗鱼弹幕系统的峰值QPS大概是多少、团队目前的组织架构和技术方向、新人的成长路径是什么样的。这三个问题问完之后面试官明显更愿意多聊一些场面也轻松了很多。面试当天的实战心得也分享几条。一是提前调试好设备和环境。我面试时用的网页端提前半小时测试了摄像头、麦克风、网络延迟还准备了备用网络避免面试中途断网。直播行业的面试也很看重沟通效率所以我会把耳机麦克风调试到最佳状态减少杂音和回音。二是准备一个项目小结的文档在自己面前。不是让你照着念而是万一面试官追问到某个细节你瞄一眼能快速找回记忆。我自己是准备了一张只有关键词的一页纸比如项目里用的中间件版本、核心参数、关键指标这些细节一旦卡壳瞄一眼关键词就能顺下去。三是心态上不要把面试当成考试当成一次技术交流。我在斗鱼面试时遇到不会的问题就老实说“这个细节平时用得少我了解到的之前是这样但我不确定最新版本的实现”然后反过来请教面试官。大多数面试官都愿意分享而且这种坦诚反而会给你的评分加分。最忌讳的是明明不会还要胡编硬造。如果你也在准备斗鱼或者其他直播类公司的后端岗位我建议你按这个思路来先吃透Java基础并发再重点攻场景设计算法保持手感最后把项目讲成有结构有深度的故事。面经是参考不是标准答案最终面试官看的是你是不是一个真正理解技术、能解决问题的工程师。我自己面试时深切体会到准备得越充分回答时就越从容这种状态本身就会传递出令人信任的信号。