Java 求职面试实录：Spring Boot + Kafka + Redis + Spring Security 在电商大厂场景下的三轮攻防

场景：互联网大厂电商业务线 Java 面试

第一轮：基础能力与项目切入

面试官：你先简单介绍一下你在电商项目里负责的核心模块，技术栈是怎么选的？

燕双非：我主要负责订单、库存和优惠券模块，后端用 Spring Boot 做统一接口层，数据库访问用 MyBatis，缓存用 Redis。因为下单链路对性能要求高，所以热点数据尽量走缓存，减少数据库压力。

面试官：嗯，这个思路是对的。那你说说订单查询为什么要做缓存？缓存和数据库怎么保证一致性？

燕双非：订单详情这种读多写少的场景，缓存能明显降低响应时间。至于一致性嘛……一般就是先更新数据库，再删缓存，或者先删缓存再更新数据库，具体看业务，反正要避免脏数据太久。

面试官：思路有了，后面可以再细化一下并发下的双删时机。那你们支付成功后，库存扣减是同步做还是异步做？

燕双非：我们会把支付结果发到 Kafka，由库存服务异步消费。这样支付链路更快，也能削峰填谷，避免高峰期把库存系统打爆。

面试官：可以，说明你对消息解耦有理解。那 Kafka 消息重复消费你怎么处理？

燕双非：这个我一般会给消息加唯一业务 ID，消费者处理前先查一下有没有处理过，如果处理过就直接跳过。嗯……还可以配合数据库唯一索引或者幂等表。

第二轮：链路治理与稳定性

面试官：订单链路引入 Kafka 后，如何保证消息可靠投递？

燕双非：生产者端会设置合理的重试策略，broker 端尽量保证分区副本，消费者端处理成功后再提交 offset。关键业务还会做本地消息表或者事务消息兜底。

面试官：说到事务消息，你们如果没有现成的事务消息能力，怎么做订单创建和库存扣减的一致性？

燕双非：可以用最终一致性方案。先落订单状态为待确认，然后通过 Outbox 事件表或者本地消息表发 Kafka，库存服务消费后回写结果。中间失败就靠重试和补偿任务修复。

面试官：不错。那高并发抢购场景下，Redis 预扣库存和数据库真实库存如何配合？

燕双非：秒杀时先在 Redis 做原子扣减，拦住超卖，再异步落库。数据库层面再加乐观锁兜底，防止 Redis 和 DB 数据漂移太多。

面试官：很好。那如果 Redis 短暂不可用，你怎么设计降级策略？

燕双非：那就……先限流，必要时直接返回系统繁忙。核心是保护数据库，不然流量全穿透下去，可能整个链路都挂了。

面试官：这个保护意识是有的。最后问你一个稳定性问题，Spring Security 在电商后台管理里你会怎么用？

燕双非：后台会接入 Spring Security + JWT 做登录认证，按角色控制订单、商品、营销配置等权限。敏感接口再结合审计日志，防止越权操作。

第三轮：架构深化与可观测性

面试官：如果这个电商系统要做成微服务架构，你会怎么拆分服务？

燕双非：一般会拆成用户、商品、购物车、订单、支付、库存、营销、搜索这些服务。服务之间通过 OpenFeign 或者消息队列通信，查询走接口，状态变更走事件。

面试官：那服务治理怎么做？

燕双非：可以用 Spring Cloud 配合注册中心做服务发现，再加 Resilience4j 做熔断、限流和重试。核心链路要设置超时，避免一个慢接口拖垮整个调用链。

面试官：监控方面你们怎么排查慢请求和消息积压？

燕双非：用 Micrometer 暴露指标到 Prometheus，Grafana 看 QPS、RT、错误率和 Kafka Lag。日志统一接到 ELK，链路追踪可以用 Zipkin 或 Jaeger 定位问题。

面试官：不错，最后一个问题：如果活动流量突然暴涨，你怎么做容量保护？

燕双非：先做限流和熔断，再把非核心流程异步化，比如发券、通知、积分。前端页面和接口也可以做缓存，关键链路尽量减少同步依赖。

面试官：整体思路还行，今天先到这，你回家等通知吧。

面试题详细解析

1. 为什么电商订单查询适合用 Redis 缓存？

电商系统中订单详情、商品详情、活动配置等数据通常是读多写少，并且读请求集中在热点数据上。使用 Redis 可以降低数据库压力，提升响应速度。但要注意缓存穿透、缓存击穿和缓存雪崩问题。

常见做法包括：

• 空值缓存防穿透
• 热点 Key 预热和互斥锁防击穿
• TTL 随机化防雪崩
• 更新时采用先更新数据库、再删除缓存的策略，必要时引入双删或消息驱动最终一致性

2. Kafka 在支付、库存、订单链路中的作用是什么？

Kafka 的核心价值是异步解耦、削峰填谷、提高吞吐。支付成功后通知库存服务扣减库存，订单服务更新状态，营销服务发放权益，这些都适合通过事件驱动来完成。

落地时要关注：

• 消息幂等：避免重复消费造成重复扣减
• 消息顺序：同一订单的关键事件尽量进入同分区
• 可靠性：生产者重试、ACK 策略、消费者提交 offset 时机
• 补偿机制：失败重试、死信队列、人工修复

3. 如何处理 Redis 预扣库存与数据库真实库存的一致性？

高并发场景下，通常先在 Redis 侧做原子预扣减，快速拦截超卖请求，再异步落库更新真实库存。数据库层面可使用乐观锁或条件更新来做最终兜底。

这种设计的核心是允许短暂不一致，但保证最终一致。如果 Redis 与数据库出现漂移，需要通过定时任务、对账任务或补偿消息进行修复。

4. Spring Security + JWT 在后台管理系统中怎么设计？

后台管理系统一般采用 JWT 作为身份凭证，登录后签发 Token，后续请求携带 Token 访问接口。Spring Security 负责认证和授权，按角色或权限点控制菜单、订单、商品、活动等功能。

实践中常见做法：

• Token 设置合理过期时间
• 敏感操作增加二次校验
• 接口鉴权与审计日志结合
• 支持黑名单或刷新令牌机制

5. 微服务架构下为什么要做熔断、限流和超时控制？

电商系统在大促时调用链长、依赖多，任何一个下游服务变慢都可能把上游拖垮。通过 Resilience4j 等组件实现熔断、重试、限流和隔离，可以避免级联故障。

原则上：

• 超时要短，避免线程堆积
• 重试要谨慎，防止放大流量
• 熔断要快速失败，保护系统
• 非核心链路要异步化或降级

6. 如何构建可观测性体系？

可观测性通常包含指标、日志、链路追踪三部分。Micrometer 可以统一暴露业务指标，Prometheus 负责采集，Grafana 做展示；ELK 用于日志检索；Zipkin 或 Jaeger 做分布式链路追踪。

在电商系统中，重点关注：

• 接口 RT、错误率、QPS
• Kafka 消息堆积和消费延迟
• 数据库连接池耗尽情况
• 订单创建到支付完成的链路耗时

结语

感谢阅读，希望这篇文章能帮助大家更好地准备 Java 面试，理解电商大厂场景下的核心技术点与面试思路。祝大家都能在面试中稳定发挥，顺利拿到心仪的 offer。