Java 面试实战：Spring Boot + Kafka + Redis + Spring Security 在电商秒杀与风控场景中的 3 轮深挖

Java 面试实战Spring Boot Kafka Redis Spring Security 在电商秒杀与风控场景中的 3 轮深挖故事背景今天的面试场景是某互联网大厂电商业务线需要招聘一位 Java 后端工程师负责秒杀、订单、风控、消息通知等核心链路。面试官语气严肃候选人是“水货程序员”燕双非表面自信实则经常把简单问题答得像背书复杂问题就开始含糊其辞。第一轮秒杀链路的基础能力面试官先说说你怎么设计一个电商秒杀接口避免超卖和接口被打爆燕双非这个简单先用 Redis 做库存预扣再加个 Spring Boot 接口限流前面挂个 Nginx后面异步下单应该就差不多了。面试官嗯方向对。那你说说 Redis 预扣和数据库扣减如何保持一致燕双非我一般会先扣 Redis再发 Kafka 消息到订单系统数据库那边异步落库。如果失败就重试重试不行就补偿……大概是这么个思路。面试官那你知道幂等怎么做吗燕双非可以用订单号做唯一键数据库加唯一索引消息消费端也带业务幂等表防止重复消费。面试官这个答得还可以。那如果高峰期请求量特别大你会怎么做削峰燕双非我会把请求先丢到 Kafka 里排队前面再加本地缓存和令牌桶限流尽量让系统平滑一点。第二轮风控、权限与数据链路面试官秒杀接口会被刷单、薅羊毛你怎么做用户风控燕双非Spring Security 做登录认证JWT 传用户身份再结合 Redis 记录用户行为频率比如同一个 IP、同一个账号短时间请求太多就拦掉。面试官如果你要给不同风险等级的用户做分级策略呢燕双非可以在网关层或者业务层做规则引擎高风险用户直接验证码或者人机校验中风险用户限制频率低风险用户正常走。面试官订单和支付系统之间如何保证状态流转清晰燕双非订单先创建待支付状态支付成功后发事件通知订单服务更新状态。可以用 Kafka 统一事件流状态机控制订单状态避免乱跳。面试官如果消息重复、乱序、延迟怎么办燕双非这个……要么加版本号要么按时间戳判断消费端再做幂等和状态校验不能直接覆盖。面试官你提到了事件流那你怎么监控这条链路是否健康燕双非用 Micrometer 打点Prometheus 采集Grafana 看仪表盘关键链路再配合日志和链路追踪比如 Zipkin 或 Jaeger。第三轮云原生、AI 与扩展能力面试官现在业务要求客服系统接入 AI自动回答订单、退款、物流问题你会怎么设计燕双非可以做一个 Spring AI 的服务把用户问题先做语义检索结合 RAG 去企业文档里找答案再把结果交给大模型生成回复。面试官那如何避免 AI 幻觉燕双非呃……主要还是要控制提示词做检索增强尽量让模型“有据可依”。对高风险问题比如退款金额、隐私信息直接走规则和人工兜底。面试官如果要把 AI 服务部署到 Kubernetes 上并支持扩容你怎么做燕双非容器化后部署到 K8s设置 HPA根据 CPU 或 QPS 自动扩缩容。模型调用和检索服务分开避免互相影响。面试官那如果客服对接外部系统比如物流、工单、支付你怎么做工具调用燕双非可以把这些能力标准化成工具接口再让 Agent 去选择调用。比如查物流、查订单、发起工单都作为工具减少模型自由发挥。面试官行今天先到这里。你回去等通知吧。问题详解1. 秒杀接口如何避免超卖和打爆系统电商秒杀的核心是“高并发下的库存保护与系统保护”。通常做法是前置限流在网关或 Nginx 层进行限流防止流量直接冲垮后端。Redis 预扣库存请求进入后先在 Redis 中原子扣减库存成功才允许进入后续流程。异步下单通过 Kafka 这类消息队列把下单请求异步化削峰填谷。数据库最终落库订单服务异步消费消息最终写入数据库。幂等控制通过业务唯一键、唯一索引、消费去重表避免重复下单。在真实业务中Redis 负责“快”和“高并发”数据库负责“最终一致性”中间用消息队列连接两者。2. Redis 预扣与数据库一致性如何处理常见思路是“先快后慢、最终一致”。Redis 中先扣库存扣成功后发送消息到 Kafka。消费者收到消息后写数据库。如果数据库写失败可以重试如果多次失败再进入补偿队列或人工介入。注意不要强行做分布式事务把所有系统绑死。秒杀场景追求吞吐和可用性通常采用最终一致性方案更合理。3. 幂等为什么重要怎么做在秒杀和支付场景中请求可能因超时、重试、消息重复投递而多次到达。幂等是保证“执行一次和执行多次效果一样”。常见实现方式数据库唯一索引例如订单号唯一。幂等表记录已处理请求或消息 ID。状态机校验只允许合法状态转换。缓存去重短时间内对相同请求做拦截。4. 如何做用户风控风控通常结合认证、行为分析和策略引擎Spring Security 负责身份认证和授权。JWT 用于无状态身份传递适合前后端分离。Redis 记录频率、IP、设备指纹、黑名单等信息。规则引擎或策略中心按风险等级分流。例如高风险用户需要验证码、人机校验低风险用户可直接放行。风控不是单点功能而是贯穿登录、下单、支付全链路。5. 订单状态流转如何设计建议用状态机管理订单生命周期待支付、已支付、已取消、退款中、已退款等。状态机可以避免“任意状态跳转”保证系统逻辑清晰。支付成功后通过 Kafka 或其他事件总线通知订单服务更新状态订单服务消费事件时必须校验当前状态防止乱序和重复消息导致错误覆盖。6. 如何监控整条链路典型方案是Micrometer 统一打点指标。Prometheus 采集指标。Grafana 展示仪表盘。日志系统使用 Logback/Log4j2 ELK。链路追踪使用 Zipkin 或 Jaeger。对于秒杀链路重点关注接口耗时、消息堆积、库存扣减成功率、下单成功率、消费延迟。7. Spring AI RAG 如何做企业客服企业客服接入 AI 时不能只靠大模型“凭感觉回答”而是要结合检索增强生成RAG先把企业知识库、FAQ、工单、物流说明等文档进行加载和切分。对文本做向量化存入 Milvus、Chroma 或 Redis 向量能力。用户提问后做语义检索召回相关片段。将检索结果与问题一起拼接成提示词交给大模型生成答案。对退款、金额、隐私等高风险问题增加规则兜底和人工转接。这样可以显著降低 AI 幻觉提高回答可信度。8. 如何避免 AI 幻觉主要做法包括优先检索事实再生成答案。控制提示词要求模型“仅根据提供内容回答”。对高风险领域增加规则校验。引入引用来源便于审计。对输出结果做后处理和安全过滤。在企业场景里AI 要做“辅助决策”不能让模型单独承担最终责任。9. 为什么要容器化并部署到 KubernetesKubernetes 提供弹性扩缩容、服务发现、滚动发布、故障自愈等能力。对于客服 AI 服务、订单服务、风控服务这类流量波动较大的系统K8s 能更好地应对高峰和异常。部署时建议将模型调用、检索、业务 API 分层拆分避免某个依赖抖动拖垮整个链路。10. Agent 和工具调用在业务里怎么落地Agent 的核心是“让模型知道自己能调用哪些工具并在需要时选择调用”。例如查订单查物流发起退款申请创建工单工具调用标准化后模型不需要自己“编造”结果而是通过调用真实系统获取数据再组织语言返回给用户。这就是企业智能客服、智能助理的典型落地方式。总结这类 Java 面试并不只是问“会不会某个框架”而是看你能否把 Spring Boot、Kafka、Redis、Spring Security、Micrometer、K8s、Spring AI 等技术串成一条完整业务链路并能解释为什么这么设计。如果你能在面试中把“秒杀、风控、订单、监控、AI 客服”讲成一个连续故事面试官通常会认为你具备较强的工程化思维。感谢阅读希望这篇文章能帮助到正在准备 Java 面试的你祝你面试顺利早日拿到心仪的 offer