某小厂后端面经

【岗位名称】后端开发实习生-飞书低代码平台和大模型应用【面试时间】2025.7.7【流程&题目】1. 自我介绍2. 项目（分布式缓存系统）a. 为什么要做分布式缓存系统？b. 是自己从头到尾设计，还是有一些参考的项目？c. 做的过程中遇到了哪些问题？⇒ 分布式缓存系统一般在业务上会怎么用？为什么要用分布式缓存？一般能解决哪些业务问题？3. 基础知识a. 算法思路：n*n的迷宫，1为通，0为不通，怎么找到从入口到出口的最短路径？⇒ 除了动态规划还有什么思路？b. MySQL的索引类型？例如用户表，有几个字段，哪些情况下使用索引？c. 如果使用三个字段A、B、C创建联合索引，哪些能够命中，哪些不能？说明原因d. HTTP的状态码有哪些？502、504出现在什么情况？301、302的区别？e. TCP怎么保证可靠传输？f. 业务场景：网购平台下单，如何防止超卖和重复？这个架构可能会遇到什么问题，如何解决g. 计算机思维：16瓶药，1瓶有毒，15瓶无毒，小老鼠喝掉毒药之后1h会被毒死，现在只有1h的时间，最少用几只小老鼠可以试出哪瓶有毒4. 算法题：最长递增子序列5. 最后问题：有没有接触过和大模型相关的内容6. 问面试官的问题a. 关于低代码平台b. 对我的建议【总结】准备的还是不太充足，很多概念都只是知道这个名词而不了解在业务上的应用场景（也是最后面试官的建议）面试官人挺好的，回答的不是很好但是面试官很耐心

最近刷小红书，发现好多帖子都在推各种各样的 AI 面试作弊的工具，国内国外的都有，自研开源的也都有，底下的评论都还挺迫切的需要。看完这些留言，我挺感慨的。今天我想就这个话题，跟大家掰扯掰扯：用AI作弊拿到offer这事，到底该怎么看？值不值得赌？后果有多严重？说实话，现在AI辅助工具确实很强。你给它一句题干，它能秒出思路、代码、注释一条龙服务。不少“聪明人”把这套用到线上面试里：一边和面试官语音连麦；一边用 iPad 或第二台电脑把题目输进 ChatGPT ；然后照着 AI 的答案，对着摄像头念。听起来好像挺丝滑？但你以为面试官是傻子吗？很多面试官也用 AI 出题、写文档。他们比你更懂 AI ...

1 注册中心不可用了微服务之间还能相互调用吗2 rpc调用过程3 看你用了redis和es，为什么用了多个缓存组件4 redis单线程效率为什么快5 redis有哪些数据结构6 使用redis集群的话，数据分区过程是什么样7 es的分词过程有了解吗8 MongoDB和mysql实用场景区别，优缺点9 mysql的acid如何实现10 事务隔离级别的读已提交和可重复读怎么实现11 mysql的索引的建立选择和依据12 你去建立索引要考量的因素有哪些13 mysql适合范围查询吗14 tcp怎么解决数据损坏丢包乱序问题15 算法：反转链表

鼠鼠第一次投大厂面试,写面经攒人品: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面成功.