Java大厂面试实录：谢飞机的音视频场景三连问（Spring Boot + Kafka + Redis + AI RAG）

Java大厂面试实录：谢飞机的音视频场景三连问（Spring Boot + Kafka + Redis + AI RAG）

面试官：严肃、逻辑缜密、善用业务场景追问
谢飞机：985科班，简历写满20+技术栈，实际能跑通Hello World…但今天，他碰上了「音视频」——那个让一半Java人沉默、另一半开始重学Netty的领域。

🌟 第一轮：基础稳不稳？先看音视频上传链路

面试官：我们音视频平台每天接收500万条UGC上传请求，前端分片上传到OSS后触发回调。服务端用Spring Boot接收回调，校验MD5并落库。请问：

1. 如何避免同一视频被重复处理（幂等性）？
2. 如果校验失败，你用什么方式通知前端重传？同步HTTP调用还是异步？为什么？
3. 数据库写入前，是否需要加分布式锁？锁粒度怎么选？

谢飞机（挠头）：“呃…幂等？我用Redis setnx！key是fileId…失败就发个Feign调用前端…”面试官（点头）：“不错，Redis做幂等key可行。但Feign同步调用在高并发下会拖垮你的回调接口——这里应该投递Kafka消息，由下游消费端异步通知。至于锁？文件ID级锁太重，建议用fileId:check作为锁key，超时设为3秒，配合try-with-resources释放。”

🌟 第二轮：流量洪峰来了，缓存和消息怎么扛？

面试官：上传成功后，要触发AI生成封面图（调用内部Stable Diffusion API）、打标（NLP模型）、推荐冷启动（相似视频召回）。这三个任务耗时差异大（100ms~3s），且不能阻塞主流程。你怎么设计？

1. 这类异步任务，用@Async够吗？为什么不用Kafka？
2. 封面图生成失败，如何保证重试且不重复生成？
3. 推荐冷启动结果需缓存，用Redis哪种结构？过期策略怎么设？

谢飞机（语速加快）：“@Async…够吧？我加了@EnableAsync…重试？加个while循环？缓存…String？TTL…嗯…7天？”面试官（微笑）：“@Async共享Tomcat线程池，一旦下游AI接口雪崩，你的Web容器就OOM了。必须解耦——全走Kafka。重试用死信队列+delay topic；冷启动结果用Hash存{videoId: {tagList, simIds}}，TTL设动态值：热度越高，TTL越长（用ZSET按播放量排序，定时刷新）。”

🌟 第三轮：AI不是魔法，是工程——RAG怎么落地？

面试官：我们上线了「创作者知识库问答」功能：UP主上传SOP文档（PDF/Word），运营可问“如何开通4K审核权限？”。后台用RAG实现。请说明：

1. 文档解析阶段，如何保留表格/标题层级结构？
2. 向量化时，为什么不能直接用整篇PDF喂给Embedding模型？
3. 检索阶段，用户问“审核权限”，可能匹配到“资质认证”“内容安全中心”等词，如何提升语义相关性？
4. 如果RAG返回答案含幻觉（如虚构政策条款），你怎么拦截？

谢飞机（擦汗）：“解析…用POI？向量…不是越大越好吗？语义…加关键词？幻觉…呃…加个‘请勿编造’提示词？”面试官（轻叹）：“POI无法解析PDF表格，要用Apache PDFBox + LayoutParser提取结构化文本；Embedding必须分块（chunk），推荐semantic chunking（按标题/段落语义切），否则丢失上下文；相关性靠HyDE（假设性文档嵌入）+ Rerank模型（如BGE-Reranker）；幻觉拦截需双保险：① 答案必须标注引用原文片段（source_id + page_num）② 设置置信度阈值，低于0.65则返回‘暂未找到依据’。”

✅ 面试官结语

“谢飞机同学，基础概念有认知，但在场景深度、取舍权衡、失败预案上还需沉淀。比如Kafka分区数没提、Redis持久化策略没聊、RAG评估指标（Hit Rate/MRR）也没涉及…回去把《音视频高并发架构》《RAG Engineering Best Practices》两篇Paper精读一遍，两周后可约二面。——回家等通知吧。”

📚 附：技术点详解（小白友好版）

🔹 场景锚点：音视频UGC平台

• 为什么考这些？音视频=高吞吐（上传）、低延迟（播放）、强一致性（审核）、AI融合（封面/打标/问答），是检验Java工程师全栈工程能力的黄金场景。

🔹 技术链路拆解

| 环节 | 技术选型 | 关键原因 | |------|----------|----------| |幂等校验| Redis SETNX + Lua脚本 | 原子性保障，毫秒级响应，比DB唯一索引更轻量 | |异步解耦| Kafka（非@Async） | 解耦生产/消费速率，支持重试、死信、顺序消费（partition key=videoId） | |缓存设计| Redis Hash + 动态TTL | Hash节省内存；TTL联动ZSET热度排名，避免冷数据长期占内存 | |RAG落地| PDFBox+LangChain+Chroma+BGE-Reranker | 结构化解析→语义分块→向量检索→重排序→溯源拦截，形成闭环 |

🔹 新手避坑指南

• ❌ 不要用@Scheduled轮询查Kafka消费进度 → 改用Kafka Consumer Group Offset自动提交
• ❌ 不要将JWT Token存在Redis String → 改用Redis Set（支持快速剔除黑名单Token）
• ❌ 不要给所有Embedding模型配相同chunk size → 代码类用256，文档类用512，对话类用128

💡一句话总结：大厂面试不考“会不会”，而考“为什么这么选”——每个技术决策背后，都是对业务规模、故障成本、演进成本的权衡。

本文首发CSDN，转载请联系作者。谢飞机已入职某音视频AIGC团队（P7），正在重构他们的RAG Pipeline…