Spring Boot Kafka Redis Elasticsearch Micrometer互联网大厂 Java 面试实录场景电商场景下的订单履约与营销推荐系统面试官严肃候选人是搞笑的水货程序员“燕双非”。燕双非背着双肩包坐下面试官翻开简历目光冷静。第一轮订单系统与基础架构面试官你们电商下单后订单服务怎么设计Spring Boot 里怎么拆分分层燕双非我一般先搞个 Spring Boot 单体把 controller、service、dao 分开。下单接口先校验库存再落库再发消息最后返回成功。等业务大了再拆微服务不然代码会像我桌上的外卖一样越堆越乱。面试官思路还算清楚。那你说说为什么下单要先落库再发 Kafka 消息燕双非因为订单是事实来源得先保证数据库里有记录。消息可以用来通知库存、积分、营销系统。要不然消息先发出去订单没成功兄弟系统都在那儿白忙活。面试官那如果数据库成功了Kafka 发送失败怎么办燕双非嗯……这个就要做补偿吧。可以用本地消息表或者事务消息。反正不能靠“我重试一下”这种玄学毕竟程序员的眼泪不值钱。面试官还行知道可靠投递的方向。那你平时怎么做接口文档和联调燕双非Swagger/OpenAPI 配合 Spring Boot前后端都能看到接口定义。联调时我会把请求响应字段固定好避免“你以为我以为”式灾难。第二轮搜索、缓存与可观测性面试官用户下单后商品详情页要展示“猜你还喜欢”并且支持订单搜索。你会怎么设计燕双非推荐列表我会先把用户行为打到 Kafka再异步做画像和召回订单搜索可以用 Elasticsearch 建索引。这样查订单号、商品名、手机号就不至于全表扫描把数据库扫成风扇。面试官那 Elasticsearch 的数据一致性怎么保证燕双非一般是以数据库为准ES 做查询副本。写库后通过消息异步更新索引延迟很短时用户感知不到。如果要求强一致那就得业务上重新评估不能指望 ES 像计算器一样实时绝对一致。面试官高并发抢购时Redis 你会怎么用燕双非会用 Redis 做库存预扣、热点商品缓存、用户限流。比如商品详情先查缓存缓存没有再回源。热点 key 可以加本地 Caffeine 二级缓存减少 Redis 压力。面试官缓存击穿和雪崩怎么处理燕双非击穿可以加互斥锁或者逻辑过期雪崩可以给 key 加随机过期时间还可以做多级缓存和限流。我虽然经常被老板击穿但系统不能被击穿。面试官最后问一个你怎么监控这套链路燕双非用 Micrometer 采集指标Prometheus 拉取Grafana 看面板链路追踪可以接 Zipkin 或 Jaeger。订单接口的 QPS、P99、Kafka 堆积、Redis 命中率都要盯住不然出问题只能靠猜。第三轮容灾、性能与工程化面试官如果促销活动来了订单接口突然慢了你怎么排查燕双非先看监控是数据库慢、Redis 慢还是下游接口慢。再看线程池、GC、日志和链路追踪。Java 这边如果对象创建太多GC 一抖业务就像被老板突然一样原地发懵。面试官那你说说 JVM 层面会关注哪些点燕双非堆内存、GC 类型、老年代增长、对象分配速率、线程栈、类加载还有有没有大对象频繁进入老年代。线上常见就是 Minor GC 太频繁或者 Full GC 偶发长停顿。面试官如果订单服务要做对外开放平台你会怎么做接口治理燕双非会做签名、鉴权、限流、幂等和版本控制。REST API 可以配合 OpenAPI 管理文档JWT/OAuth2 负责身份认证。如果有外部合作方还要考虑重放攻击和参数校验。面试官最后一个问题Spring Cloud 里服务调用失败怎么处理燕双非可以用 Resilience4j 做熔断、限流、重试、舱壁隔离。调用失败时先快速失败别把线程全卡死。要不服务一慢整个链路都像春节抢票一样全军覆没。面试官嗯今天先到这儿。你回家等通知吧。面试题详细解析1. 订单系统为什么先落库再发 Kafka 消息在电商订单场景中订单数据库通常是业务事实的唯一可信来源。先落库再发消息可以保证“订单已创建”这一事实先被持久化再通知库存、营销、积分等下游系统异步处理。这样即使消息发送失败也可以通过本地消息表、事务消息或补偿任务进行修复。2. Kafka 发送失败如何保证最终一致性常见方案包括本地消息表订单和消息记录同库事务提交再由后台任务重试发送。事务消息依赖消息中间件能力在半消息确认后执行本地事务再提交消息。Outbox 模式将事件和业务数据一起写入数据库由CDC或轮询同步出去。核心目标是避免“数据库成功、消息丢失”导致的系统不一致。3. 为什么接口文档要用 Swagger/OpenAPI在前后端分离和多团队协作场景中Swagger/OpenAPI 可以统一描述接口路径、参数、响应结构和错误码降低联调成本。对于互联网大厂来说接口文档是协作契约也是测试和自动化生成客户端的重要基础。4. Elasticsearch 适合做什么为什么不是强一致数据库ES 更适合全文检索、聚合分析和复杂查询不适合作为强事务主库。它的索引更新和查询分离带来高性能检索能力但数据写入后可查询存在短暂延迟因此通常通过异步同步保持最终一致。5. Redis 在高并发电商中有哪些典型用法Redis 常用于热点商品详情缓存库存预扣和限流会话信息与登录态分布式锁排行榜与计数器配合本地缓存 Caffeine 可以减少 Redis 压力提升热点读性能。6. 缓存击穿、雪崩、穿透如何处理击穿是热点 key 失效导致大量请求打到数据库通常用互斥锁、逻辑过期解决雪崩是大量 key 同时过期通常通过过期时间加随机因子、多级缓存、限流来缓解穿透是请求不存在的数据可用布隆过滤器、空值缓存或参数校验拦截。7. Micrometer、Prometheus、Grafana、Zipkin/Jaeger 的作用是什么Micrometer 负责统一采集应用指标如 QPS、延迟、错误率Prometheus 负责抓取和存储指标Grafana 负责可视化展示Zipkin/Jaeger 负责分布式链路追踪帮助定位请求在各服务间的耗时和异常点。8. JVM 排查性能问题时重点看什么需要关注堆内存使用、GC 频率与停顿时间、对象晋升情况、线程阻塞、类加载和直接内存等。促销场景下如果对象分配速度过快可能导致频繁 GC如果老年代持续增长则可能存在内存泄漏或缓存未清理问题。9. 开放平台接口为什么要做签名、鉴权、幂等和限流开放平台面向外部合作方时必须防止伪造请求、重复提交和流量滥用。签名保证请求未被篡改鉴权确认调用方身份幂等避免重复下单限流则防止恶意或异常流量压垮系统。10. Spring Cloud 调用失败如何治理可以通过 Resilience4j 实现熔断、限流、重试和舱壁隔离。这样在下游异常时系统能快速失败并保护核心线程资源避免级联故障扩大。以上面试题从电商订单、搜索、缓存、监控、JVM、开放平台到微服务治理覆盖了 Java 求职者在互联网大厂中常被追问的关键点。希望这篇内容能帮助大家更好地梳理知识体系在面试中答得更稳、更清晰。感谢阅读希望能真正帮助到你
)
