Spring Boot Kafka Redis Spring Security互联网大厂 Java 面试实录场景某互联网大厂的“本地生活服务 会员营销 风控”业务线严肃面试官与搞笑水货程序员燕双非展开三轮面试。第一轮订单与优惠券接口设计面试官你们的本地生活服务里用户下单、领券、核销都很频繁。如果用 Spring Boot 来搭一个优惠券服务你会怎么组织项目结构燕双非我一般先把 controller、service、dao 分好再把配置、实体、DTO 分开Spring Boot 启动类放根包下扫描就省事。简单场景我还会加上 Spring MVC 做接口分层方便前后端联调。面试官不错分层思路清楚。那如果优惠券库存扣减要保证不超卖你会怎么做燕双非这个我知道一点可以先用 Redis 预扣减再异步落库如果怕并发高就加分布式锁或者 Lua 脚本做原子操作。数据库层面再用乐观锁兜底。面试官很好知道先快后稳。那你说说为什么不直接在 MyBatis 里开个事务更新库存就完了燕双非嗯……因为并发太高的话数据库扛不住锁冲突也会比较严重。Redis 先顶住流量数据库做最终一致性整体会更稳一点。面试官这个理解方向对了。最后一个问题接口响应你会用 Jackson 还是 Gson为什么燕双非我一般优先 Jackson和 Spring Boot 集成默认就比较顺手注解也多性能和生态都不错。Gson 也能用但项目里一般还是 Jackson 多。第二轮会员画像与风控消息链路面试官现在优惠券服务上线了用户行为、风控命中、会员成长值都要实时同步。你会怎么设计消息链路燕双非我会用 Kafka 做主链路订单创建、支付成功、券核销这些事件都发到 topic 里消费者分别处理画像、积分、风控。这样解耦比较好也方便扩展。面试官不错事件驱动意识有了。那你怎么保证消息不丢、不重燕双非不丢的话生产端要确认消息发送成功消费端要幂等最好结合业务唯一键去重。重复消费就算来了也不能把积分加两次。面试官很好。那如果风控规则要支持灰度发布和快速回滚你会选什么配置和治理手段燕双非我可能会把规则配置放在配置中心配合 Spring Cloud 或者 Consul 做动态刷新。灰度的话可以按用户标签、城市、商户维度分流回滚就直接切版本或者回退配置。面试官思路可以。那 Kafka 消费端如果出现堆积你会怎么排查燕双非先看消费组 lag再看机器 CPU、GC、磁盘和网络。然后看是不是下游数据库慢或者单条消息处理太重。必要时扩容 consumer 实例或者增加并行度。面试官回答得还行至少知道先看哪里。第三轮搜索、监控与 AI 助手面试官我们现在要做一个“智能客服 商家知识库”系统支持自然语言语义搜索。你会如何把 AI 能力接入到现有 Java 系统里燕双非我会考虑用 Spring AI 做统一接入把大模型、向量库、工具调用这些能力封装起来。用户提问后先做文档加载和向量化再去 Milvus、Chroma 或 Redis 里做语义检索把相关文档拼到提示词里最后交给模型生成回答。面试官不错已经能说出 RAG 了。那如果模型出现幻觉你怎么控制燕双非一方面要限制回答范围只让它基于检索到的知识回答另一方面要做提示填充明确要求“不知道就说不知道”。再配合结果校验、置信度阈值和人工兜底能缓解很多。面试官很好。再说一个工程问题智能客服的长会话上下文怎么管理燕双非可以做聊天会话内存按用户维度保存最近几轮对话摘要和关键状态。太长的历史要做压缩不然 token 成本会很高。复杂工作流场景还可以把会话状态和工具执行框架结合起来。面试官最后一个问题整个系统上线后你怎么监控燕双非我会用 Micrometer 接 Prometheus 和 Grafana看接口延迟、错误率、Kafka 堆积、向量检索耗时、模型响应时间。链路追踪可以接 Zipkin 或 Jaeger日志统一用 SLF4J 配合 Logback 或 Log4j2便于排查。面试官嗯回答比前面完整一些。行了今天先到这里你回去等通知吧。问题详解1. Spring Boot 优惠券服务如何设计分层在本地生活优惠券场景中常见分层是 controller、service、repository/dao、domain、DTO、config。Controller 负责接收请求与参数校验Service 处理领券、核销、库存扣减等核心业务DAO 负责数据库读写DTO 用于接口输入输出隔离。Spring Boot 与 Spring MVC 结合可快速完成 REST 接口开发并通过统一异常处理、参数校验、AOP 日志增强可维护性。2. 为什么优惠券库存常用 Redis 预扣减 DB 落库优惠券秒杀或高峰期领券场景下直接操作数据库会面临锁竞争和吞吐瓶颈。Redis 可利用单线程原子性或 Lua 脚本实现原子预扣减先拦截超卖请求再通过消息异步写库降低数据库压力。最终由数据库事务和乐观锁做兜底保证最终一致性。该方案本质是“前置限流、异步削峰、数据库兜底”。3. Jackson 为什么常用于 Spring Boot 接口序列化Jackson 与 Spring Boot 生态集成度高默认即为常用 JSON 序列化方案支持注解、日期格式化、字段别名、自定义模块等。相比 GsonJackson 在 Spring 体系里更容易统一配置且与 RestTemplate、WebFlux、OpenFeign 等组件配合自然适合企业级后端接口场景。4. Kafka 在会员画像和风控链路中的作用是什么Kafka 适合做高吞吐、可扩展的事件总线。在订单创建、支付成功、券核销等业务中核心系统只需发出事件会员画像、积分增长、风控校验等下游系统通过订阅 topic 异步消费实现业务解耦。这样既提升系统弹性也方便后续新增消费者而不影响上游。5. 如何保证消息不丢不重生产端可使用确认机制、重试机制和持久化配置降低丢消息风险消费端必须实现幂等常见做法包括业务唯一键去重、消费日志表、Redis 去重、状态机校验等。若要求更强一致性可结合事务消息或本地消息表模式。实际工程中最关键的是“消费端幂等”因为消息系统通常默认至少一次投递。6. 风控规则如何支持灰度发布可将规则配置化并集中管理通过配置中心动态刷新。业务路由层按用户、城市、商户、设备特征做分流逐步放量。出现问题时只需回退配置或切换版本即可快速回滚。若配合 Spring Cloud、Consul 等组件可以实现规则服务的动态发现与配置热更新。7. Kafka 消费堆积如何排查先看消费组 lag判断堆积程度再看 consumer 实例数、分区数是否匹配随后检查下游数据库、RPC、缓存、外部依赖是否慢同时观察 CPU、GC、网络、磁盘和线程池状态。优化方式包括扩容消费者、提升并行度、拆分重任务、批处理、异步化以及降低单条消息处理耗时。8. Spring AI 在企业 AI 场景中的价值是什么Spring AI 目标是为 Java 生态提供统一的大模型接入方式降低与不同模型、向量数据库、工具调用系统的集成成本。在智能客服、企业知识库、员工助手、文档问答等场景中它能帮助开发者快速搭建 RAG、Agent、工具调用和会话记忆能力让 AI 能力更容易融入现有 Spring 体系。9. 什么是 RAG为什么能缓解幻觉RAG 即检索增强生成先从企业文档库、知识库、FAQ、工单系统中检索相关内容再把检索结果注入提示词交给模型生成答案。这样模型回答时不完全依赖参数记忆而是基于真实业务资料能显著降低幻觉。配合提示约束“仅基于检索内容回答”可以进一步提升可信度。10. 长会话上下文为什么要做压缩LLM 的上下文窗口有限历史消息过多会导致 token 成本飙升、响应变慢甚至超限。工程上通常保留最近几轮对话、关键实体和摘要信息对无关冗余内容进行压缩。会话记忆可按用户或会话 ID 存储在 Redis、数据库或专门的记忆模块中兼顾性能和一致性。11. 系统上线后如何监控 AI 与消息链路可使用 Micrometer 统一采集业务指标接入 Prometheus 与 Grafana 看延迟、错误率、QPS、队列堆积、向量检索耗时、模型调用耗时等指标。日志可通过 SLF4J 配合 Logback 或 Log4j2 统一输出链路追踪可用 Jaeger 或 Zipkin。对于 AI 场景还应特别关注 token 消耗、命中率、召回率和人工兜底率。12. 业务中为什么要将工具调用标准化在智能客服、复杂工作流、Agentic RAG 场景中模型可能需要调用查订单、查物流、查库存、创建工单等内部工具。若接口协议不统一后续扩展和治理成本很高。标准化工具调用可以让模型、编排层和业务系统之间形成清晰的契约便于权限控制、审计、重试与观测也更利于扩展能力接入。感谢阅读希望这篇互联网大厂 Java 面试实录能帮助你更好地准备面试、理解业务与技术结合的方式也祝你在求职路上稳步上岸。