后端开发一面面经

#牛客AI配图神器#面试官面了我30分钟，我面了他20分钟（开玩笑的，但我确实问了面试官很多），面试官是后端组长，整体体验很好，偏项目深挖，不是纯八股，很多问题都是从简历里一个点一路往下追，但是我的知识面确实还不足，下来好好补一下。
下面是把录音发给ai让他帮我总结的：

一、自我介绍

主要介绍了自己的学校、Java 后端技术栈、两段实习，以及做过的一些 Agent / 微服务项目。

面试官让我选一个自己比较熟悉的实习经历展开，我选了目前在做的智能驾培中控系统。

二、实习项目深挖

先让我介绍整个项目、业务背景、技术栈和架构。

我主要介绍了智能驾培中控系统，负责学员、课程、车机以及预警相关的后端功能。

然后开始深挖简历里的“学员下课预警”。

问得比较细：

• 这个功能的业务场景是什么
• 为什么需要同步课程预约数据
• 数据是从哪里同步到哪里
• 是数据库直接同步，还是通过接口同步
• 定时任务怎么做
• 一天大概有多少数据
• 如何处理取消预约
• 如何判断是不是最后一节连续课程
• 跨天课程怎么处理
• Redis 快照是什么意思
• 前端怎么获取预警信息
• 是服务端主动推送还是前端轮询
• 轮询多久一次
• 会不会存在高并发问题

这一块感觉面试官比较重视“你是不是真的做过”，会不断追问业务细节。

三、Redis + MySQL 延迟队列

简历里有一个自研延迟任务队列：

MySQL 持久化任务
→ Redis ZSet 按时间戳排序
→ 到期任务迁移到 Redis List
→ 消费者消费

面试官主要问：

• 为什么不用 ZSet 直接做完整的延迟队列
• 为什么还要加 List
• MySQL 在这里是做什么的
• Redis 重启后任务怎么办
• List 是怎么消费的
• 用 RPOP 还是 BRPOP
• 如果 List 没数据，是不断轮询还是阻塞等待
• 阻塞式和非阻塞式消费有什么区别

这里我对 BRPOP 不太熟，算是一个明显知识盲区。

我当时的设计思路是：

ZSet 主要负责时间排序，List 负责消费，MySQL 负责持久化。Redis 如果丢数据，可以通过数据库里未完成的任务重新恢复。

面试官还问了一个很实际的问题：

“既然项目都已经用了 Kafka，为什么延迟队列还要自己用 Redis List 做？”

我回答主要是为了自己实践一套延迟队列设计，并且 MySQL 是最终持久化来源，所以 Redis 不是唯一数据源。

四、Kafka

项目里 Kafka 主要用来：

• 异步同步文章上下架状态
• Kafka Streams 聚合用户行为
• 计算文章热度
• 更新 Redis ZSet 热点榜

问了 Kafka 顺序消费：

如果一批消息要求严格按顺序处理，应该怎么设计？

我回答：

Kafka 整体不能保证全局有序，但是单个 Partition 内有序，可以使用相同业务 key，让相关消息进入同一个 Partition，再由 Consumer Group 顺序消费。

继续追问：

“如果消费的时候出现并发怎么办？”

我回答同一个 Consumer Group 中，一个 Partition 同一时刻只会分配给一个 Consumer。

这部分整体还可以。

五、Elasticsearch

问了 ES 在项目里是做什么的。

我一开始回答说文章查询直接查 MySQL 成本比较高，所以同步到 ES 做查询。

然后面试官继续问：

“那 MySQL 查询也不一定比 ES 慢，ES 到底用了什么 MySQL 没有的能力？”

这里我没答好。

后面复盘了一下，这里应该重点回答：

ES 主要优势不是“单纯更快”，而是倒排索引、全文检索、分词、相关性评分、多字段文本搜索等能力。

这个属于比较明显的失分点。

六、Redis 基础和分布式锁

问了 Redis 除了 ZSet、List 之外还用过什么结构。

然后继续问分布式锁。

我提到了 Redis SETNX 和 Redisson WatchDog。

面试官继续深挖：

• WatchDog 怎么续期
• 什么情况下需要续期
• TTL 应该设置多长
• 如果有成千上万个任务都使用 WatchDog，这种方式是否合理

面试官的观点是：

高并发大量任务下，不一定所有场景都适合持续 WatchDog 检测，也可以根据业务耗时预估一个较合理 TTL，然后在任务执行过程中根据耗时主动判断是否需要续期。

这个角度以前没怎么考虑过。

七、Redis ZSet 排行榜

这个问题挺有意思。

先问：

ZSet 中如果两个 member 的 score 一样，怎么排序？

我一开始不确定，后面面试官提示，正确答案是：

score 相同时按照 member 的字典序排序。

然后继续问一个游戏场景：

两个玩家都是 100 分，但是玩家 A 比玩家 B 更早达到 100 分，要求 A 排在 B 前面，怎么设计？

我当时没想出来。

面试官给了两个思路：

一个是把真实分数和时间信息编码到同一个 score 里面，例如整数部分存真实分数，小数部分根据达到时间构造排序权重。

另一个思路是通过位运算，把真实分数和时间信息拼到一个数值中，必要时配合 Lua 脚本完成计算和写入。

感觉这个问题挺符合游戏后端业务的。

八、Agent / LangGraph 项目

后面问了我的 Agent 项目。

问题包括：

• LangGraph 一共有几个节点
• 每个节点输入输出是什么
• State 怎么维护
• 条件边怎么设计
• Prompt Enhancement 拼接的是什么
• 大模型如何读项目文件
• 代码生成后怎么校验
• 是否会自动启动项目
• 如何保证 AI 生成代码的质量

我介绍了大概的流程：

用户需求
→ 需求分析
→ 素材并发收集
→ Prompt 增强
→ 判断生成普通 HTML 还是 Vue 项目
→ 代码生成
→ 质量检查
→ 不通过则回到生成节点重试

这里自己有几个节点记得不够熟，面试过程中有“边想边说”的情况，后面准备这种项目还是应该把完整工作流图背熟。

九、AI Coding

面试官问：

平时使用 Codex / Agent 写代码，怎么保证生成代码的质量？

我的回答大概是：

• 需求分析和方案设计阶段多花时间
• 先验证最小闭环
• 用 Postman 测正常流程
• 再测异常和边界条件
• 再用另一个会话或更强模型做一次 Review

后面反问环节聊 AI 比较多。

面试官说他们团队现在 AI Coding 使用程度已经非常高，从 PRD 到代码生成、代码 Review 都会大量使用 Agent。

目前主要的问题反而不是“AI 能不能写代码”，而是：

AI 一次可以产出非常多内容，人很难快速判断这些方案是不是正确、是不是适合生产环境。

所以他们现在比较强调：

• 人负责方案把控
• AI 负责生成和检查
• 复杂任务拆成小步骤
• 每一步都做验证
• 不太倾向直接让 Agent 长时间全自动跑完一个大型任务

还提到 TDD / BDD 来验证 AI 产出。

十、反问

我主要问了几个问题：

1. AI 在团队研发流程里怎么使用
2. 当前服务端开发最大的难题是什么
3. Agent / Skill 的 Harness 怎么设计
4. AI 越来越强以后，开发人员应该怎么提升

面试官的一个观点我印象挺深：

以后开发人员可能更需要技术广度和方案判断能力。

因为 AI 能很快帮你实现代码，但是你要知道：

这个场景应该用 MySQL、ES、ClickHouse 还是其他方案？

方案 A 和方案 B 到底有什么区别？

AI 可以帮你实现，但最终技术方案还是需要人判断。

总结

整体大概 50 分钟左右。

感觉乐元素这场后端面试不是特别偏八股，更偏：

项目真实性 + 技术方案设计 + 中间件细节 + 实际业务场景。

简历上写到的东西最好都要能够回答：

• 为什么这么设计
• 有没有别的方案
• 为什么不用成熟方案
• 极端情况下会发生什么
• 如果数据量/并发量扩大怎么办

我这次比较明显需要补的点：

• Redis BRPOP / BLPOP
• Elasticsearch 倒排索引和全文检索
• ZSet 同分排序和排行榜二级排序
• Redisson WatchDog 的实现和适用边界
• Agent 工作流节点、State、条件边
• AI 代码生成后的自动化验证

整体面试体验不错，面试官也会在答不上来的地方给一些实际经验和思路，不是单纯问完就结束。

面试官说hr已经下班了，明天通知我后续，应该是6.30下班，有点不好意思，拖了面试官20分钟#面经#