互联网大厂 Java 面试燕双非在“本地生活即时配送”场景下被面试官连续追问下面是一场围绕本地生活即时配送业务展开的 Java 面试实录。候选人“燕双非”对简单问题能答上来复杂问题则开始含糊其辞面试官严肃追问并循序渐进深入到技术与业务落地。第一轮订单创建与接口设计面试官你们做即时配送系统用户下单后怎么设计订单接口如果前端要实时看到订单状态变化你会怎么考虑燕双非我会先用 Spring Boot 提供 REST 接口订单创建返回订单号状态查询接口单独放一个。实时状态的话可以再开一个 WebSocket前端订阅订单状态变化。这样用户下单后能看到“已接单、骑手取货、配送中、已送达”。面试官可以起码方向是对的。那如果订单创建后要调用风控、库存、配送调度三个服务你怎么保证接口稳定性燕双非嗯……可以用 Spring Cloud服务之间调用加个超时和重试失败了就降级。然后用消息队列把一些非核心流程异步化。面试官你说到了异步化那订单创建接口的幂等怎么做燕双非这个……应该可以加个唯一请求号吧数据库里做唯一索引重复提交就拦掉。然后 Redis 里也可以做一下幂等校验。面试官思路基本对至少知道要防重复提交。继续。面试官如果要把订单信息返回给前端你会怎么序列化你更偏向 Jackson 还是 Gson为什么燕双非我一般用 JacksonSpring Boot 默认也比较方便注解支持多和 REST 接口集成比较顺。Gson 也能用但我平时用得少。第二轮高并发、缓存与消息一致性面试官即时配送高峰期会有大量抢单请求数据库扛不住的时候你怎么优化燕双非可以先用 Redis 做缓存把热数据比如商家营业状态、骑手在线状态、热门区域的配送规则缓存起来。再加限流和队列削峰避免请求直接打到数据库。面试官那缓存和数据库一致性怎么保证比如商家把营业状态从“营业中”改成“休息中”。燕双非这个……一般先改数据库再删缓存或者先删缓存再改数据库我记得有个双删策略。面试官说得不完整。那你继续说说为什么要双删燕双非因为并发下可能会读到旧值双删就是先删缓存更新数据库后再删一次减少脏数据残留时间。具体我平时都是按框架封装好的方式做。面试官嗯至少知道场景。那订单状态变更这么频繁你会用什么方式通知其他服务燕双非可以用 Kafka。比如订单创建后发一个“订单已创建”事件调度服务、通知服务、风控服务分别消费。这样解耦吞吐也高。面试官如果消息重复消费或者消费失败呢燕双非重复消费要做幂等消息里带业务唯一键失败的话可以重试实在不行进死信队列人工补偿。不过我有时候觉得消息队列一上问题就都能解决了。面试官“都能解决”这句话在面试里一般不太安全。继续往下。面试官如果你要做一个抢单功能如何避免多个骑手同时抢到同一单燕双非可以用 Redis 分布式锁抢单时先加锁抢到锁的人才能操作或者数据库层面用乐观锁更新状态时检查版本号。面试官两个方案都提到了不错。那你觉得哪个更适合燕双非嗯……高并发场景我会优先考虑 Redis 锁配合数据库乐观锁Redis 负责快速互斥数据库最终兜底。第三轮可观测性、权限与云原生落地面试官现在系统已经上线了。用户说“下单成功但骑手没看到”你怎么排查燕双非先看日志Logback 或 Log4j2 都可以再看链路追踪比如 Jaeger 或 Zipkin确认订单事件有没有正常发出去、调度服务有没有消费到。指标方面还能看 Prometheus 和 Grafana观察 MQ 积压和接口错误率。面试官可以至少知道从日志、链路、指标三条线入手。那如果订单数据里要做权限控制商家、骑手、用户、运营后台权限不一样你怎么设计燕双非可以用 Spring Security 做认证授权登录后发 JWT。然后根据角色和资源权限控制接口访问后台再做细粒度的菜单权限和数据权限。面试官如果要接入企业统一身份中心呢燕双非可以考虑 OAuth2统一登录后拿 token。若公司有 Keycloak 这种也可以对接标准协议减少自己造轮子。面试官最后一个问题如果你的服务要部署到 Kubernetes上线后要保证弹性和快速扩缩容你会关注哪些点燕双非要关注健康检查、无状态化、配置外置、镜像版本管理还有 HPA 自动扩缩容。服务发现和配置也尽量交给平台处理避免单机依赖。面试官回答比前面顺一点但还不够深入。今天先到这里你回去等通知吧。面试问题详细解答1. 订单接口与 WebSocket 实时状态在本地生活即时配送场景中订单创建接口通常负责完成基础校验、生成订单号、落库、返回受理结果。若前端需要实时看到状态变化可使用WebSocket或基于 SSE 的推送方案。WebSocket 适合双向通信常用于“订单状态面板”“骑手轨迹展示”等场景。对于 Java 服务端Spring Boot 可以快速接入 WebSocket并与业务事件驱动模型结合。2. 服务调用稳定性与幂等订单创建后常需串联风控、库存、调度等服务。为了避免链路过长导致接口超时应尽量把非核心流程异步化例如通过Kafka或RabbitMQ发送事件。稳定性方面要设置超时、重试、熔断与降级Resilience4j是常见选择。幂等是电商、配送、支付类系统的核心要求通常使用请求唯一号、业务唯一键、数据库唯一索引、Redis 幂等标记等方式组合实现。3. JSON 序列化选择Jackson是 Spring 生态最常见的 JSON 库注解丰富、性能稳定、与 Spring Boot 集成天然友好。Gson更轻量但在复杂日期格式、字段定制化、生态集成方面通常不如 Jackson 常用。业务上如果项目已使用 Spring Boot大多数团队会直接默认 Jackson。4. 高并发下的缓存优化与一致性高峰期读多写少的数据例如商家营业状态、骑手在线状态、区域配送费率适合放入Redis或本地缓存如Caffeine。缓存的价值在于削减数据库压力、降低接口延迟。缓存与数据库一致性常见方案包括先更新数据库再删除缓存、延迟双删、消息驱动失效、订阅 binlog 等。面试中常说的“双删”适用于并发写场景目标是尽量缩短脏缓存存在的窗口但它不是绝对强一致方案更多是折中方案。5. 消息驱动与重复消费处理订单创建后发送事件给调度、通知、风控等下游服务可以实现系统解耦。Kafka更适合高吞吐日志与事件流RabbitMQ更适合复杂路由和业务消息JMS则常见于传统企业应用。消息系统必须考虑重复投递、乱序、延迟、堆积、失败重试。消费者端要做幂等处理例如“订单号 事件类型”作为唯一键失败后可重试超过次数进入死信队列结合人工补偿或定时任务修复。6. 抢单与并发控制抢单场景是典型并发控制问题。常见方案包括Redis 分布式锁适合快速互斥但要注意锁超时、误删、续期和可重入问题。数据库乐观锁通过 version 字段控制并发更新简单可靠最终一致性好。悲观锁适合竞争极强但吞吐要求没那么高的场景。实际落地通常是“Redis 锁 数据库乐观锁”组合Redis 负责第一道快速互斥数据库负责最终正确性兜底。7. 可观测性日志、链路、指标排查“下单成功但骑手没看到”这类问题必须构建可观测体系-日志Logback、Log4j2、SLF4J 统一输出关键字段包含 traceId、订单号、用户ID。-链路追踪Zipkin、Jaeger 用于查看请求在各服务间的流转。-指标监控Prometheus Grafana 监控接口耗时、错误率、MQ 积压、消费延迟。有了这三层才能快速判断是接口没发消息、消息没被消费还是消费后写库失败。8. 权限体系与统一身份配送平台涉及多角色用户、骑手、商家、客服、运营。通常需要基于Spring Security构建认证授权体系并使用JWT做无状态令牌。若接入统一身份中心则可采用OAuth2或对接Keycloak。权限设计应区分认证、角色权限、资源权限、数据权限。例如骑手只能看到自己的配送单商家只能看自己的门店订单运营则需要更高权限与审计能力。9. Kubernetes 部署要点在 Kubernetes 上部署 Java 服务时核心关注点包括-无状态化会话尽量外置到 Redis不依赖本机内存。-健康检查liveness/readiness 探针保证实例可用性。-配置外置使用 ConfigMap、Secret 管理配置和敏感信息。-自动扩缩容基于 CPU、QPS、延迟等指标做 HPA。-灰度发布配合流量治理降低上线风险。这些能力能让配送业务在午高峰、晚高峰等流量波峰下保持稳定。10. 延伸理解为什么这些技术组合在一起本地生活即时配送本质上是一个高并发、强时效、强事件驱动系统。前台订单入口需要快后台调度需要稳消息链路需要可追踪权限体系需要严谨云原生部署需要弹性。Java 技术栈之所以常见是因为它在工程化、稳定性、生态完整度上非常适合这类大厂场景。感谢阅读希望这篇文章能帮助大家更好地理解互联网大厂 Java 面试中的真实业务问题与技术考察方式也希望对你的求职准备有所帮助。