企业官网建设流程全解析

Java 面试实战：电商风控场景下的 Spring Boot、Kafka、Redis 与 AI/RAG 进阶问答

今天的面试场景是：互联网大厂 Java 岗，业务方向是电商风控与营销反作弊。面试官表情严肃，候选人是外号“燕双非”的水货程序员，主打一个“会一点，但不多”。

下面进入正式面试。

第一轮：基础架构与高并发入口

面试官：先说说，如果让你设计一个电商秒杀活动的下单接口，你会怎么用Spring Boot搭建服务？

燕双非：嗯……Spring Boot 启动快，配置少。我会先把订单服务、库存服务拆开，然后写个 Controller 接收请求，再加个 Service 做业务校验，最后落库。哦对，还能用配置文件区分不同环境。

面试官：思路基本对。那高并发下你怎么避免接口被打爆？

燕双非：可以先做限流，比如网关层限流、接口幂等、缓存预热……还有把热点商品信息放到 Redis 里。

面试官：不错，至少你知道别让数据库先死。继续。你提到 Redis，那如果用户重复提交订单，怎么做幂等？

燕双非：我觉得可以给每次请求生成一个 token，提交后就删掉。下次再来就没有 token 了。

面试官：这个方案可以。那如果 token 过期、并发提交、重复消费同时出现呢？

燕双非：……那就要再加一层校验吧，可能还得结合数据库唯一索引或者 Redis 原子操作。

面试官：行，至少你没有把锅甩给运气。

第二轮：消息削峰、风控与一致性

面试官：现在活动来了，流量暴涨。下单请求先进入Kafka，你会怎么设计消费链路？

燕双非：可以先把下单请求写到 Kafka，消费者慢慢处理。这样能削峰填谷，保护后端数据库。

面试官：很好。那如果消费者重复消费了一条消息，怎么办？

燕双非：Kafka 不是有 offset 吗？……应该可以手动提交 offset？然后我再保证消费逻辑幂等。

面试官：继续往下说，幂等怎么做？

燕双非：可以用订单号做唯一键，先查有没有处理过；或者在 Redis 里放一个处理标记，消费成功再更新状态。

面试官：可以。那活动中还要做风控，比如识别羊毛党。你会怎么设计一个简单的反作弊策略？

燕双非：可以结合用户行为、设备指纹、IP、下单频次……然后把风控规则放到服务里，命中黑名单就直接拦截。

面试官：如果规则很多、经常变动呢？

燕双非：那就……拆成规则中心？配置化？然后通过管理后台动态调整。

面试官：这次还行。那风控结果要给上游服务实时展示，你会用什么做缓存和统计？

燕双非：Redis 做实时计数，Micrometer 采集指标，再接 Prometheus 和 Grafana 看图表。

面试官：答得比刚才像样多了。

第三轮：安全、可观测性与 AI 增强

面试官：接下来讲安全。电商订单接口你会怎么做认证？如果用JWT，你觉得优缺点是什么？

燕双非：JWT 好处是无状态，服务端不用存 session，适合微服务。缺点是……一旦发出去，撤销比较麻烦。

面试官：很好。那你会怎么结合Spring Security落地？

燕双非：自定义过滤器解析 token，拿到用户身份后放进 SecurityContext，再做权限控制。

面试官：继续。系统上线后你怎么快速定位问题？

燕双非：日志用 SLF4J+Logback 统一打点，链路追踪可以接 Zipkin 或 Jaeger，指标用 Prometheus，异常多的接口再看 Grafana 面板。

面试官：挺完整。那如果现在要接一个 AI 客服，帮用户查询订单、解释风控拦截原因，你会怎么做？

燕双非：可以用Spring AI接大模型，再结合RAG检索订单知识库和规则文档。用户问“为什么我下单失败”，先向量检索，再把结果拼到提示词里，让模型生成回答。

面试官：那 AI 幻觉怎么控制？

燕双非：嗯……尽量让模型只基于检索结果回答，置信度不够就转人工。还可以做提示填充、工具调用标准化，以及对关键答案加白名单校验。

面试官：最后一个问题，企业里如果要做一个复杂工作流，比如“下单后自动校验风控、冻结库存、通知客服、生成报表”，你会怎么考虑 Agent 和工具执行框架？

燕双非：这个……可以把每一步封成工具，然后让 Agent 决定调用顺序。像是有点自动编排的意思，不过具体实现我得回去再想想。

面试官：行，今天先到这里。你先回家等通知吧。

面试题详细解析

1. Spring Boot 如何搭建秒杀下单服务？

在电商秒杀场景中，Spring Boot 的优势在于快速构建、自动装配和生态完整。常见做法是将系统拆分为订单服务、库存服务、营销服务等独立模块。入口层负责请求校验、鉴权和限流，业务层完成库存扣减、订单创建和消息投递，持久层负责落库。

关键点：

• 使用统一的异常处理和参数校验，减少无效请求。
• 结合 Redis 缓存商品详情、库存快照、活动配置，降低数据库压力。
• 对热点路径进行降级处理，确保核心链路可用。

2. 秒杀接口如何避免重复提交？

幂等的核心是“同一个请求多次执行结果一致”。常见方法包括：

• 一次性 token：先获取 token，提交时校验并删除。
• 业务唯一键：如订单号、用户+活动ID组合唯一索引。
• Redis 原子操作：利用 setnx、Lua 脚本实现检查与占位的原子化。

在高并发下，最好把应用层幂等与数据库唯一约束结合起来，避免单点失效。

3. Kafka 在削峰填谷中的作用是什么？

Kafka 适合做异步解耦和流量缓冲。下单请求先写入 Kafka，由消费者异步处理库存校验、订单创建、风控判断等逻辑。这样即使瞬时流量很大，也不会直接冲击数据库。

注意点：

• 消息可能重复投递，消费端必须幂等。
• 处理失败要有重试、死信队列或补偿机制。
• 业务上要明确“最终一致性”而不是强行追求分布式强一致。

4. 重复消费怎么解决？

常用思路：

• 用订单ID或业务流水号做去重标识。
• 消费前查数据库是否已处理。
• 借助 Redis 记录处理状态，配合过期时间避免永久占用。

真正可靠的做法是：消息消费幂等 + 业务状态机 + 数据库约束三位一体。

5. 电商风控如何设计基础策略？

电商风控通常会关注设备、IP、行为模式、下单频率、收货地址异常等维度。基础策略可以先用规则引擎或配置中心管理黑白名单、频控规则和评分阈值。

业务上通常分三层：

• 前置拦截：登录、下单、支付前做快速判断。
• 实时判定：命中高风险特征立即拒绝或验证。
• 离线分析：通过历史数据发现新型作弊模式。

6. Redis 在实时统计和缓存中的作用？

Redis 适合做高频读写的计数器、热点配置缓存、会话状态和分布式锁。比如实时统计某活动下单次数、某用户请求频率、某风控规则命中次数，都可以放在 Redis 中。

结合Spring Cache还能简化缓存使用，但对于高并发风控场景，往往更需要精细控制 TTL、原子性和热点保护。

7. JWT + Spring Security 如何落地？

JWT 的优势是无状态、易扩展，适合微服务环境下的统一认证。Spring Security 通常通过自定义过滤器解析 JWT，验证签名和过期时间，然后将用户身份写入上下文，供后续授权使用。

注意：

• JWT 一旦签发，撤销较麻烦，通常需要黑名单、短有效期或刷新令牌机制。
• 敏感操作仍然建议结合二次校验。
• 权限设计最好与角色、资源和数据范围结合，而不是只做简单的 URL 拦截。

8. 如何做系统可观测性？

可观测性通常包含日志、指标和链路追踪三部分：

• 日志：SLF4J 作为门面，Logback 或 Log4j2 作为实现。
• 指标：Micrometer 统一采集应用指标，接 Prometheus 与 Grafana 展示。
• 追踪：Jaeger 或 Zipkin 观察调用链路，定位慢接口和异常依赖。

在大厂面试里，能把三者串起来讲清楚，通常会很加分。

9. AI 客服如何结合 Spring AI 与 RAG？

在企业场景中，AI 客服不能只靠大模型“自由发挥”，更适合使用RAG：先从知识库、订单库、风控规则库中检索相关内容，再把检索结果喂给模型生成答案。

典型链路：

1. 用户提问。
2. 做意图识别与 query 改写。
3. 通过向量化和语义检索找到相关文档。
4. 把结果拼进提示词。
5. 模型生成答案，并附带引用依据。

这样能显著降低幻觉，提高可解释性。

10. 如何控制 AI 幻觉？

可从以下方向入手：

• 限定回答范围，只允许基于检索结果回答。
• 对关键问题设置置信度阈值，低于阈值转人工。
• 引入工具调用，让模型查询真实系统而不是凭空编造。
• 对敏感回答做规则校验和审核。

企业级 AI 的核心不是“会说”，而是“说得准、可追溯、可管控”。

11. Agent 和工具执行框架适合什么场景？

当业务流程复杂、步骤不固定、需要动态决策时，Agent 很有价值。例如：下单后自动执行风控校验、库存冻结、消息通知、报表生成等多个动作。

工具执行框架的关键是：

• 把每个能力封装成标准工具。
• 定义清晰的输入输出协议。
• 支持失败重试、超时、补偿和审计。

这类方案适合做“半自动工作流”，但要避免让模型直接控制关键资金或安全动作。

以上就是本次面试实战的全部内容。希望这篇文章能帮助大家更好地理解 Java 面试中的高频技术点与真实业务场景之间的联系。感谢阅读，希望能帮助到大家！