Java 求职面试实录：Spring Boot + Kafka + Redis + Spring Security 的电商与风控场景深挖
场景：某互联网大厂 Java 终面，业务方向为电商交易与安全风控。
角色：严肃面试官、搞笑水货程序员燕双非。
第一轮：先聊业务主链路，看看基础稳不稳
面试官：你先讲讲，如果你负责一个电商下单系统，Spring Boot 在这里主要承担什么角色？
燕双非：Spring Boot 负责快速搭框架，自动配置，省得我一个个手搓 XML。下单接口、参数校验、事务管理、依赖注入这些都能比较顺地做起来。比如订单服务启动后，可以直接暴露 REST 接口给前端或者网关调用。
面试官：说得还行。那如果订单量一上来，怎么避免接口被打爆？
燕双非：嗯……可以先限流，再加缓存，热点商品信息放 Redis，减少数据库压力。订单创建这类核心链路还要考虑异步化，不然用户点一下我这边服务器就像被双十一按在地上摩擦。
面试官：限流、缓存、异步都提到了，方向对。那 Redis 在这个场景里你会怎么设计 key？
燕双非：比如商品详情可以按product:detail:{id}这种形式，用户购物车可以按cart:user:{userId}。如果是秒杀库存，可能会用seckill:stock:{skuId}，配合原子操作防止超卖。
面试官：很好，至少 key 命名有业务意识。
第二轮：深入到链路、消息与风控
面试官：下单成功后，库存扣减、发券、发短信、埋点这些动作你怎么解耦？
燕双非：可以用 Kafka。主链路只负责发一个订单创建事件，库存、营销、通知、风控这些消费者各自订阅。这样主流程更快，系统也更容易扩展。
面试官：如果 Kafka 消息重复消费怎么办？
燕双非：呃……要做幂等。比如消费端先查业务唯一键，已经处理过就直接跳过。也可以借助数据库唯一约束，或者 Redis 去重标记。总之不能让用户买一次东西，系统给他扣三次库存。
面试官：那风控系统要实时判断是不是异常订单，你会怎么做？
燕双非：可以在订单创建时同步调用风控规则，也可以用 Kafka 把订单事件发出去，由风控服务做实时画像和规则计算。高风险订单可以打标、拦截或者进入人工审核队列。
面试官：如果风控规则经常变，怎么保证系统可维护？
燕双非：规则配置化，核心判断逻辑和规则数据分离。比如把阈值、黑名单、地区限制这些放到配置中心或者数据库里，风控引擎按规则执行，别把业务判断写死在代码里，不然以后改一条规则像拆地雷。
面试官：那你如何保证接口安全？
燕双非：可以用 Spring Security + JWT。登录后签发 token，后续请求带 token，服务端校验签名和过期时间。权限控制可以按角色和接口粒度拦截。对外接口还要防重放、防刷接口。
面试官：不错，已经开始像个能干活的人了。
第三轮：压一压底层、可观测性和稳定性
面试官：你刚才提到异步和高并发，那 JVM 层面你会关注什么？
燕双非：关注堆内存、GC、线程池、对象创建频率。比如订单服务如果有大量短命对象，可能会带来频繁 Young GC。还要看线程池队列长度，避免任务堆积。线上出现卡顿时，我会先看 GC 日志和线程栈。
面试官：如果你发现接口 RT 突然飙升，你怎么定位？
燕双非：先看监控和日志。Prometheus + Grafana 看 CPU、内存、QPS、错误率，Micrometer 打业务指标，日志里找慢 SQL、外部接口超时，再结合链路追踪看是不是卡在某个依赖上。
面试官：链路追踪你会选什么？
燕双非：Jaeger 或 Zipkin 都可以。订单创建经过网关、订单服务、库存服务、风控服务，每个 span 都打上 traceId，查问题时就不会像摸黑找猫一样。
面试官：最后一个问题，MyBatis 和事务你怎么配合？
燕双非：核心下单逻辑放在一个事务里，订单表和库存表更新要保证一致性。MyBatis 适合写可控 SQL，性能和可读性都不错。遇到跨服务一致性，就不能只靠本地事务了，得考虑最终一致性、消息事务或者补偿机制。
面试官：嗯，回答比前面扎实一些。今天就到这儿，你先回家等通知吧。
问题详解与知识点总结
1. Spring Boot 在电商下单系统中的作用
Spring Boot 的核心价值在于快速构建生产可用的服务。对于电商下单系统，它通常承担以下职责：接口暴露、依赖注入、参数校验、事务管理、自动配置、中间件集成等。业务上最重要的是让订单、支付、库存等模块以统一方式启动和运行。
在实际业务中，Spring Boot 常与 Spring MVC 或 WebFlux 配合，用于处理同步或异步 HTTP 请求。对于核心交易链路，一般优先保证稳定性、可读性和可维护性。
2. Redis 在商品详情、购物车和秒杀中的应用
Redis 适合做高频读缓存、会话存储、计数器、分布式锁和限流。商品详情、用户购物车等场景可以采用清晰的 Key 设计，便于管理和排查问题。秒杀场景中，Redis 还能承担库存预扣减，利用原子操作减少超卖风险。
不过缓存不是数据库的替代品。要处理缓存击穿、缓存穿透和缓存雪崩问题，常见手段包括热点预热、空值缓存、互斥重建、随机过期时间等。
3. Kafka 在订单事件驱动架构中的作用
Kafka 非常适合做订单事件总线。订单创建成功后，订单服务只负责发送事件，库存、营销、通知、风控等服务异步消费。这样可以降低主链路耗时，同时实现服务解耦。
业务上要重点关注：消息顺序性、重复消费、消息丢失、堆积处理、重试与死信。消费者必须实现幂等，常见方式有业务唯一键去重、数据库唯一索引、状态机校验和 Redis 标记等。
4. 风控系统如何设计
风控系统通常由规则引擎、实时计算、特征画像和策略配置组成。在订单、登录、支付等关键动作上进行识别和干预。规则需要配置化，避免硬编码，便于运营和安全团队快速调整。
常见策略包括设备指纹、IP 黑名单、地理位置异常、频率阈值、行为模式识别等。对于高风险订单，可以采取拦截、二次验证、人工审核或降级处理。
5. Spring Security + JWT 的接口安全方案
JWT 适合无状态认证，服务端只需校验签名与有效期。Spring Security 负责认证、鉴权和接口访问控制。对于电商系统，还要配合验证码、限流、防重放和敏感操作二次校验，减少刷单和撞库风险。
实践中要注意 Token 刷新机制、注销策略、黑名单处理以及密钥安全。若权限模型复杂，可结合 RBAC 或 ABAC 设计。
6. JVM、GC 与线程池在高并发场景中的关注点
高并发下 JVM 问题经常表现为 GC 抖动、内存泄漏、线程竞争、对象过多创建、连接池耗尽等。订单服务如果频繁创建短命对象，可能触发频繁 Young GC，影响 RT。
排障顺序通常是：监控告警 → GC 日志 → 线程栈 → 火焰图/Profiler → 慢 SQL/下游接口 → 业务代码热点。线程池也必须合理配置，避免任务堆积导致系统雪崩。
7. 可观测性：Prometheus、Grafana、Micrometer、Jaeger/Zipkin
Prometheus 负责采集指标，Grafana 负责展示，Micrometer 负责统一埋点，Jaeger/Zipkin 负责分布式链路追踪。一个成熟的电商系统必须具备可观测性，否则出问题时无法快速定位。
建议关注的指标包括 QPS、错误率、延迟分位数、线程池队列长度、Kafka 消费积压、缓存命中率、数据库连接池状态和下游依赖耗时。
8. MyBatis 与事务一致性
MyBatis 适合对 SQL 有精细控制的场景，尤其是订单、库存、账务等核心交易表。事务用于保证单体服务内的数据一致性，但在分布式系统里，跨服务一致性通常需要借助消息、补偿、Outbox、Saga 或最终一致性方案。
面试时若提到“下单扣库存”，建议同时说明本地事务和分布式一致性边界，体现工程思维。
9. 业务串联思路
一个典型电商交易链路可以这样串起来：用户请求进入 Spring Boot 接口，鉴权由 Spring Security + JWT 处理，热点数据走 Redis 缓存，订单创建写入 MyBatis 管理的数据库事务，随后通过 Kafka 发送事件，库存、营销、风控等服务异步消费，并通过 Prometheus/Grafana/Micrometer/Jaeger 完成可观测与追踪。
这类回答在面试中最重要的是：先讲主链路，再讲异常与扩展，最后讲稳定性与治理。
10. 结语
以上就是本次 Java 面试实录与知识解析，希望能帮助大家在电商、风控、分布式系统、高并发和可观测性等方向建立更完整的知识框架。感谢阅读，希望这篇文章能真正帮助到大家，也祝大家面试顺利、Offer 多多。
