Java 面试实录：Spring Boot + Kafka + Redis + AI/RAG 在互联网大厂业务中的 3 轮深度追问

Java 面试实录Spring Boot Kafka Redis AI/RAG 在互联网大厂业务中的 3 轮深度追问场景设定互联网大厂 Java 面试现场严肃面试官正在考察候选人燕双非。燕双非属于“会一点、但不多”的类型简单题能接住复杂题就开始左右横跳。面试官一边追问一边顺手把业务场景往深处带。第一轮内容社区的帖子发布链路面试官我们先从内容社区说起。用户发一篇帖子后前端到后端的整体链路你怎么设计燕双非先用Spring Boot接收请求做参数校验然后写入数据库成功后返回发布成功。接口层我会配合Swagger/OpenAPI生成文档方便前后端联调。面试官不错至少能把主干讲清楚。那如果帖子里有图片、视频、标签还要支持敏感词校验和审核流你怎么拆燕双非嗯……可以拆成几个服务。内容服务负责落库审核服务负责校验媒体服务负责文件上传。中间可以用Kafka异步通知避免主流程太慢。面试官方向对了。那 Kafka 异步后如何保证消息不丢、不重复燕双非不丢的话生产者要确认一下消费者处理完再提交 offset。重复的话……应该可以做幂等比如用帖子 ID 做去重。面试官回答还可以说明你至少接触过生产级思路。那帖子发布成功后首页列表和个人主页都要高频读取你怎么做缓存燕双非可以用Redis做缓存热点帖子单独设置过期时间。列表页可以做缓存预热减少数据库压力。第二轮交易与风控的接口设计面试官现在切到电商/支付场景。用户下单后要完成扣库存、扣券、发消息、记账这一套你怎么处理燕双非这个我熟先让订单服务创建订单然后通过Kafka发事件库存、券、账务几个服务各自消费。面试官如果库存扣减成功了账务失败了怎么办燕双非那就……重试吧。实在不行就补偿。可以设计一个状态机订单状态从待支付到处理中再到成功或失败。面试官补偿思路是对的。那你怎么避免并发下超卖燕双非可以用数据库乐观锁或者在Redis里做预扣减再异步落库。高并发时尽量减少同步锁竞争。面试官那风控怎么做比如同一用户频繁支付失败、异地登录、设备异常。燕双非可以在网关或风控服务里做规则判断结合Spring Security和JWT识别用户身份再基于行为特征做拦截。日志可以接ELK方便追踪异常链路。面试官继续往下说如果风控规则需要快速调整怎么做到不频繁发版燕双非嗯……规则配置化吧放到配置中心或者数据库里服务启动后加载定时刷新。面试官可以至少知道要把“规则”和“代码”分离。第三轮AIGC 智能客服与企业知识问答面试官最后来个热点题。假设你要做一个企业智能客服系统支持知识库问答、工单分流、人工兜底和多轮对话你怎么设计燕双非我会先做一个聊天服务用Spring AI接大模型再把企业文档做清洗、切分、向量化存到向量数据库里比如Milvus。用户提问后做语义检索召回相关文档再把结果拼到提示词里让模型生成答案。面试官不错已经开始像个正经人了。那为什么要做 RAG而不是直接让模型回答燕双非因为模型本身不一定知道企业内部知识而且容易幻觉。RAG 可以结合检索到的真实文档提升准确率和可解释性。面试官如果客服系统要支持多轮上下文你怎么管理会话记忆燕双非可以做聊天会话内存把当前会话的关键轮次、用户画像、工单状态保存下来。上下文太长时做摘要压缩避免 token 爆掉。面试官好。那如果用户问“你们退款多久到账”模型答错了如何降低幻觉影响燕双非我会加检索置信度阈值低于阈值就引导转人工同时把回答限定在知识库证据范围内必要时要求模型引用来源。对于高风险问题直接走规则和人工审核。面试官最后一个问题整个系统怎么做可观测性燕双非可以用Micrometer打指标接Prometheus和Grafana看监控链路追踪用Jaeger或Zipkin日志统一用SLF4J Logback输出便于排查检索、模型调用、消息消费等问题。面试官嗯思路基本完整了。今天先到这里你回家等通知吧。问题详解与业务化拆解一、内容社区帖子发布链路1Spring Boot 接口层设计在内容社区里发帖接口通常承担参数校验、身份鉴权、幂等控制、落库和异步通知等职责。Spring Boot 适合快速构建 REST 接口可结合 Swagger/OpenAPI 输出接口文档提升前后端协作效率。2Kafka 异步解耦帖子发布完成后审核、推荐、索引、通知等动作不应该阻塞主链路。使用 Kafka 发布领域事件可以把这些动作拆分到不同消费者中并行处理。为了保证可靠性生产者要关注确认机制消费者要做幂等处理和重试补偿。3