字节网络/存储/分布式/基础架构实习面经（已收offer）

30min八股和业务，20min手撕1.自我介绍2.项目中业务数据用MySQL来存储，MySQL的事务有了解过吗3.b树和b+树区别4.慢SQL处理，sparkSQL运行慢如何处理5.hive和spark区别6. 为什么要有DWD层 如何构建的，有没有进行一些指标的分析7.DWS层作用，如何进行构建的，建表依据8.没有ADS层可以吗9.业务域和数据域什么区别，不同主题域是否会有重叠10.有接触过数据治理吗11.如果让你接手一个 数据治理项目，会从哪些层面着手12.ER模型和维度 模型区别13.MapReduce中有几个排序，有什么区别14.索引有什么作用手撕:连续登录大于3天用户ID有的记不清了，大概这些最后反问:当前阶段是加强对技术栈的理解更重要还是业务方面的理解答，对于学生阶段更应该深入技术栈，加强学习，以后工作可以加强对业务的理解作为面试官，在考察时更注重哪些层面的能力答，会更加看重对做的项目的理解，比如做一件事为什么要做这件事，为什么要用这种方法，看有没有进行这个思考，以及思考的深度

1.自我介绍2.项目介绍3.介绍一下SSE协议，聊不了解实现机制4.数据库相关MySQL了解吗，在项目中使用MySQL还是PGMySQL的MVCC快照读和当前读的区别是什么MySQL的B+Tree的结构是怎么样的（明明我说用的是PG😭）5.RedisRedis的网络IO模型是什么用Redis实现分布式锁会有什么问题6.介绍一下MCP，如果Schema文字量大要如何处理7.有用过开源编排引擎吗？看过哪些多Agent的搭建8.如何设计一个可以对模型+设备进行TPM、RPM的限流机制，如果单个设备会打到不同服务器又要如何设计算法：1.反转整数，不能使用long类型，超过int的最大最小值返回02.给定一个数n和一个数组nums，返回使用nums元素可以构建的小于n的最大数，不考虑nums中存在负数。例如：n=23491，nums=[2,4,9]，返回22999；n = 23333，nums = [2,3]，返回23332；n=23333，nums = [3]，返回3333拼尽全力捞我，无法战胜过于菜鸡的我更新：进二面了，感谢一面的面试官大人

一面：全程50min，八股30min，算法20min1. innodb引擎的rr级别，age是普通索引，id是数据库主键，递增字段。事务A：begin；T1 select * from user where age = 20；（2个结果）T3 select * from user where age = 20；T4 update user set name = 'name1' where age = 20;T5 select *from user where age = 20;comit;事务B：T2 begin insert into user values('name2', 20); comit。请你分别告诉我T3-T5各有几个结果?2、3、32. TIME_WAIT 状态原因？ack至少丢失一次；防止建立历史连接3. 设计一个抽奖系统，每个用户可以抽 m 次，奖品个数为 n，每个用户最多只能中奖一次，大流量场景下如何设计，可以支持百万级并发抽奖？从接口、逻辑、扩展方面依次回答了。4. 算法：130. 被围绕的区域======================================================================二面：全程 40min，项目 15min，算法 20min，反问 5min1. 自我介绍2. 说下实习干了啥？大致介绍了下，然后说的实习难点3. 接口重构做了什么？说了过程，说了上线策略4. 你们后端服务大致拆分了几个服务？为什么那么拆分？5. 慢 SQL 治理的过程和原理？6. 其他记不清了7. 算法：LCR 084. 全排列 II。中间看成了全排列，5 分钟秒掉结果调试半天没有输出，经提示有重复数字。抠了半天抠出来了======================================================================三面：总共 70min，实习+项目+八股 20min，算法 50min1. 自我介绍？2. 实习工作？3. Netty 为什么快？4. 详细说下 NIO？5. 各种其他问题，记不清了6. 算法：31. 下一个排列总结：栽在三面了，唯一一次原题没写出来。当时写 hot100 就没细看，感觉这题有点难，结果唯一一次出原题我还没写出来！

鼠鼠第一次投大厂面试,写面经攒人品:1. 个人介绍(2min)2. 挖项目(我跟后端相关的项目似乎只有抖音商城(字节跳动青训营),他一直挖我这个项目)3. 服务是怎么被发现的?(微服务)4. 假如你这个服务要更新,要更平滑,不让用户感到延迟,你会怎么做?- 维护两套环境（蓝：当前生产环境；绿：新版本环境）。- 新版本在绿环境测试通过后，切换流量到绿环境，蓝环境作为回滚备用。- 优点：零停机，用户无感知切换。5. 你输入一个url的处理过程6. 然后就开始写题了,面试官直接口述,输入一个数字,输出下一个最小的比这个数大的数字(重新排列)leetcode类似的题目是:[556. 下一个更大元素 III](******************************************************)这道题手撕还是相当紧张的,给我撕出来了7. 数据库事务是什么8. mvcc是什么,怎么实现的?9. 场景题,给你一个番茄小说的书,有十万订阅,如何快而准确的通知到所有订阅的人更新了(这里要求你去用具体的实现)我这里寄了,后面复盘的时候,应该是使用feed流,这个是用ai写的答案:- 推模式 (Fanout-On-Write/Writes)：- **操作时机：** 当关键事件（如新章节发布）发生时**立即**执行。- **目标用户：** **核心活跃粉丝（数量相对较小）**。- **动作：** 将事件**直接写入**这些目标粉丝的个人 **收件箱（Inbox Feed）**（一个按时间排序的数据存储）。用户访问自己的 Feed 流时，直接从这个收件箱拉取即可，延迟极低。- 拉模式 (Fanout-On-Read)：- **操作时机：** 当用户主动请求访问 Feed 流时执行。- **目标用户：** **非核心粉丝（长尾粉丝，数量大）** 或 触发推模式的粉丝，在访问 Feed 时可能需要拉取更长时间范围内的数据。- **动作：** 后端服务在用户请求时，**实时聚合**用户所关注对象（收藏的书籍）的 **发件箱（Outbox Feed）** 数据（包含所有发布事件），按时间排序后返回给用户。这需要访问多个发件箱（每个收藏的书一本）并聚合。- **「推拉结合」的关键：** **合理区分「核心粉丝」与「长尾粉丝」**，只对核心粉丝进行实时写入。**关键组件与流程详解：**1. **事件源 (Event Source)：**- **新章节发布：** 最核心的事件源。携带 `bookId`, `chapterId`, `publishTimestamp`。- **粉丝关系变更：** 用户收藏 (`favor`) 或取消收藏 (`unfavor`) 一本书。携带 `userId`, `bookId`, `action`, `timestamp`。2. **事件总线 (Event Bus)：**- 使用高吞吐、可靠的消息队列如 Kafka/Pulsar。接收上述事件并进行持久化，供下游消费者订阅。后面是就是针对十万用户的进行**精准界定“核心活跃粉丝” (`HotFanCache`)：**,查询优化,**高性能存储与分片：**10. 反问,问了业务是什么,技术栈是什么,然后和面试官聊的蛮开心的,面试官夸了基础好,知道稳了10min之后,hr通知2面.1面成功.