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/ZipkinPrometheus 负责采集指标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 多多。