校招 未知部门 / 后端-Java / 多轮
[面试日期] 2026-09-22 [面试时长] 未知
[学校背景] 北京理工大学 | 985 [学历背景] 本科
[发布人] 面试之星官方收录
<h2>分享|4年Java面B站,Redis和MySQL日志体系深挖,三面终于OC</h2>
<p>先交代背景:普通本科,Java后端,4年经验,上一家是某二线互联网公司,负责过会员系统和直播互动系统的开发。</p><p>B站4年经验的面试,一面45分钟,围绕Redis持久化、Redis集群、MySQL日志体系三个方向深挖。面试官不追求题量,而是顺着一个点往下追,追到你答不上来为止。三轮技术面加HR面,最终OC。</p><p><strong>📌 第一阶段:一面三个方向深挖45分钟(9月)</strong></p><p><strong>方向一:Redis持久化</strong></p><p><strong>1️⃣ RDB和AOF的区别是什么?生产环境怎么选?</strong></p><p>💡 <strong>思路参考</strong>:RDB是快照,全量备份,恢复速度快但可能丢数据(两次快照之间的数据);AOF是增量日志,实时性好但文件大、恢复慢。4年经验要能说出<strong>混合持久化(RDB+AOF)</strong>——Redis 4.0之后支持,AOF重写时前半部分是RDB格式,后半部分是AOF格式,兼顾恢复速度和数据完整性。</p><p><strong>2️⃣ 追问:“RDB的fork操作会阻塞主线程吗?”</strong></p><p>💡 <strong>思路参考</strong>:fork本身会短暂阻塞主线程(微秒到毫秒级,取决于内存页表大小),但fork之后的快照写入是子进程完成的,不阻塞主线程。4年经验要能说出<strong>fork的Copy-On-Write机制</strong>——fork后父子进程共享内存页,只有写操作时才复制,所以内存占用不会瞬间翻倍。</p><p><strong>3️⃣ 追问:“AOF重写期间,新写入的命令怎么办?”</strong></p><p>💡 <strong>思路参考</strong>:AOF重写期间,主线程的新写入命令会同时写入<strong>AOF缓冲区</strong>和<strong>AOF重写缓冲区</strong>。重写完成后,将重写缓冲区的命令追加到新AOF文件中,再用新文件替换旧文件。4年经验要能说出<strong>为什么要两个缓冲区</strong>——AOF缓冲区保证正常写入不丢,AOF重写缓冲区保证重写期间的增量不丢。</p><p><strong>方向二:Redis集群</strong></p><p><strong>4️⃣ Redis Cluster的槽位是怎么分配的?MOVED和ASK重定向的区别?</strong></p><p>💡 <strong>思路参考</strong>:Redis Cluster有16384个槽位,均匀分配到所有主节点。MOVED表示槽位已经永久迁移到另一个节点,客户端需要更新路由表;ASK表示槽位正在迁移中,客户端需要临时重定向到目标节点,但不需要更新路由表。4年经验要能说出<strong>为什么是16384个槽位</strong>——16384个槽位的位图大小是2KB,网络传输开销小;如果槽位太多(如65536),心跳包会太大。</p><p><strong>方向三:MySQL日志体系</strong></p><p><strong>5️⃣ redo log、undo log、binlog三者的区别和联系?</strong></p><p>💡 <strong>思路参考</strong>:redo log是InnoDB的物理日志,记录数据页的修改,用于崩溃恢复;undo log是InnoDB的逻辑日志,记录数据的反向操作,用于事务回滚和MVCC;binlog是MySQL Server层的逻辑日志,记录所有修改操作,用于主从复制和数据恢复。4年经验要能说出<strong>三者写入顺序和两阶段提交</strong>——事务提交时,先写redo log(prepare状态),再写binlog,最后写redo log(commit状态)。</p><p><strong>6️⃣ 追问:“为什么需要两阶段提交?如果不做会怎样?”</strong></p><p>💡 <strong>思路参考</strong>:两阶段提交是为了保证redo log和binlog的一致性。如果先写redo log再写binlog,写完redo log后宕机,重启后redo log恢复数据,但binlog没写,主从数据不一致;如果先写binlog再写redo log,写完binlog后宕机,主库恢复后没有数据,但从库有数据,主从数据不一致。4年经验要能说出<strong>崩溃恢复时的判断逻辑</strong>——redo log是prepare状态时,检查binlog是否完整,完整则提交,不完整则回滚。</p><p><strong>📌 第二阶段:二面三面全过了(9月)</strong></p><p><strong>二面(50分钟)——过了</strong></p><p><strong>1️⃣ 系统设计:设计一个高可用直播弹幕系统</strong></p><p>💡 <strong>思路参考</strong>:接入层(WebSocket长连接管理,按直播间ID一致性哈希分片)、消息层(Kafka按直播间ID分区,保证同一直播间消息顺序)、存储层(Redis ZSET按直播间维护最近100条弹幕)、推送层(通过WebSocket推送给在线用户,写扩散)。核心难点:高并发写入、实时推送、限流策略。4年经验要能说出<strong>弹幕系统的降级方案</strong>。</p><p><strong>2️⃣ 项目深挖:直播互动系统的QPS架构分析</strong></p><p>💡 <strong>思路参考</strong>:日均请求1000万,峰值QPS约5000。直播互动系统涉及弹幕、礼物、点赞、连麦四个核心链路。4年经验要能说出<strong>接口时延的分布</strong>——哪个方法耗时最多、为什么、怎么优化的。</p><p><strong>三面(交叉面,40分钟)——过了</strong></p><p><strong>1️⃣ 线上故障排查</strong></p><p>💡 <strong>思路参考</strong>:说一个真实的P1级事故。某次大促流量比预估高了3倍,Redis连接池被打满。排查过程:看监控确认故障范围→查Redis连接池状态(打满)→发现热Key问题(某个直播间被大量请求)→紧急做本地缓存(Caffeine,过期时间10秒)→恢复。事后加<strong>热Key分散策略</strong>。</p><p><strong>HR面(20分钟)——OC</strong></p><p><strong>📌 声明</strong></p><blockquote><p><em>以上思路参考来自 </em><strong><code><em>"面题鸭🦆"</em></code></strong><em> 各岗位专属考题的考点方向</em></p></blockquote><p><strong>📝 复盘</strong></p><p>B站4年经验的面试,考的是三件事:底层机制、线上排障、系统设计。</p><p><strong>🎯 后来怎么调整的?</strong></p><p>一面挂的原因是Redis持久化的细节说不清楚,AOF重写期间的双缓冲区机制答得不完整。</p><p>还有一个意外收获——没想到在 <strong><code>"面题鸭🦆"</code></strong> 上刷了一遍B站方向的JD专属出题和大厂考题,Redis持久化、Redis集群槽位、MySQL两阶段提交这些方向覆盖得很全。二刷时心里有底很多。</p><p></p><p></p><a>#数据人的面试交流地#</a><a>#发面经攒人品#</a><a>#牛客在线求职答疑中心#</a><a>#秋招报数:你投了多少家公司?#</a><a>#你觉得什么岗位会被AI替代#</a>
AI 推荐面试题
