Spring Boot Kafka Redis OpenFeign互联网大厂 Java 面试实战问答场景电商大促与会员增长系统面试官一脸严肃燕双非一脸轻松坐在对面准备“稳定发挥”。第一轮订单链路与接口设计面试官如果你负责一个电商下单系统用户点击“立即购买”后整个 Java 后端链路你会怎么设计燕双非先校验库存再创建订单然后发消息通知积分、优惠券、物流这些系统最后返回结果。一般我会尽量把同步流程做短异步流程放消息队列里。面试官不错知道主链路要短。那如果高峰期瞬时流量很大Spring Boot 里你会怎么做限流和降级燕双非呃……可以用网关限流或者在接口上加一些拦截器具体我一般看项目吧。面试官思路有一点但还不够落地。继续说说订单创建成功后如何保证 Kafka 消息不丢燕双非这个……我觉得先发消息再写库或者先写库再发消息反正保证一个成功就行。面试官你这是“二选一运气法”。再说说 OpenFeign 调用库存服务时怎么避免服务抖动拖垮下游燕双非嗯加超时、重试、熔断吧具体参数我回去看看。第二轮缓存、数据库与一致性面试官订单详情页访问量很高你会如何设计 Redis 缓存燕双非可以先查缓存缓存没有再查数据库然后回填 Redis。热点订单可以设置较长一点的过期时间。面试官很好。那缓存穿透、击穿、雪崩怎么处理燕双非穿透可以做空值缓存或者布隆过滤器击穿可以加互斥锁雪崩可以给过期时间加随机值。面试官回答得还行。现在说数据库侧订单表和流水表用 MyBatis 怎么设计事务边界燕双非一个方法里统一加事务先插订单再插流水失败就回滚。尽量别把远程调用放在事务里。面试官这个方向对。那如果你要解决“库存扣减成功但订单状态没更新”的问题你怎么做燕双非我会……加定时任务补偿或者用消息重试。实在不行就人工对账。面试官能想到补偿就比只会“再试一次”强一点。继续HikariCP 相比 C3P0 你更倾向哪个为什么燕双非HikariCP 吧听说性能更好连接池也更轻量。第三轮监控、容错与系统演进面试官大促期间你会怎么通过 Prometheus 和 Grafana 观测系统健康燕双非看 QPS、RT、错误率、JVM 内存、线程池队列长度还有 Kafka 消费堆积。面试官不错知道要看链路和消息堆积。那如果你们的促销活动要支持秒杀、优惠券、积分、支付回调怎么保证系统可扩展燕双非可以拆成多个微服务用 Spring Cloud 和消息驱动解耦支付回调走幂等关键接口加 Resilience4j 容错。面试官这次方向比较对。最后一个问题Spring Boot 里你怎么做接口文档和统一返回结构燕双非Swagger/OpenAPI 生成接口文档统一返回体封装 code、message、data异常用全局异常处理器。面试官行今天就先到这儿。回家等通知吧。面试题详细解析1. 电商下单系统链路设计典型的电商下单链路应尽量把同步链路缩短把非核心动作异步化。用户点击下单后后端通常先完成参数校验、库存预占、优惠计算、订单创建再通过 Kafka 或 RabbitMQ 异步通知积分、营销、物流等系统。这样可以避免单点服务压力过大也能提升整体响应速度。在 Spring Boot 中通常会结合网关限流、线程池隔离、接口超时控制来保护核心服务。对于高并发场景限流可以放在 API Gateway 或服务入口层常见思路是令牌桶、漏桶或基于网关的并发控制。2. Kafka 消息不丢的保障思路消息可靠性一般要从生产者、Broker、消费者三个维度考虑。生产者侧要开启确认机制确保消息写入成功Broker 侧要配置副本与 ISR消费者侧要控制幂等处理与手动提交偏移量。实际业务中常会使用事务消息、Outbox 模式或本地消息表来保证“写库”和“发消息”之间的一致性。例如订单创建成功后先在本地事务中写订单和消息表随后由后台任务扫描消息表并投递 Kafka。这样即使中间服务挂掉也能通过补偿任务恢复消息。3. OpenFeign、超时、重试与熔断OpenFeign 适合做声明式远程调用但必须配合超时、重试和熔断否则某个下游慢接口会放大整体故障。超时用于快速失败重试用于应对短暂抖动熔断则是在错误率过高时直接失败避免级联故障。Resilience4j 是目前较常见的容错组件可实现限流、熔断、舱壁隔离和重试。业务上例如库存服务短暂抖动时可以先快速失败并返回“系统繁忙请稍后再试”而不是让线程一直挂起。4. Redis 缓存设计与三大问题缓存的目标是减轻数据库压力、提升读取性能。典型流程是先查 Redis未命中再查数据库然后回填缓存。热点数据可设置较合理的 TTL并结合逻辑过期或主动失效。缓存穿透查询不存在的数据导致每次都打到数据库。解决方式包括空值缓存、布隆过滤器。缓存击穿热点 key 过期瞬间大量请求打到数据库。解决方式是互斥锁、逻辑过期、热点永不过期。缓存雪崩大量 key 同时过期数据库被击穿。解决方式是 TTL 加随机值、分批过期、服务降级。5. MyBatis 事务与一致性订单系统中事务边界应尽量包裹本地数据库操作避免把远程服务调用放在事务中。因为远程调用慢且不可控一旦失败会拖长数据库锁持有时间。常见做法是先完成本地事务再通过消息驱动实现最终一致性。若出现“库存扣减成功但订单状态未更新”通常说明流程中某个步骤失败。可以通过补偿任务、重试队列、对账任务来修复。对于强一致要求较低的业务最终一致性往往是更可行的方案。6. HikariCP 的优势HikariCP 是目前非常常见的高性能数据库连接池特点是轻量、启动快、性能好、配置相对简单。相较于传统的 C3P0它通常有更低的开销和更好的并发表现适合高吞吐场景。7. Prometheus 与 Grafana 观测指标大促期间常重点关注接口 QPS、RT、错误率、JVM 堆内存、GC 次数、线程池队列长度、数据库连接池使用率、Kafka 消费堆积、缓存命中率等指标。Prometheus 负责采集与存储Grafana 负责可视化展示Micrometer 则是 Java 应用里较常见的指标埋点方案。如果发现 RT 持续升高、错误率上升、Kafka 消费延迟变大就要尽快判断是流量突增、下游依赖抖动还是 JVM 或数据库资源瓶颈。8. 微服务拆分与可扩展性促销、电商、支付回调、库存、积分、物流等模块适合按业务域拆分成独立服务。Spring Cloud 可以提供注册发现、配置管理、声明式调用等能力消息队列用于解耦Resilience4j 用于容错幂等设计用于处理支付回调和重复通知。例如支付回调接口通常必须保证幂等可以通过订单号加唯一约束、状态机流转校验、请求幂等 token 等方式处理重复通知。9. Swagger/OpenAPI 与统一返回结构接口文档可以通过 Swagger/OpenAPI 自动生成方便前后端协作与测试联调。统一返回结构通常包含 code、message、data异常通过全局异常处理器统一封装这样可以让前端和调用方更容易处理结果。总结本次面试围绕电商大促场景串联了接口设计、Kafka 消息可靠性、Redis 缓存、MyBatis 事务、HikariCP、Prometheus/Grafana、Spring Cloud、OpenFeign 和 Swagger/OpenAPI 等常见考点。真正的面试不仅看你会不会背概念更看你能不能把技术放到业务链路里讲清楚。希望这篇文章能帮助你在 Java 面试中更有思路、更有底气。感谢阅读也祝大家面试顺利早日拿到满意的 offer