Java 大厂面试实录Spring Cloud Kafka Redis Elasticsearch Docker Kubernetes 的电商履约链路深挖场景互联网大厂 Java 求职面试业务背景为电商订单与履约系统。第一轮从下单到订单创建面试官我们先聊一个基础场景。用户在大促期间下单你会如何设计订单创建接口保证高并发下不重复下单燕双非这个我熟。先用 Redis 做一个下单标记用户点提交的时候先 setnx 一下如果成功就继续创建订单失败就提示重复提交。数据库里再加唯一索引兜底。这样就比较稳。面试官思路不错。那如果订单创建后要同步写库存、优惠券、积分你会同步做还是异步做燕双非我一般会先把核心订单落库然后把后续动作丢到 Kafka 里异步处理。这样主链路快一点库存、积分、短信通知都可以解耦。面试官那 Kafka 消息重复消费怎么办燕双非嗯……这个可以做幂等吧。比如用订单号做唯一键消费前先查 Redis 或数据库判断有没有处理过。要是已经处理过就直接跳过。面试官可以说明你对幂等和削峰有基本认识。继续往下走订单创建成功后你如何把数据展示给用户并支持订单列表快速检索燕双非列表我会先查数据库如果压力大就加缓存。搜索的话可以把订单索引同步到 Elasticsearch这样按订单号、商品名、状态查起来会快很多。第二轮履约、风控与可用性面试官很好。现在进入履约链路。订单支付成功后需要自动拆单、发货、同步物流状态。你怎么设计微服务之间的调用燕双非我会用 Spring Cloud 做服务治理服务之间通过 OpenFeign 调用。支付成功后发一个订单已支付事件拆单服务、库存服务、物流服务各自订阅 Kafka 消息处理。面试官如果物流服务偶发超时不能拖垮整个系统你怎么办燕双非可以加 Resilience4j 的熔断和限流。比如物流接口慢了就快速失败降级返回“已受理稍后更新”。面试官那如果我们要求用户能实时看到物流轨迹前端怎么拿到变化燕双非可以用 WebSocket 推送。物流状态一变后端主动推给前端不用前端老是轮询。面试官很好。现在加一点风控。订单、支付、地址变更都需要鉴权你会怎么做安全设计燕双非登录后签发 JWT网关校验 token再配合 Spring Security 做权限控制。高风险操作可以二次校验或者接 OAuth2 统一授权。面试官如果是内部系统既要对外部合作方开放 API又要保证审计合规呢燕双非嗯……可以给合作方单独发 client_id 和 secret限制 scope所有调用都记录审计日志。敏感操作再走签名校验。面试官可以开始像个业务系统设计人了。第三轮上线、压测与排障面试官最后一轮我们看工程化能力。这个系统上线到 Kubernetes怎么做灰度发布和健康检查燕双非容器化用 Docker 打包镜像部署到 Kubernetes。通过 readinessProbe 和 livenessProbe 做健康检查滚动发布时先放少量流量没问题再全量切过去。面试官监控怎么做出了问题你怎么快速定位燕双非我会接 Micrometer 暴露指标Prometheus 抓取Grafana 看看 QPS、P99、错误率。日志统一到 ELK链路追踪用 Jaeger 或 Zipkin。出问题先看慢在哪个服务再顺着 trace 找下游。面试官测试层面你会怎么保障这条链路燕双非单测用 JUnit 5 和 Mockito核心服务写集成测试Kafka 消费和数据库写入也跑一下。接口回归可以加自动化测试关键支付流再做冒烟校验。面试官如果让你补一条 AI 能力给订单客服做一个智能问答你会怎么接燕双非可以搞个 RAG把订单规则、售后政策、物流文档先做向量化存到向量数据库里。客服提问时先做语义检索再把检索结果喂给大模型尽量减少幻觉。复杂工单可以做 Agent 工作流自动查订单、查物流、查退款状态。面试官思路有点意思。今天先到这里吧你回去等通知。面试题详解1. 如何防止高并发下重复下单典型做法是“前置拦截 数据库兜底”。前置可以使用 Redis 的 setnx、分布式锁或幂等 token兜底则依赖数据库唯一索引例如用户 id 商品 id 活动 id 组合唯一。业务上要注意提交幂等、支付幂等、消息消费幂等是三件不同的事不能混为一谈。2. 为什么订单创建后适合异步化订单主链路最重要的是快和稳。库存扣减、积分发放、短信通知等都不是“必须立刻完成”的核心逻辑适合通过 Kafka 解耦。这样可以削峰填谷降低主链路时延同时也方便后续扩展更多消费者。3. Kafka 消息重复消费如何处理Kafka 天然可能出现重复投递或重复消费因此消费者侧必须设计幂等。常见方法包括业务唯一键去重、状态机判断、消费表记录、Redis 去重标记等。以订单场景为例可以在订单状态流转表里保存“已处理事件 id”再次消费时先判断是否处理过。4. 为什么订单列表要结合 Elasticsearch订单列表通常会有多条件查询、模糊搜索、筛选排序等需求关系型数据库在复杂检索和高并发查询下会吃力。将订单数据同步到 Elasticsearch 后可以对订单号、商品名、收货人、状态等字段做高效检索。需要注意 ES 适合搜索不适合做强事务核心账务。5. 微服务之间为什么用 Spring Cloud OpenFeignSpring Cloud 提供服务治理能力OpenFeign 让服务间 HTTP 调用更声明式、可维护。实际项目里还要结合注册中心、负载均衡、超时设置、重试策略和降级策略避免“调用很方便但系统很脆弱”。6. Resilience4j 主要解决什么问题它用于提升系统韧性包括限流、熔断、隔离、重试、时间限制等。电商履约中如果物流或第三方接口不稳定应该让系统快速失败并降级而不是把线程卡死导致雪崩。7. WebSocket 适合什么场景WebSocket 适合服务端主动推送、低延迟双向通信场景比如物流状态变化、订单支付结果、实时客服消息等。它比轮询更节省资源用户体验也更好但要注意连接管理、心跳、断线重连和网关兼容。8. JWT、Spring Security、OAuth2 如何分工JWT 常用于无状态令牌承载用户身份信息Spring Security 负责认证与授权框架落地OAuth2 则更偏向“授权协议”和第三方接入场景。内部系统可以 JWT Spring Security 实现权限控制对外开放接口则常配合 OAuth2 做标准化授权。9. Kubernetes 上线时健康检查为什么重要readinessProbe 决定实例是否接收流量livenessProbe 决定实例是否需要重启。对于依赖数据库、缓存、消息队列的 Java 服务启动后不代表“可用”必须通过健康检查确保依赖初始化完成否则会出现流量打到半死不活的实例。10. Micrometer、Prometheus、Grafana 怎么配合Micrometer 负责统一埋点和暴露指标Prometheus 负责拉取与存储指标数据Grafana 负责展示和告警。电商系统可以重点观察下单接口延迟、Kafka 积压、Redis 命中率、数据库连接池耗尽、错误率等指标。11. JUnit 5 和 Mockito 在测试中的价值是什么JUnit 5 提供现代化测试框架能力Mockito 适合模拟依赖对象。对于订单服务这种依赖数据库、消息队列、外部接口较多的系统单测中应隔离外部依赖验证业务分支与异常路径再用少量集成测试验证链路连通性。12. RAG 在智能客服系统中如何落地RAG 的核心是“先检索再生成”。在电商客服场景中可以把退款规则、配送规则、商品售后政策、FAQ、工单处理文档做切分、向量化和入库用户提问时先做语义检索再把相关知识作为上下文交给大模型生成答案从而减少幻觉提高答案可追溯性。13. Agent 为什么适合复杂业务工作流Agent 的优势在于能根据目标自主选择工具。比如“查一下用户退款进度并给出原因”Agent 可以按步骤调用订单服务、支付服务、物流服务、知识库检索等工具形成一个可执行工作流。它比单轮问答更适合多步骤任务。以上就是本次互联网大厂 Java 面试实录的全部内容。希望这篇文章能帮助大家在微服务、电商履约、工程化上线和 AI 增强系统等方向建立更清晰的知识框架。感谢阅读希望能真正帮助到你。
