01-XAML与布局
2026/9/30 23:43:54
Java 17 + Spring Boot + Kafka + Redis + OpenFeign 面试实战：互联网大厂求职者与燕双非的 3 轮攻防
场景：互联网大厂 Java 求职面试
第一轮：基础与项目切入
面试官：先自我介绍一下，说说你最近做的电商秒杀项目技术栈，为什么选 Java 17 和 Spring Boot？
燕双非：我项目主要是用 Java 17，感觉新特性挺香，Spring Boot 启动快，整合方便，适合快速开发。
面试官：不错，能说到“启动快”和“整合方便”，说明你不是只会背概念。那你说说 Java 17 相比 Java 8，哪些特性在后端服务里最实用？
燕双非：嗯……比如 switch 更强了，record 也能少写很多样板代码，还有文本块，写 JSON 比较方便。
面试官：回答得可以，至少知道怎么落地。那你在服务里是怎么管理配置和多环境切换的？
燕双非：我一般用 Spring Boot 的 profile，开发、测试、生产分开配，数据库地址、MQ 地址都拆开。
面试官：这个思路对，继续。那你秒杀接口怎么防止重复下单和库存超卖？
燕双非：嗯……先限流，再加锁，Redis 里做个标记，数据库再做最后兜底。
面试官：方向是对的，后面我们再细聊。
第二轮：中间件与分布式设计
面试官：你刚提到 Redis。那在秒杀链路里，Redis 主要承担什么职责？为什么不用直接打数据库？
燕双非：Redis 主要快嘛，做库存缓存、用户购买标记、热点数据。直接打数据库压力太大，容易扛不住。
面试官：很好。那如果库存扣减和下单写库不是一个原子操作，怎么避免数据不一致？
燕双非：这个……可以用 Lua 脚本或者消息队列异步削峰，后面再做补偿。
面试官：不错，已经有分布式思维了。那你们为什么选 Kafka，不选 RabbitMQ？
燕双非：因为 Kafka 吞吐高，适合秒杀这种高并发场景；RabbitMQ 更偏灵活路由，但我们更看重削峰。
面试官：回答得不错。那 Kafka 消息重复消费你怎么处理？
燕双非：嗯……消费者侧做幂等，业务表加唯一键，或者记录消息处理状态。
面试官：可以。再说说 OpenFeign 在你项目里做什么？
燕双非：用来调用商品服务、库存服务、订单服务，接口定义比较清晰，配合负载均衡和超时控制挺方便。
面试官：很好，那如果下游服务响应慢，你怎么做容错？
燕双非：可以配合 Resilience4j 做超时、熔断、限流，避免雪崩。
第三轮：监控、安全与 AI 化扩展
面试官：最后聊聊安全。秒杀活动很容易被刷，你怎么做风控？
燕双非：可以加登录态校验、JWT 鉴权、IP 限流、图形验证码，还有行为分析。
面试官：不错，安全意识还可以。那你怎么监控整个链路的性能？
燕双非：我们会接 Micrometer 接 Prometheus，Grafana 看 QPS、延迟、错误率，再配合日志排查问题。
面试官：挺好。那如果老板说要加一个 AI 导购助手，帮用户推荐商品，你怎么设计？
燕双非：可以用 Spring AI 接大模型，做 RAG，把商品知识、活动规则、FAQ 做向量化检索，再结合对话记忆和工具调用。
面试官：这个回答已经接近实战了。你说说 RAG 为什么能减少 AI 幻觉？
燕双非：因为它不是纯靠模型瞎猜，而是先检索企业文档或者商品知识，再让模型基于检索结果回答，所以更稳。
面试官：不错，今天先到这里。你回去等通知吧。
问题详解
1. 为什么 Java 17 + Spring Boot 适合互联网大厂项目？
Java 17 提供了更现代的语法与运行时能力，例如 record、switch 表达式、文本块等，能够减少样板代码，提高可读性。Spring Boot 则通过自动配置、starter 依赖、嵌入式容器等能力，降低服务开发和部署成本，非常适合高迭代的互联网业务。
2. 秒杀场景如何防止超卖与重复下单？
通常采用“前置拦截 + 缓存原子扣减 + 消息异步下单 + 数据库兜底”的组合方案。前置层可以做限流、验证码、登录校验；Redis 可通过 Lua 保证库存扣减原子性；Kafka 用于削峰；数据库层再通过唯一索引、乐观锁或状态机保证最终一致性。
3. Redis 在高并发场景中的作用是什么？
Redis 适合承担热点库存、用户购买标记、验证码、活动配置等高频读写数据。它可以大幅降低数据库压力，但必须注意缓存穿透、击穿、雪崩问题，通常需要结合布隆过滤器、互斥锁、随机过期时间等手段治理。
4. Kafka 为什么适合秒杀削峰？
Kafka 具有高吞吐、分区并行、顺序性可控、消费组扩展方便等特性，适合承接突发流量。秒杀中的下单请求先进入 Kafka，由后端异步消费，能把瞬时高峰平滑成可处理的业务流量。
5. 消息重复消费如何保证幂等？
幂等设计常见手段包括：业务唯一键约束、去重表、消息状态表、分布式锁、基于业务状态机判断、消费端事务控制等。关键是让同一条消息被重复处理时，结果保持一致，不会造成重复扣减或重复发货。
6. OpenFeign 与 Resilience4j 的组合价值是什么？
OpenFeign 提供声明式 HTTP 调用能力，适合服务间通信；Resilience4j 则提供超时、熔断、限流、隔离等容错能力。两者结合可以在调用下游服务时做到“调用方式简单，故障控制完善”。