面试场景互联网大厂 Java 求职者面试电商履约 AI 智能客服第一轮基础能力与服务拆分面试官你先自我介绍一下重点说说你做过的电商履约相关项目技术栈里 Java 11、Spring Boot、MyBatis、Redis、Kafka 有没有实际用过燕双非用过用过Java 11 我主要拿来写更优雅的代码Spring Boot 一把梭MyBatis 负责和数据库聊天Redis 负责给接口加点速度Kafka 负责把消息发出去大家各司其职项目就稳了。面试官那你说说为什么订单创建后要先落库再发消息到 Kafka而不是先发消息再落库燕双非这个……一般都是先保证订单在数据库里有个“身份”然后再通知下游。要不然消息出去了订单没了就很尴尬像我面试答错题一样。面试官说得还可以。那如果消息发送成功了但本地事务回滚了你怎么处理燕双非可以用本地消息表或者事务消息确保最终一致性。嗯核心就是别让系统“口头承诺”太多得有证据。面试官那你再说说 Redis 在电商下单里的典型用法。燕双非库存预热、热点商品缓存、用户会话、验证码、限流都能用。尤其秒杀场景Redis 很像前台保安先拦一下别让后面系统挤爆。第二轮履约链路与容错设计面试官现在我们把场景升级成“本地生活平台下单”用户下单后要经过商户接单、配送调度、状态回传。你会怎么设计服务拆分燕双非我会拆成订单服务、商户服务、配送服务、通知服务。订单服务管主流程商户服务管接单配送服务管派单通知服务管短信和站内信。面试官不错继续。服务之间怎么通信同步调用还是异步消息为什么燕双非关键链路同步比如查订单状态非关键链路异步比如发通知、写日志、做推荐。这样能降低耦合慢服务别拖大家后腿。面试官如果商户接单接口抖动你怎么保证整个链路可用燕双非可以用 Resilience4j 做熔断、限流、重试、隔离。要是它一直抖就先让系统别跟它硬碰硬避免“感情用事”。面试官那你说说幂等怎么做比如配送回传状态重复上报。燕双非可以用业务唯一键加数据库唯一索引或者状态机校验只允许合法流转。重复请求来了就当它是“老熟人”不再重复处理。面试官那你觉得 Spring Cloud 里注册中心和网关分别解决什么问题燕双非注册中心负责服务发现网关负责统一入口、鉴权、路由、限流。一个管“人在哪”一个管“从哪进”。第三轮AI 智能客服与企业级落地面试官现在业务要加一个 AI 智能客服支持“订单状态查询、退款规则解释、物流异常解释”。你会怎么结合 Spring AI、RAG、向量数据库来做燕双非我会先把企业文档、FAQ、退款规则、物流知识库做文档加载然后切分、Embedding 向量化存到 Milvus 或 Redis 里。用户提问时先做语义检索把相关内容召回再交给大模型生成回答。面试官很好。那如果模型回答“听起来很对但其实是错的”你怎么降低幻觉燕双非要做检索增强生成、答案引用、提示词约束、置信度控制还要限制模型只能基于知识库回答。别让它自由发挥不然客服就变成“会说话的段子手”。面试官如果客服系统要支持复杂工作流比如先查订单再判断是否超时再决定是否自动退款你怎么设计 Agent燕双非可以把工具调用标准化给 Agent 配订单查询、规则判断、退款申请等工具。Agent 负责规划步骤工具负责干活这样更像一个会安排任务的“项目经理”。面试官最后一个问题企业里接入外部大模型接口你会如何考虑安全、审计和扩展能力燕双非要做 API 鉴权、日志审计、敏感信息脱敏、超时重试、灰度发布还要抽象客户端-服务器架构方便以后换模型、换向量库、换供应商。系统不能被某一家绑死。面试官嗯今天先到这里你回去等通知吧。问题详解1. 为什么订单先落库再发消息在电商、外卖、本地生活等场景中订单创建通常需要先完成数据库持久化再向消息队列发送事件。这样做的原因是数据库事务能保证本地一致性而消息用于通知下游服务异步处理。如果先发消息再落库一旦落库失败就会出现“消息已发出但订单不存在”的数据不一致问题。常见解决方案包括本地消息表、事务消息、Outbox 模式等核心目标都是保证最终一致性。2. Redis 在高并发下单中的作用Redis 常用于缓存热点数据、验证码、用户会话、购物车、秒杀库存、分布式锁和限流。在秒杀或大促场景中Redis 可以作为前置拦截层减少数据库压力。对于库存扣减可以采用原子操作、Lua 脚本或预扣库存策略避免超卖。还可以结合 Spring Cache 提升查询性能但要注意缓存穿透、击穿和雪崩问题。3. 服务拆分与通信方式在本地生活或电商履约链路中通常会按领域拆分订单服务、商户服务、配送服务、通知服务、风控服务等。服务间通信可按业务重要性选择同步或异步核心流程通常同步保证即时反馈非核心流程通过 Kafka、RabbitMQ、JMS 等消息队列异步处理以提高吞吐和解耦。对于跨服务调用建议配合服务发现、网关、超时控制和链路追踪。4. Resilience4j 的作用Resilience4j 提供限流、熔断、重试、隔离、舱壁等能力适合在下游服务不稳定时保护系统。比如商户接单接口抖动若无限重试可能放大故障合理的熔断可以快速失败给系统恢复时间。限流则能防止突发流量击穿系统保障核心用户体验。5. 幂等设计怎么做幂等是分布式系统里非常重要的能力尤其适用于支付回调、物流状态上报、消息重复投递等场景。常见方法包括业务唯一键 数据库唯一索引、状态机校验、去重表、分布式锁、Token 机制等。核心思想是同一请求重复执行多次结果与执行一次一致。6. Spring Cloud 中注册中心与网关注册中心用于服务注册与发现让调用方知道目标服务实例在哪里网关作为统一入口负责鉴权、路由、限流、灰度发布、协议转换等。二者结合可让微服务架构更易治理。常见组合包括 Eureka/Consul Spring Cloud Gateway/OpenFeign 等。7. Spring AI RAG 的企业客服落地在企业智能客服中单纯依赖大模型容易产生幻觉因此通常需要 RAG检索增强生成。流程一般是加载企业文档、清洗和切分文本、生成 Embedding、存入向量数据库如 Milvus/Chroma/Redis Vector用户提问时先进行语义检索再把召回内容连同问题一起交给模型生成答案。这样回答会更贴近企业事实减少胡说八道。8. 如何降低 AI 幻觉降低幻觉的方式包括控制提示词、限制模型仅基于检索结果回答、增加引用来源、设置拒答策略、加入规则引擎和人工兜底、对高风险问题进行白名单处理。对于退款、医疗、金融等敏感场景必须加入强约束和审计机制。9. Agent 与工具调用Agent 的核心是“规划 工具调用”。在复杂工作流里Agent 不直接瞎编答案而是根据任务目标调用订单查询、规则判断、退款申请、工单创建等工具再组合结果输出。工具调用标准化后系统扩展性更强后续新增能力时只需增加工具接口即可。10. 企业级 AI 接入的安全与扩展接入外部大模型时要关注身份认证、访问控制、敏感数据脱敏、审计日志、请求限流、超时重试、熔断降级、供应商可替换性。建议把模型调用封装成独立适配层避免业务代码直接依赖某个厂商 SDK。这样未来切换模型或向量库时改动范围更小。感谢阅读希望这篇文章能帮助你在 Java 面试中更从容地应对大厂高频问题也希望能对你的学习和进阶带来一点点启发。