尧图建网站 尧图建网站 YAOTU WEB BUILD 免费咨询
ARTICLE DETAIL

资讯详情

深耕网站建设与建站编程的一线实战洞察。

Java 大厂面试实录:Spring Boot + Kafka + Redis + Spring AI + Kubernetes 的 12 道高频追问

Java 大厂面试实录:Spring Boot + Kafka + Redis + Spring AI + Kubernetes 的 12 道高频追问 Java 大厂面试实录Spring Boot Kafka Redis Spring AI Kubernetes 的 12 道高频追问场景一家互联网大厂的 Java 社招面试现场业务方向是电商秒杀 智能客服。面试官严肃专业候选人是外号“水货程序员燕双非”的求职者。规则三轮递进式提问每轮 3-5 个问题问题从业务到技术逐步深入。燕双非对简单题能勉强答上来答得好时面试官会顺势夸赞并继续追问遇到复杂题则开始含糊其辞、语焉不详。第一轮系统设计与基础链路面试官我们先聊一个电商秒杀场景。假设大促时商品详情页 QPS 很高你会怎么设计 Java 服务的整体架构燕双非我会先把服务拆开商品服务、订单服务、库存服务分开。用 Spring Boot 起服务前面再加个网关缓存放 Redis数据库扛不住的地方尽量别直接打库。面试官思路还行至少知道“别让数据库硬扛”。那商品详情页里哪些数据适合缓存哪些不适合燕双非商品基础信息、价格、活动配置这些可以缓存库存这种变化特别快的要谨慎或者加比较短的过期时间另外要防止缓存击穿、穿透……面试官不错能说到击穿和穿透说明不是完全靠背。那如果 Redis 挂了你准备怎么兜底燕双非嗯……可以本地再加一层缓存或者直接降级成返回默认值。再不行就让用户稍等系统提示“当前访问人数较多”。面试官至少知道要有降级意识。最后一个基础问题Spring Boot 里你通常怎么管理配置线上和本地怎么区分燕双非我一般用 application.yml再配 spring profiles。比如 dev、test、prod 分开敏感配置放到配置中心或者环境变量里。第二轮消息削峰与一致性面试官好进入秒杀下单流程。用户点击抢购后你会怎么避免库存被打爆燕双非我会先做接口限流然后请求进来后写 Kafka异步处理下单。前台先返回“已受理”后面慢慢落库。面试官用了 Kafka说明你知道削峰。那如果消息重复消费了怎么办燕双非额这个要做幂等。比如订单号唯一数据库加唯一索引或者消费前先查 Redis 里有没有处理过。面试官可以。那你觉得“先写 Kafka 再扣库存”和“先扣库存再写 Kafka”哪个更合理燕双非我觉得……都行吧主要看业务。一般就是先把关键数据保存好然后让异步系统慢慢处理。面试官“都行吧”在大厂面试里通常不太行。你要是做订单系统怎么保证库存、订单、支付状态之间的一致性燕双非嗯可以用事务……但跨服务就比较麻烦。可能要用最终一致性比如订单创建成功后发消息库存服务和支付服务各自消费失败就重试实在不行走补偿。面试官这就开始像个工程师了。那重试和补偿怎么设计避免“雪崩式补偿”燕双非这个……可以给消息加重试次数和死信队列补偿任务定时扫表。再配合监控看失败率人工介入。面试官行至少知道要留后手。再问你一个 MyBatis 的问题你在高并发场景下会怎么优化数据库访问燕双非减少 SQL 次数避免 N1分页要走合理索引连接池用 HikariCP慢 SQL 通过日志和监控定位。面试官不错回答已经比开头像样了。第三轮智能客服与云原生演进面试官现在公司想做一个智能客服系统用户会问“我的订单为什么还没发货”。你会如何引入 Spring AI 和 RAG燕双非我会先把订单、物流、售后文档做向量化存到向量数据库里。用户提问时先做语义检索找到相关文档再把检索结果喂给大模型生成答案。面试官很好已经接近正确答案了。那为什么不能只靠大模型直接回答燕双非因为它可能会幻觉瞎编。尤其是订单状态这种强业务场景必须结合企业文档和实时数据不然容易把用户带沟里。面试官对。那如果客服问题需要调用“查订单”“查物流”“改地址”这类工具你会怎么做工具调用标准化燕双非可以把这些能力包装成工具让 Agent 根据意图决定调用哪个服务。工具入参、返回值尽量统一避免每个接口都写一套特殊适配。面试官说得还行。最后问一个云原生问题这套客服和订单服务都要部署到 Kubernetes你如何做健康检查、监控和灰度发布燕双非健康检查用 readiness 和 liveness监控用 Micrometer 接 Prometheus再在 Grafana 看图。灰度的话可以分批发布或者按流量比例切一小部分到新版本。面试官嗯云原生这块你至少不是完全空白。那如果我再追问一句线上某个智能问答接口延迟突然升高你怎么排查燕双非先看监控指标再看日志和链路追踪可能是向量检索慢、模型接口慢或者某个下游服务超时。然后按调用链一步一步缩小范围。面试官行了今天先到这。你回去等通知吧。面试题详细解答1. 电商高并发场景的整体架构怎么设计典型思路是按业务拆分服务商品、库存、订单、支付、营销等。Java 技术栈上常见组合是 Spring Boot Spring MVC / WebFlux、Redis、MyBatis / JPA、Kafka、Kubernetes。核心原则是把“读多写少”的数据提前缓存把“必须强一致”的写操作收敛到少数关键链路并通过限流、降级、熔断、异步化来保护系统。在秒杀场景里最怕的是请求直接打到数据库。正确做法通常是前置网关限流、页面静态化或局部静态化、热点数据缓存、库存预扣、消息队列削峰、异步落库。2. 哪些数据适合缓存哪些不适合适合缓存的通常是商品详情、活动规则、配置类数据、用户画像摘要、常见查询结果。不太适合直接缓存的通常是变化极快且要求绝对实时的数据比如秒杀库存最终值、支付状态、风控强校验结果等。缓存设计要重点考虑缓存穿透查不存在的数据需用布隆过滤器或空值缓存。缓存击穿热点 key 失效瞬间大量请求穿透到数据库需用互斥锁、逻辑过期等方案。缓存雪崩大量 key 同时过期需设置随机过期时间和多级缓存。3. Redis 挂了怎么兜底可采用本地缓存、降级页面、静态兜底数据、读数据库限流等方式。关键是要先定义“系统降级后还能提供什么最小可用能力”例如商品页只展示基础信息库存不显示实时数值避免全站不可用。4. Kafka 在秒杀链路中的作用是什么Kafka 的作用是削峰填谷、异步解耦、提升吞吐。用户请求进入后可以先快速校验资格再把下单请求写入 Kafka由后端消费者异步完成库存扣减、订单创建、支付预创建等操作。这样做的好处是前端响应快系统整体更平滑坏处是引入了最终一致性需要处理重复消费、消息丢失、顺序问题、幂等问题。5. 如何保证消息重复消费也不会出错常见做法包括业务幂等键如订单号、请求号、支付流水号。数据库唯一索引用唯一约束拦截重复写入。消费日志表记录消息是否处理过。Redis 去重标记适合短期幂等防护。在支付、库存这类关键链路里通常会组合使用幂等键 数据库约束 失败重试。6. 如何设计库存、订单、支付的一致性跨服务一致性一般不用分布式强事务而是走最终一致性。常见模式有本地事务 消息可靠投递。事务消息 / Outbox 模式。Saga 补偿模式。例如订单创建成功后发出“库存预扣”消息库存服务消费后扣减成功再回写状态。若库存扣减失败则通过补偿任务释放订单或恢复库存。系统必须具备重试、补偿、对账、告警能力。7. MyBatis 在高并发场景如何优化重点是减少数据库访问次数和锁冲突合理建索引避免全表扫描。避免 N1 查询。控制单次返回数据量分页合理。批量写入减少频繁往返。连接池使用 HikariCP 提升连接获取效率。通过慢 SQL 日志、APM 和数据库监控定位瓶颈。8. 为什么不能只让大模型直接回答订单问题因为大模型可能出现 AI 幻觉生成看似合理但实际上错误的答案。像“订单是否发货”“退款到哪一步”这种问题必须结合企业实时数据、业务文档和流程状态。RAG的价值就在于先检索可信知识再让模型生成答案从而显著降低幻觉概率。9. Spring AI RAG 在智能客服里怎么落地典型链路是文档加载导入 FAQ、业务手册、工单知识库、订单规则。切分与向量化把文本切成适合检索的片段生成 embedding。向量存储写入 Milvus、Chroma 或 Redis 向量能力。语义检索用户提问后找出最相关片段。提示填充将检索结果与问题一起拼到 Prompt 中。大模型生成输出答案必要时附带引用来源。如果再结合实时接口查询订单、物流就可以做成 Agentic RAG检索知识 工具调用 结果汇总。10. 什么是工具调用标准化当 Agent 要调用“查订单”“查物流”“退货申请”时最好把每个能力都封装成统一格式的工具接口明确工具名、入参 schema、返回 schema、错误码和超时策略。这样模型更容易选择工具系统也更容易治理。这类架构常见于企业文档问答、智能客服、复杂工作流编排。工具执行框架可以把外部系统能力变成模型可理解、可调用、可追踪的动作。11. Kubernetes 上如何做健康检查、监控和灰度发布健康检查一般分为liveness进程是否还活着。readiness是否准备好接流量。监控层面可以使用 Micrometer 暴露指标Prometheus 采集Grafana 展示。日志系统可配合 ELK Stack链路追踪则可用 Jaeger 或 Zipkin。灰度发布通常通过分批滚动、流量染色、服务网格或网关路由实现。12. 线上延迟升高怎么排查排查思路是从“现象”到“链路”再到“单点”看监控QPS、RT、错误率、GC、CPU、内存、线程池。看日志是否有超时、重试、序列化异常。看链路追踪慢在模型接口、向量检索、数据库还是消息消费。看依赖Redis、Kafka、数据库、外部模型服务是否抖动。真正的大厂排障不是“我觉得是数据库”而是用指标和链路一步步证据化定位。总结这场面试从电商秒杀、消息削峰、一致性设计逐步深入到智能客服、RAG、Agent、Kubernetes 监控与灰度发布。对于 Java 求职者来说真正重要的不只是会背概念而是能把技术和业务场景连接起来讲清楚为什么这么设计、如何落地、出了问题怎么兜底。如果你正在准备大厂 Java 面试希望这篇实录能帮助你梳理思路、查漏补缺、提升表达。感谢阅读真心希望它能帮助到你。
返回列表