Java 面试实录Spring Boot Kafka Redis Spring Security AI 的大厂拷打现场\n场景互联网大厂 Java 求职面试\n人物严肃面试官、搞笑水货程序员燕双非\n\n第一轮电商增长与高并发下单\n面试官我们先从一个电商秒杀场景开始。你用 Spring Boot 做下单接口时如何避免接口被刷爆\n燕双非这个简单先加限流再加 Redis 缓存必要时把库存提前预热到本地缓存里。Spring Boot 里我一般会配合拦截器或者网关做基础防护。\n面试官回答得还行。那如果要在高并发下保证库存不超卖你会怎么设计\n燕双非嗯……可以先把库存放 Redis用原子操作扣减数据库再异步落库。至于一致性嘛反正最后总会对上的大概吧。\n面试官你这个“大概”有点危险。那消息队列在这里怎么用\n燕双非我会把下单请求先写入 Kafka后面的订单服务异步消费。这样削峰填谷前台先返回“抢购成功待确认”。\n面试官可以至少方向是对的。那你会如何处理 Kafka 消息重复消费\n燕双非……加个唯一订单号消费端做幂等校验。比如 Redis 记一下处理状态或者数据库订单表加唯一索引。\n\n第二轮支付与风控链路\n面试官现在订单已经创建成功进入支付环节。Spring Security 在这个场景里怎么保护支付接口\n燕双非登录态要校验JWT 携带用户身份接口鉴权交给 Spring Security。支付这种敏感接口还要加二次校验比如短信验证码或者风控令牌。\n面试官如果第三方支付回调来了你怎么防止伪造请求\n燕双非验签啊检查签名、时间戳、随机串确认是支付平台发来的。要是再严一点可以把回调 IP 白名单也加上。\n面试官回调处理失败时如何保证账务最终一致\n燕双非可以用本地事务先记一条待处理流水然后再发消息给 Kafka。消费端更新订单和账单状态失败就重试。还可以配合 Outbox 模式避免“数据库写成功、消息没发出去”的尴尬。\n面试官不错。那你知道 Micrometer 在支付链路里有什么价值吗\n燕双非可以埋点统计接口耗时、成功率、异常率再接 Prometheus 和 Grafana 看板。这样支付超时、Kafka 堆积、Redis 命中率下降都能更早发现。\n面试官这个回答比刚才靠谱。那如果风控要求实时识别异常下单你会怎么结合 AI 能力\n燕双非可以把用户行为、设备指纹、历史订单特征做向量化再做语义检索或者规则增强如果接 Spring AI 和 RAG把风控知识库、历史案例接入让模型辅助判断风险等级。\n\n第三轮企业协同与智能客服\n面试官最后一个场景我们做企业协同 SaaS用户会上传大量合同和工单。你会怎么设计文档问答系统\n燕双非先文档加载再切分文本做 Embedding存到向量数据库里比如 Milvus 或 Redis。查询时做语义检索召回相关片段再交给大模型生成答案。\n面试官你提到了检索。那如果企业客户要求“不能胡说八道”你怎么控制 AI 幻觉\n燕双非要尽量走 Agentic RAG答案必须基于检索到的企业文档提示词里要求引用来源召回不足就直接说“不确定”。另外可以限制工具调用范围避免模型瞎编。\n面试官如果客服系统还要支持实时消息你会考虑什么技术\n燕双非可以用 WebSocket 做在线会话消息后端再接 Kafka 异步处理工单流转。会话内存可以记录上下文方便多轮追问。\n面试官再补一个问题你如何把这一套系统做成可观测、可扩展的服务\n燕双非服务层用 Spring Boot接口层加 OpenAPI监控用 Micrometer Prometheus Grafana日志用 SLF4J 配合 Logback。容器化后上 Kubernetes配合健康检查和弹性扩缩容。AI 服务和业务服务拆开复杂工作流交给独立编排层。\n面试官行今天先到这吧。你回去等通知。\n\n题目详解\n1. 如何在 Spring Boot 电商秒杀场景中防止接口被刷爆\n高并发场景下入口保护通常分为网关层、应用层、缓存层三道防线。网关层可做 IP 限流、用户限流和黑名单拦截应用层使用令牌桶、漏桶或滑动窗口限流缓存层可将热点商品信息、库存、活动配置提前缓存减少数据库压力。实际业务中通常会结合 Nginx、Gateway 或 Sentinel 一类组件做统一治理。\n2. 如何避免库存超卖\n核心思想是让“扣库存”尽可能原子化。常见方案有Redis 原子扣减库存、数据库乐观锁扣减库存、消息队列异步下单后落库。Redis 方案适合高并发抢购但最终仍需与数据库对账数据库方案更稳妥但吞吐较低。生产中常采用“Redis 预扣减 MQ 异步下单 数据库最终确认”的组合方案并通过幂等键、唯一索引、状态机保证一致性。\n3. Kafka 在下单链路中的作用是什么\nKafka 的价值在于削峰填谷、异步解耦和扩展吞吐。下单请求先进入消息队列订单服务异步消费后写库、扣减库存、发通知。这样前台接口响应更快后端也可按消费能力平滑处理请求。需要注意消费者幂等、消息重试、死信处理和分区顺序性避免重复下单和状态错乱。\n4. 如何处理 Kafka 重复消费\n Java 面试实录：Spring Boot + Kafka + Redis + Spring Security + AI 的大厂拷打现场
Java 面试实录Spring Boot Kafka Redis Spring Security AI 的大厂拷打现场\n场景互联网大厂 Java 求职面试\n人物严肃面试官、搞笑水货程序员燕双非\n\n第一轮电商增长与高并发下单\n面试官我们先从一个电商秒杀场景开始。你用 Spring Boot 做下单接口时如何避免接口被刷爆\n燕双非这个简单先加限流再加 Redis 缓存必要时把库存提前预热到本地缓存里。Spring Boot 里我一般会配合拦截器或者网关做基础防护。\n面试官回答得还行。那如果要在高并发下保证库存不超卖你会怎么设计\n燕双非嗯……可以先把库存放 Redis用原子操作扣减数据库再异步落库。至于一致性嘛反正最后总会对上的大概吧。\n面试官你这个“大概”有点危险。那消息队列在这里怎么用\n燕双非我会把下单请求先写入 Kafka后面的订单服务异步消费。这样削峰填谷前台先返回“抢购成功待确认”。\n面试官可以至少方向是对的。那你会如何处理 Kafka 消息重复消费\n燕双非……加个唯一订单号消费端做幂等校验。比如 Redis 记一下处理状态或者数据库订单表加唯一索引。\n\n第二轮支付与风控链路\n面试官现在订单已经创建成功进入支付环节。Spring Security 在这个场景里怎么保护支付接口\n燕双非登录态要校验JWT 携带用户身份接口鉴权交给 Spring Security。支付这种敏感接口还要加二次校验比如短信验证码或者风控令牌。\n面试官如果第三方支付回调来了你怎么防止伪造请求\n燕双非验签啊检查签名、时间戳、随机串确认是支付平台发来的。要是再严一点可以把回调 IP 白名单也加上。\n面试官回调处理失败时如何保证账务最终一致\n燕双非可以用本地事务先记一条待处理流水然后再发消息给 Kafka。消费端更新订单和账单状态失败就重试。还可以配合 Outbox 模式避免“数据库写成功、消息没发出去”的尴尬。\n面试官不错。那你知道 Micrometer 在支付链路里有什么价值吗\n燕双非可以埋点统计接口耗时、成功率、异常率再接 Prometheus 和 Grafana 看板。这样支付超时、Kafka 堆积、Redis 命中率下降都能更早发现。\n面试官这个回答比刚才靠谱。那如果风控要求实时识别异常下单你会怎么结合 AI 能力\n燕双非可以把用户行为、设备指纹、历史订单特征做向量化再做语义检索或者规则增强如果接 Spring AI 和 RAG把风控知识库、历史案例接入让模型辅助判断风险等级。\n\n第三轮企业协同与智能客服\n面试官最后一个场景我们做企业协同 SaaS用户会上传大量合同和工单。你会怎么设计文档问答系统\n燕双非先文档加载再切分文本做 Embedding存到向量数据库里比如 Milvus 或 Redis。查询时做语义检索召回相关片段再交给大模型生成答案。\n面试官你提到了检索。那如果企业客户要求“不能胡说八道”你怎么控制 AI 幻觉\n燕双非要尽量走 Agentic RAG答案必须基于检索到的企业文档提示词里要求引用来源召回不足就直接说“不确定”。另外可以限制工具调用范围避免模型瞎编。\n面试官如果客服系统还要支持实时消息你会考虑什么技术\n燕双非可以用 WebSocket 做在线会话消息后端再接 Kafka 异步处理工单流转。会话内存可以记录上下文方便多轮追问。\n面试官再补一个问题你如何把这一套系统做成可观测、可扩展的服务\n燕双非服务层用 Spring Boot接口层加 OpenAPI监控用 Micrometer Prometheus Grafana日志用 SLF4J 配合 Logback。容器化后上 Kubernetes配合健康检查和弹性扩缩容。AI 服务和业务服务拆开复杂工作流交给独立编排层。\n面试官行今天先到这吧。你回去等通知。\n\n题目详解\n1. 如何在 Spring Boot 电商秒杀场景中防止接口被刷爆\n高并发场景下入口保护通常分为网关层、应用层、缓存层三道防线。网关层可做 IP 限流、用户限流和黑名单拦截应用层使用令牌桶、漏桶或滑动窗口限流缓存层可将热点商品信息、库存、活动配置提前缓存减少数据库压力。实际业务中通常会结合 Nginx、Gateway 或 Sentinel 一类组件做统一治理。\n2. 如何避免库存超卖\n核心思想是让“扣库存”尽可能原子化。常见方案有Redis 原子扣减库存、数据库乐观锁扣减库存、消息队列异步下单后落库。Redis 方案适合高并发抢购但最终仍需与数据库对账数据库方案更稳妥但吞吐较低。生产中常采用“Redis 预扣减 MQ 异步下单 数据库最终确认”的组合方案并通过幂等键、唯一索引、状态机保证一致性。\n3. Kafka 在下单链路中的作用是什么\nKafka 的价值在于削峰填谷、异步解耦和扩展吞吐。下单请求先进入消息队列订单服务异步消费后写库、扣减库存、发通知。这样前台接口响应更快后端也可按消费能力平滑处理请求。需要注意消费者幂等、消息重试、死信处理和分区顺序性避免重复下单和状态错乱。\n4. 如何处理 Kafka 重复消费\n