Spring Boot Kafka Redis Spring Security互联网大厂 Java 面试实录电商风控场景场景某互联网大厂 Java 岗位面试。面试官严肃克制候选人是“水货程序员燕双非”嘴上很会答得对时会被夸答不清时会开始打太极。第一轮系统设计入场先看你能不能把业务讲明白面试官我们做的是电商交易链路用户下单后要做风控、库存、支付预校验。你会怎么拆这个链路燕双非我会先把下单接口做成 Spring Boot 的 REST API前端提交订单后后端先查库存再走风控再发消息给支付和履约服务。核心是把同步链路尽量短异步部分用 Kafka 承接。面试官思路还行先把主链路压短继续说。面试官那风控规则怎么做动态配置比如同一用户在不同时间段、不同设备上的风险等级不一样。燕双非我会把规则放到数据库里配合 Spring Cache 或 Redis 缓存规则数据规则更新时通过消息通知失效缓存。复杂一点的话可以加一个规则引擎但如果只是基础风控先用配置表也能撑住。面试官不错缓存失效和配置下发这块你至少想到了。面试官如果要做“限购”和“防刷”你怎么防止并发下重复下单燕双非我会在 Redis 里做分布式锁或者原子扣减结合数据库唯一约束兜底。下单时先校验幂等 token避免重复提交。订单服务和库存服务之间尽量用消息最终一致。面试官这个方向是对的别把锁只理解成“加个 synchronized 就完事”了。第二轮技术深挖开始看你是不是只会背名词面试官你说用了 Kafka那在订单创建后发消息如果消息重复消费了怎么办燕双非嗯……这个一般就是消费者做幂等吧比如按订单号查一下有没有处理过。也可以在数据库里加唯一索引或者用 Redis 记录消费状态。Kafka 本身我记得偏吞吐高至于 exactly once……我平时项目里用得不多通常靠业务幂等兜底。面试官回答得不算完整但方向没跑偏。面试里能说出“业务幂等兜底”已经比只会说“消息队列解耦”强。面试官Spring Security 怎么接入 JWT 做无状态鉴权燕双非登录成功后签发 JWT客户端带着 token 调接口。服务端在过滤器里解析 token拿到用户身份和权限放进 SecurityContext。这样就不用服务端保存 session 了适合前后端分离和微服务场景。面试官可以继续往下想token 过期、刷新、踢人下线呢燕双非这个……我一般会把 refresh token 和 access token 分开短 token 访问接口长 token 续期。踢人下线可能要配合 Redis 黑名单或者版本号控制。我写到这一步一般就差不多了。面试官嗯至少不是“JWT 永不过期”的那种回答。面试官如果风控服务比较复杂规则很多缓存命中率还不稳定你怎么观察线上性能燕双非会接 Prometheus 和 Grafana 看接口延迟、QPS、错误率再用 Micrometer 埋点。链路排查可以上 Jaeger 或 Zipkin 做分布式追踪看看是缓存慢、Kafka 堵了还是数据库抖了。面试官这个比较像干过活的人说的话。第三轮场景推进到支付闭环看看你能不能兜住边界问题面试官支付回调来了但是订单状态已经被别的线程更新过一次了你怎么保证状态流转正确燕双非我会设计订单状态机状态流转只允许从某些状态转到某些状态比如“待支付”到“已支付”。回调更新时加乐观锁版本号或者用 SQL 条件更新限定当前状态避免乱跳。面试官很好这才是交易系统该有的约束意识。面试官如果支付链路里还要接入第三方服务接口很慢你怎么避免拖垮主流程燕双非我会把第三方调用放到异步任务里必要时用 Resilience4j 做超时、熔断、限流和重试。对用户来说先返回“处理中”后面通过回调或者轮询确认结果。面试官可以至少知道别把所有希望都压在一个慢接口上。面试官最后一个问题假设你要做一个风控订单查询后台支持运营同学按条件检索订单、看实时指标你会怎么组织接口和数据结构燕双非查询接口我会用 Spring Boot 提供 REST API复杂条件查询可以拆成分页接口和聚合接口。列表数据用 DTO不直接暴露实体实时指标可以从 ES、Redis 或专门的统计库取。前端如果要订阅实时变化还可以用 WebSocket 推送。面试官思路整体是连贯的。你有些地方说得还不够深但基本能看出你知道业务和技术怎么拼起来。面试官今天先到这里你回去等通知吧。面试问题详细解答1. 电商下单链路如何拆分典型做法是把“库存校验、风控、订单落库、支付预创建、履约通知”拆成多个步骤。主链路尽量同步完成必要校验并快速返回非核心动作用 Kafka 异步解耦。这样既能降低接口耗时也便于扩展和降级。2. 风控规则如何动态配置规则可存数据库并缓存到 Redis 或本地缓存。规则变更时通过消息通知各实例刷新缓存。若规则复杂可引入规则引擎若业务简单配置表缓存已经足够。关键在于规则版本、灰度发布和变更可追踪。3. 如何处理并发重复下单与限购常见组合是幂等 token、防重提交Redis 原子操作或分布式锁做抢占数据库唯一索引做最终兜底。库存扣减建议采用“预占库存”或“乐观扣减补偿”模式避免超卖。4. Kafka 消息重复消费怎么办消息队列通常只能保证至少一次投递消费者必须设计幂等。可以使用订单号、业务流水号做去重配合数据库唯一键、消费记录表、Redis 去重标记等方案。核心是让“重复执行一次”和“执行一次”结果一致。5. Spring Security JWT 如何实现无状态鉴权登录后签发 JWT客户端请求时携带 token。服务端在过滤器或拦截器中解析 token校验签名、过期时间、权限信息并将认证结果放到 SecurityContext。由于不依赖 session天然适合微服务和前后端分离。6. JWT 的过期、刷新与踢下线怎么做通常采用短期 access token 长期 refresh token。access token 用于接口访问refresh token 只用于续期。踢下线可以通过 Redis 黑名单、token 版本号、用户会话状态表等方式实现确保旧 token 失效。7. 线上性能如何监控可用 Micrometer 统一埋点指标Prometheus 采集Grafana 展示。若要分析链路延迟和调用关系可使用 Jaeger 或 Zipkin 做分布式追踪。重点关注接口耗时、错误率、队列堆积、缓存命中率和数据库慢查询。8. 支付回调如何保证状态流转正确交易系统应设计状态机所有状态流转受控。更新时可以用乐观锁、版本号或条件更新 SQL 限定当前状态防止回调乱序、重复回调、并发覆盖等问题。支付、退款、关闭等状态都要严格定义。9. 第三方支付接口很慢怎么办把慢调用从主流程剥离采用异步任务、超时控制、重试和熔断。Resilience4j 可以实现超时、限流、熔断、隔离等能力避免外部依赖拖垮核心交易服务。对用户可先返回处理中状态再通过回调或轮询同步结果。10. 查询后台如何设计接口列表查询应使用分页和筛选条件返回 DTO 而不是实体。复杂检索可依赖 Elasticsearch实时状态可以来自 Redis 或消息驱动的统计表。若有实时推送需求WebSocket 适合做运营大屏或订单状态变更提醒。感谢阅读希望这篇电商风控场景的 Java 面试实录能帮助大家更好地理解面试中的业务拆解、技术选型与高频追问方式并在实际求职中更有底气。 Spring Boot + Kafka + Redis + Spring Security：互联网大厂 Java 面试实录（电商风控场景）
Spring Boot Kafka Redis Spring Security互联网大厂 Java 面试实录电商风控场景场景某互联网大厂 Java 岗位面试。面试官严肃克制候选人是“水货程序员燕双非”嘴上很会答得对时会被夸答不清时会开始打太极。第一轮系统设计入场先看你能不能把业务讲明白面试官我们做的是电商交易链路用户下单后要做风控、库存、支付预校验。你会怎么拆这个链路燕双非我会先把下单接口做成 Spring Boot 的 REST API前端提交订单后后端先查库存再走风控再发消息给支付和履约服务。核心是把同步链路尽量短异步部分用 Kafka 承接。面试官思路还行先把主链路压短继续说。面试官那风控规则怎么做动态配置比如同一用户在不同时间段、不同设备上的风险等级不一样。燕双非我会把规则放到数据库里配合 Spring Cache 或 Redis 缓存规则数据规则更新时通过消息通知失效缓存。复杂一点的话可以加一个规则引擎但如果只是基础风控先用配置表也能撑住。面试官不错缓存失效和配置下发这块你至少想到了。面试官如果要做“限购”和“防刷”你怎么防止并发下重复下单燕双非我会在 Redis 里做分布式锁或者原子扣减结合数据库唯一约束兜底。下单时先校验幂等 token避免重复提交。订单服务和库存服务之间尽量用消息最终一致。面试官这个方向是对的别把锁只理解成“加个 synchronized 就完事”了。第二轮技术深挖开始看你是不是只会背名词面试官你说用了 Kafka那在订单创建后发消息如果消息重复消费了怎么办燕双非嗯……这个一般就是消费者做幂等吧比如按订单号查一下有没有处理过。也可以在数据库里加唯一索引或者用 Redis 记录消费状态。Kafka 本身我记得偏吞吐高至于 exactly once……我平时项目里用得不多通常靠业务幂等兜底。面试官回答得不算完整但方向没跑偏。面试里能说出“业务幂等兜底”已经比只会说“消息队列解耦”强。面试官Spring Security 怎么接入 JWT 做无状态鉴权燕双非登录成功后签发 JWT客户端带着 token 调接口。服务端在过滤器里解析 token拿到用户身份和权限放进 SecurityContext。这样就不用服务端保存 session 了适合前后端分离和微服务场景。面试官可以继续往下想token 过期、刷新、踢人下线呢燕双非这个……我一般会把 refresh token 和 access token 分开短 token 访问接口长 token 续期。踢人下线可能要配合 Redis 黑名单或者版本号控制。我写到这一步一般就差不多了。面试官嗯至少不是“JWT 永不过期”的那种回答。面试官如果风控服务比较复杂规则很多缓存命中率还不稳定你怎么观察线上性能燕双非会接 Prometheus 和 Grafana 看接口延迟、QPS、错误率再用 Micrometer 埋点。链路排查可以上 Jaeger 或 Zipkin 做分布式追踪看看是缓存慢、Kafka 堵了还是数据库抖了。面试官这个比较像干过活的人说的话。第三轮场景推进到支付闭环看看你能不能兜住边界问题面试官支付回调来了但是订单状态已经被别的线程更新过一次了你怎么保证状态流转正确燕双非我会设计订单状态机状态流转只允许从某些状态转到某些状态比如“待支付”到“已支付”。回调更新时加乐观锁版本号或者用 SQL 条件更新限定当前状态避免乱跳。面试官很好这才是交易系统该有的约束意识。面试官如果支付链路里还要接入第三方服务接口很慢你怎么避免拖垮主流程燕双非我会把第三方调用放到异步任务里必要时用 Resilience4j 做超时、熔断、限流和重试。对用户来说先返回“处理中”后面通过回调或者轮询确认结果。面试官可以至少知道别把所有希望都压在一个慢接口上。面试官最后一个问题假设你要做一个风控订单查询后台支持运营同学按条件检索订单、看实时指标你会怎么组织接口和数据结构燕双非查询接口我会用 Spring Boot 提供 REST API复杂条件查询可以拆成分页接口和聚合接口。列表数据用 DTO不直接暴露实体实时指标可以从 ES、Redis 或专门的统计库取。前端如果要订阅实时变化还可以用 WebSocket 推送。面试官思路整体是连贯的。你有些地方说得还不够深但基本能看出你知道业务和技术怎么拼起来。面试官今天先到这里你回去等通知吧。面试问题详细解答1. 电商下单链路如何拆分典型做法是把“库存校验、风控、订单落库、支付预创建、履约通知”拆成多个步骤。主链路尽量同步完成必要校验并快速返回非核心动作用 Kafka 异步解耦。这样既能降低接口耗时也便于扩展和降级。2. 风控规则如何动态配置规则可存数据库并缓存到 Redis 或本地缓存。规则变更时通过消息通知各实例刷新缓存。若规则复杂可引入规则引擎若业务简单配置表缓存已经足够。关键在于规则版本、灰度发布和变更可追踪。3. 如何处理并发重复下单与限购常见组合是幂等 token、防重提交Redis 原子操作或分布式锁做抢占数据库唯一索引做最终兜底。库存扣减建议采用“预占库存”或“乐观扣减补偿”模式避免超卖。4. Kafka 消息重复消费怎么办消息队列通常只能保证至少一次投递消费者必须设计幂等。可以使用订单号、业务流水号做去重配合数据库唯一键、消费记录表、Redis 去重标记等方案。核心是让“重复执行一次”和“执行一次”结果一致。5. Spring Security JWT 如何实现无状态鉴权登录后签发 JWT客户端请求时携带 token。服务端在过滤器或拦截器中解析 token校验签名、过期时间、权限信息并将认证结果放到 SecurityContext。由于不依赖 session天然适合微服务和前后端分离。6. JWT 的过期、刷新与踢下线怎么做通常采用短期 access token 长期 refresh token。access token 用于接口访问refresh token 只用于续期。踢下线可以通过 Redis 黑名单、token 版本号、用户会话状态表等方式实现确保旧 token 失效。7. 线上性能如何监控可用 Micrometer 统一埋点指标Prometheus 采集Grafana 展示。若要分析链路延迟和调用关系可使用 Jaeger 或 Zipkin 做分布式追踪。重点关注接口耗时、错误率、队列堆积、缓存命中率和数据库慢查询。8. 支付回调如何保证状态流转正确交易系统应设计状态机所有状态流转受控。更新时可以用乐观锁、版本号或条件更新 SQL 限定当前状态防止回调乱序、重复回调、并发覆盖等问题。支付、退款、关闭等状态都要严格定义。9. 第三方支付接口很慢怎么办把慢调用从主流程剥离采用异步任务、超时控制、重试和熔断。Resilience4j 可以实现超时、限流、熔断、隔离等能力避免外部依赖拖垮核心交易服务。对用户可先返回处理中状态再通过回调或轮询同步结果。10. 查询后台如何设计接口列表查询应使用分页和筛选条件返回 DTO 而不是实体。复杂检索可依赖 Elasticsearch实时状态可以来自 Redis 或消息驱动的统计表。若有实时推送需求WebSocket 适合做运营大屏或订单状态变更提醒。感谢阅读希望这篇电商风控场景的 Java 面试实录能帮助大家更好地理解面试中的业务拆解、技术选型与高频追问方式并在实际求职中更有底气。