Java 面试实战Spring Boot Kafka Redis Spring Security 在电商风控场景下的 3 轮追问故事背景面试现场严肃的面试官坐在桌前候选人燕双非一脸轻松地走进来。今天的场景是互联网大厂电商风控系统目标是识别刷单、羊毛党、异常登录、异常支付等风险行为要求系统既能扛流量又能保证低延迟和高可用。第一轮基础能力与业务理解面试官先说说你怎么设计一个电商风控系统的核心链路燕双非嗯核心就是订单、登录、支付这些事件先接入做一些规则判断命中就拦截没命中就放行。然后把事件发到 Kafka后面异步做分析。面试官不错至少知道要把同步和异步拆开。那你为什么会选 Kafka不选直接同步调用风控服务燕双非因为同步会拖慢下单链路用户体验差。Kafka 可以削峰填谷后面风控消费者慢慢处理失败还可以重试。面试官继续说Redis 在这里怎么用燕双非Redis 可以做热点用户黑名单、设备指纹、限流计数还有登录失败次数统计。比如某个账号 5 分钟内失败 10 次就直接标记风险。面试官这部分回答得还可以思路是对的。那如果风控规则需要快速调整你怎么支持配置化燕双非可以把规则存在数据库里启动时加载到内存改规则后用管理后台刷新缓存或者直接发消息通知各个节点更新。第二轮技术细节与稳定性面试官你提到缓存和消息了。那如果 Redis 挂了系统是不是就不能用了燕双非呃也不能完全这么说。可以做降级比如 Redis 读不到就走本地缓存或者直接查数据库不过这样性能会差一点。面试官说得有点泛。那本地缓存用什么怎么保证和 Redis 一致燕双非可以用 Caffeine 做本地缓存设置较短过期时间再通过 Kafka 广播失效消息来同步。严格一致性不好保证一般是最终一致性。面试官好终于说到重点了。那 Spring Security 在这个场景里怎么落地燕双非登录态认证、接口鉴权、JWT 校验还有不同角色权限控制。比如商家后台和风控后台权限要分开敏感接口只允许特定角色访问。面试官如果前端和后端是分布式部署JWT 的优缺点是什么燕双非优点是无状态扩容方便不依赖服务端 session缺点是 token 一旦签发后不容易立即失效所以要配合黑名单或者短有效期。面试官你说到了黑名单黑名单放哪里燕双非可以放 Redis登录时校验 token 是否在黑名单里。面试官可以。那如果风控规则越来越多代码里一堆 if-else你怎么优化燕双非可以搞规则引擎或者用责任链模式把每个检查点拆成独立处理器便于扩展。第三轮高并发、可观测性与 AI 增强面试官现在你负责的风控服务日请求量到了几十万 QPS你怎么保证系统稳定燕双非先做限流和熔断比如用 Resilience4j然后消息队列削峰数据库读写分离热点数据缓存另外用线程池隔离不同任务。面试官线程池隔离你具体怎么做燕双非把实时风控、异步画像更新、日志落库分开不同线程池避免某个任务阻塞拖垮整个服务。面试官那怎么监控你说的这些策略有没有生效燕双非用 Micrometer 暴露指标Prometheus 抓取Grafana 看面板再结合日志和链路追踪比如 Zipkin 或 Jaeger 看请求耗时和调用链。面试官如果现在业务要加一个 AI 风控助手支持运营用自然语言问“这个用户为什么被拦截”你怎么设计燕双非可以把风控规则、拦截原因、历史事件做文档加载再用 RAG 检索增强生成。用户问题进来先向量化去向量数据库里查相关规则和案例再由大模型生成解释。面试官那你怎么避免 AI 幻觉燕双非嗯……尽量只让它基于检索结果回答答案里附上证据片段超出知识范围就拒答或者转人工。面试官好今天先到这里。你回去等通知吧。问题详细解析1. 电商风控系统如何设计核心链路电商风控通常覆盖注册、登录、下单、支付、退款等链路。核心设计思路是把实时决策和离线分析分开实时链路负责低延迟拦截异步链路负责画像沉淀、策略迭代和模型训练。Spring Boot 适合快速构建服务Kafka 适合做事件总线把订单、登录、支付事件异步投递到风控消费者既能削峰填谷也利于后续扩展。2. 为什么选择 Kafka 而不是同步调用同步调用会把风控耗时直接叠加到主交易链路上导致下单慢、超时增多。Kafka 的价值在于解耦、削峰和可重试。风控服务即使短暂抖动也不会立即拖垮交易服务。业务上通常会对“强实时”与“可延迟”场景做拆分强实时规则本地快速判断复杂分析异步完成。3. Redis 在风控里有哪些典型用途Redis 常用于黑名单、限流计数、设备指纹、IP 频控、验证码校验、会话态等。比如某个账号短时间多次失败登录可以通过 Redis 原子自增和过期时间完成计数。风控中的很多判断都需要低延迟读取Redis 比数据库更合适。但要注意 Redis 不是万能的关键决策仍需考虑数据来源可靠性和容灾方案。4. 风控规则如何支持配置化推荐将规则抽象为规则配置 执行引擎。规则配置存储在数据库中包含条件、阈值、动作、优先级、适用业务线等信息。服务启动时加载到内存运行时通过管理后台修改配置并利用消息通知或配置中心刷新缓存。复杂场景可进一步使用责任链或规则引擎将不同判断逻辑拆分为可插拔组件。5. Redis 挂了怎么办要做多级降级。第一层是本地缓存如 Caffeine用于承接短期热点数据第二层是数据库兜底第三层是业务降级策略比如放宽某些非关键校验保留核心拦截。系统设计上不追求所有场景强一致而是采用最终一致性确保整体可用性优先。6. Caffeine 与 Redis 如何协同Caffeine 适合作为单机内的本地热点缓存读取快、性能高Redis 适合分布式共享缓存。常见做法是“本地缓存 分布式缓存”二级缓存架构。本地缓存设置短 TTL并通过消息队列广播失效事件减少脏数据窗口。对于风控类系统缓存一致性要求高于普通内容系统因此需要控制失效延迟。7. Spring Security JWT 怎么落地Spring Security 负责认证授权链路JWT 负责无状态身份承载。用户登录后签发 JWT后续请求携带 token网关或服务端过滤器解析并校验签名、过期时间和权限声明。优点是分布式部署友好缺点是 token 无法天然主动失效所以通常配合短有效期、刷新 token、黑名单机制使用。风控后台、运营后台、商家后台应使用不同角色和权限模型隔离。8. 黑名单放哪里一般放 Redis。原因是校验频繁、要求低延迟、需要支持过期和快速更新。黑名单数据可以是 token jti、用户 ID、设备 ID、IP 段等。对安全敏感的场景还需要考虑黑名单容量、持久化、热 key 和过期策略。9. if-else 过多怎么优化如果风控规则直接写成大量 if-else代码会很难维护。可用责任链、策略模式、规则引擎或 DSL 方案进行拆分。比如“登录失败次数检查”“异地登录检查”“设备风险检查”“支付金额异常检查”各自独立每个处理器只关心自己的规则。这样便于新增规则、单元测试和灰度发布。10. 高并发下怎么保证稳定高并发场景要从入口、服务内部、依赖组件三层治理入口层做限流、鉴权和熔断服务内部做线程池隔离、批处理、异步化依赖层做缓存、读写分离和消息削峰。Resilience4j 可用于限流、熔断、重试和舱壁隔离。线程池隔离的目标是避免某类慢任务占满所有资源导致系统雪崩。11. 怎么监控风控策略是否生效Micrometer 可以统一采集业务指标如拦截率、命中率、误杀率、接口延迟、Kafka 积压量、Redis 命中率等再输出到 Prometheus配合 Grafana 可视化。日志用于排障Zipkin/Jaeger 用于链路追踪。风控系统尤其需要可观测性因为策略调整后必须快速判断是否误伤正常用户。12. AI 风控助手如何设计可以采用RAG Agent思路。首先把规则文档、历史拦截案例、操作手册等进行文档加载与切分再做向量化存入 Milvus、Chroma 或 Redis 向量能力中。运营人员提问时先做语义检索拿到相关证据再让大模型基于证据生成回答。若需要跨系统查询、统计或调用工单接口可引入工具调用和 Agent 编排。但要严格控制模型边界减少幻觉。13. 如何避免 AI 幻觉最有效的方法是让模型只基于检索到的证据回答并对答案进行引用约束。对于高风险内容应该输出结构化结论、证据来源和置信度必要时拒答或转人工。这样 AI 才能真正成为风控助手而不是“想当然”的客服。结语感谢阅读希望这篇围绕电商风控场景的 Java 面试实战内容能够帮助你更好地理解大厂面试中的提问方式、业务思维和技术深挖路线也祝你在面试中稳定发挥拿下满意的 offer。