Spring Security 与 Kafka、Redis 组合构建安全风控系统架构

后台接到不少准备面试的朋友提问：项目里明明用了 Spring Security 做登录认证，为什么面试官一追问“刷单、盗号、接口被刷你怎么防”就答不深。这道“Spring Security + Kafka + Redis 安全风控系统架构实战解析”其实是个典型的系统设计题，它考的不是某个框架的 API 背得熟不熟，而是你能不能把认证、缓存、消息队列组合成一条能落地、能说清取舍的完整架构链路。这篇文章就把这套链路从头拆到尾，告诉你面试官想听什么，以及真在项目里落地时有哪些坑。

内容适合两类人：一类是准备 Java 后端大厂面试的开发者，看完可以直接把“进-存-算-执”的思路复述出来；另一类是团队里要搭风控系统但不知道怎么下手的技术负责人，文中所有方案都来自可落地的常见实践，不是 PPT 级的架构图。

1. 面试官抛出这道题，到底在考什么

1.1 认证不等于风控，先分清两个层次

很多人一提安全风控，第一反应就是“用 Spring Security 拦截请求，校验 token，不对就返回 401”。这只能算认证，不能算风控。

认证解决的是“你是谁、你能不能进来”的问题，风控解决的是“你这次行为是不是正常用户该干的事”的问题。一个僵尸号的账号密码完全合法，能通过认证，但它凌晨三点用新设备批量下单，这种行为就是风险。反过来，一个被误判的普通用户深夜加班下单，也可能被风控系统误杀。所以面试时第一句话就应该把层次分清楚：Spring Security 负责准入和权限边界，Redis 和 Kafka 负责的是准入之后的行为可信度判断。

这一句话就能让面试官知道你理解这个题目的边界。很多候选人翻车，正是把“认证成功”当作“安全校验完成”，后面所有问题都答偏了。

1.2 三个组件如何分工

用一张表把职责边界说清楚，面试时可以直接照着这个口径讲：

Spring Security 是“入口处的守门员”，Redis 是“大厅里的实时监控”，Kafka 是“把监控录像搬到分析室的传送带”。三者没有谁替代谁的关系，组合在一起才构成完整的风控闭环。

还有一个容易忽略的点：风控决策结果也要通过 Kafka 回流给业务系统。比如风控引擎判定某个账号需要强制二次认证，这个结果通过 Kafka 通知用户服务和网关，业务侧才能执行踢人、冻结、追加验证码等动作。很多人只聊“业务事件进 Kafka”，忘了“风控结果出 Kafka”，这一进一出才是完整的事件闭环。

1.3 先记住这条可复述的架构主线

无论后面怎么展开，面试时你的表述主线最好是：

接入层（HTTP 请求）→ Spring Security 认证与前置风控 → 业务处理 → 行为事件发送到 Kafka → 风控消费端执行规则计算 → 结果通过 Redis 更新状态、通过 Kafka 通知业务方 → 业务方执行拦截或放行动作。

这条主线里有两个关键设计原则：

第一，主链路只做最轻量的风险预判。登录时判断这个 IP 五分钟内失败次数是否超限，这种必须同步完成；完整的设备画像、行为序列分析、关联关系挖掘，全部放到 Kafka 后面异步做。主链路延迟不能因为风控而明显变慢，这是底线。

第二，风控动作要分级。不是非黑即白地“放行/拒绝”，而是分放行、验证码、二次认证、拒绝、冻结、人工审核等不同级别。面试时主动说出分级设计，比只说“拦截”显得完整得多。

2. Spring Security 不是过滤链背书，而是风控切入点

2.1 过滤器链顺序决定你在哪里“动手脚”

Spring Security 的核心机制是过滤器链，从进入 Servlet 容器开始，通过一个注册过滤器把整条安全链路串起来。面试时不需要背出每个过滤器的类名，但必须说清楚三个关键位置：

登录验证码和防爆破逻辑要加在认证过滤器之前。因为用户名密码的认证过程会触发数据库查询和密码哈希计算，如果攻击者拿脚本不停撞库，每次都走到认证器内部，数据库压力很快被打满。前置风控的逻辑是：先看这个 IP 和账号是否已经触发了频率阈值，是就直接拒绝，根本不让请求走到用户名密码校验那一步。

已登录用户的行为风控要加在授权过滤器之后。认证通过、权限校验通过不代表行为合法，此时业务请求还没有进入 Controller，在这里做频率限制和风险名单校验，比在业务代码里到处埋点干净得多。

下面是一个可参考的配置骨架，以 Spring Security 5.7+/6.x 风格为例，6.x 里写法略有调整，但思路一致：

@Configuration @EnableWebSecurity public class RiskSecurityConfig { @Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) { http .csrf(csrf -> csrf.disable()) .sessionManagement(session -> session .sessionCreationPolicy(SessionCreationPolicy.STATELESS)) .authorizeHttpRequests(auth -> auth .requestMatchers("/api/auth/login", "/api/auth/captcha").permitAll() .requestMatchers("/api/admin/**").hasRole("ADMIN") .anyRequest().authenticated()) .addFilterBefore(loginRiskFilter(), UsernamePasswordAuthenticationFilter.class) .addFilterAfter(bizRiskFilter(), AuthorizationFilter.class); return http.build(); } }

注意两点：登录相关接口要放行，否则用户还没登录就被拦住，风控无从谈起；授权过滤器类名在不同版本有差异，5.x 里是FilterSecurityInterceptor，6.x 里是AuthorizationFilter。面试时主动提到这种版本差异，反而是加分项。

2.2 会话与 JWT：风控视角的选型逻辑

如果是单体应用、中后台系统，传统 Session 模式简单可靠，服务端可以随时让会话失效。但多实例部署时必须引入 Spring Session + Redis，把 Session 从内存搬到共享存储，否则用户在一台机器上登录，请求打到另一台机器就变成未登录。

如果是移动端或高并发的开放平台，JWT 无状态方案更合适。但风控场景里有个很尴尬的问题：JWT 一旦签发，服务端无法主动让它失效。账号被冻结、密码被修改、风控要求强制下线，这些场景只靠 JWT 都做不了。所以现实方案基本是“JWT + Redis 状态校验”：

• 用户登录成功后，在 Redis 里写入一个会话状态键，比如risk:user:online:{userId}存设备信息、tokenId、登录时间；
• 每次请求校验 JWT 签名通过后，再检查 Redis 状态键是否正常；
• 踢人、冻结时删除状态键或修改版本号，JWT 即使没过期也无法再通过校验。

面试时可以补一句：真正安全的“无状态”是一种理想，只要涉及主动吊销和实时风控，就需要 Redis 参与状态管理。这句话能体现出你踩过坑。

另外要提一下SecurityContextHolder的存储机制。它是基于 ThreadLocal 的，请求结束后会自动清理。但在 Kafka 消费、异步任务、消息回调里直接取当前用户信息是拿不到的。因此在发送风控事件时，必须把用户ID、设备指纹、IP、登录会话ID这些上下文字段塞进消息体，而不是在消费端依赖请求线程的 SecurityContext。这是一个非常隐蔽但高频的线上坑。

2.3 用认证事件驱动 Redis 计数，做登录防爆破

Spring Security 在认证成功和失败时会发布事件，通过监听这些事件来维护 Redis 中的失败计数，是一种干净的做法。认证成功时清空计数，认证失败时递增计数，超过阈值就触发风控动作。

@Component public class LoginSecurityListener { @EventListener public void onSuccess(AuthenticationSuccessEvent event) { String name = event.getAuthentication().getName(); redisTemplate.delete("risk:login:fail:" + name); } @EventListener public void onFailure(AuthenticationFailureBadCredentialsEvent event) { String name = event.getAuthentication().getName(); String key = "risk:login:fail:" + name; Long count = redisTemplate.opsForValue().increment(key); redisTemplate.expire(key, Duration.ofMinutes(5)); if (count != null && count > 10) { riskProducer.sendLoginRiskEvent(name, "login_fail_limit"); } } }

这种做法比在每个登录接口手写计数逻辑要优雅得多，因为它天然覆盖所有走 Spring Security 认证的入口，而不是只在某一个 Controller 里生效。

生产环境还要注意维度问题。按用户名计数容易被撞库攻击绕过，因为攻击者会换大量用户名；所以实际项目通常按“用户名+IP”组合计数，再叠加纯 IP 维度计数。阈值也不是写死一个数，而是按账号风险等级动态调整，老用户和低风险设备可以放宽。

3. Kafka 把风控从同步链路里解放出来

3.1 为什么不直接 HTTP 同步上报

有一种常见的错误设计：业务系统把用户行为通过 HTTP 同步调用风控服务，等风控返回结果再继续往下走。这样做的坏处很明显：风控服务一旦抖动或者超时，整个业务链路都被拖垮。大促期间流量翻倍，风控系统如果扛不住，业务也跟着挂，这是架构上最忌讳的“强耦合”。

Kafka 在这里的作用是削峰填谷。业务侧只需要把行为事件扔进 Kafka，不需要等待风控计算完成。风控消费端的能力是固定的，消息在 Kafka 里排队，流量高峰被削平，低谷时消费者慢慢消化。用户请求的响应时间不受 Kafka 堆积影响。

另一个理由是审计留痕。风控事件是全量审计的基础，HTTP 调用失败后很难重试，而 Kafka 消息可以保留一段时间，消费失败也能重放。出了安全事故复盘时，Kafka 里的完整事件流是取证的关键材料。用 Kafka 和 RabbitMQ 对比时也可以说：Kafka 吞吐更高、支持分区有序、消息可回溯，更适合大规模行为事件场景；RabbitMQ 路由灵活、延迟队列方便，但蓄流能力相对弱。

3.2 生产端关键参数与主链路性能取舍

Topic 设计上，很多人纠结是建一个大而全的事件 Topic，还是按登录、下单、支付分别建 Topic。我的建议是接入初期就按领域拆分，risk-login-event、risk-order-event、risk-payment-event分开，每个 Topic 独立设置分区数和消费组，互不影响。一个大 Topic 虽然看起来省事，但某个事件类型流量暴涨时会拖累整个消费链路，排查问题也更费劲。

分区键的选型要看有没有顺序要求。同一个用户的操作事件要保证顺序，就用 userId 作为 key，Kafka 会把同一个 key 的消息路由到同一个分区，消费端才能按顺序处理。如果事件之间顺序不敏感，比如纯审计日志，就尽量不指定 key，让分区自动均匀分布。

主链路性能取舍是面试官最爱追问的点。Kafka 生产者的 acks 参数有三个选择：acks=0 只发送不管结果，最高效但可能丢；acks=1 收到 leader 确认就算成功，均衡；acks=all 等待所有副本确认，最安全但最慢。风控事件要求高可靠，但主业务链路不能同步等待 Kafka ack。正确的做法是：kafkaTemplate.send()默认异步发送，配合回调函数处理失败重试和降级，绝不在业务线程里调用future.get()等结果。

Kafka 抖动时如果所有请求都卡在发送等待上，接口 RT 会成片上涨。实践经验是发消息失败后先本地记录到日志或本地文件队列，后台定时任务补发，宁可延迟上报也不能阻塞主流程。

3.3 消费端：手动提交 + 幂等，缺一不可

消费端的核心目标是“不丢不重”。Kafka 的默认语义是 at-least-once，消息可能重复消费，所以必须做到消费幂等。一手动提交 offset，二业务幂等去重，两个缺一不可。

关闭自动提交，消费完成后再 ack，可以避免处理中途挂掉导致消息丢失。但手动提交也有坑：如果先 ack 再处理业务，那业务失败时消息已经提交，会丢；如果先处理再 ack，处理成功但 ack 失败，下次还会重复消费一次。所以要接受“重复消费是常态”，用幂等键做保障。

@KafkaListener(topics = TopicConstants.RISK_LOGIN_EVENT, groupId = "risk-engine") public void consume(ConsumerRecord<String, String> record, Acknowledgment ack) { String eventId = extractEventId(record.value()); String key = "risk:consume:id:" + eventId; Boolean flag = redisTemplate.opsForValue().setIfAbsent(key, "1", Duration.ofHours(1)); if (Boolean.FALSE.equals(flag)) { ack.acknowledge(); return; } try { riskEngine.evaluate(record.value()); ack.acknowledge(); } catch (Exception e) { // 不 ack，等待 Kafka 重试；超过次数后转投死信 Topic riskProducer.sendDlq(record.value(), e.getMessage()); } }

幂等键什么时候写很有讲究。如果先写幂等键再执行业务，业务失败后这个键已经存在，消息就会被永久跳过。所以要么先执行业务成功再写幂等键，要么把幂等键过期时间设得足够长，并且在失败时主动删除。实际项目里最稳妥的组合是“执行业务成功 → 写 Redis 幂等键 → ack”，极端情况下允许少数重复消费，但绝不能因为去重逻辑本身把消息搞丢。

4. Redis 里到底存了哪些风控数据

4.1 限流计数器：从固定窗口到滑动窗口

Redis 做限流最常见的方案有三个，面试时从简单到复杂逐个解释，能体现体系感。

固定窗口最直观：INCR key然后EXPIRE key 60，一分钟内计数超过 N 就拒绝。但固定窗口有个临界问题：第 59 秒和第 61 秒之间可能出现双倍流量，攻击者可以在窗口切换的瞬间发起两波请求。所以只适合对精度要求不高的接口，比如验证码发送次数。

滑动窗口精确得多。用 ZSET 存每个请求的时间戳，请求来了先清理窗口之外的旧记录，再统计窗口内数量，超过阈值就拒绝。由于 ZADD 和 ZREMRANGEBYSCORE 不是原子的，必须写 Lua 脚本保证原子性：

local key = KEYS[1] local now = tonumber(ARGV[1]) local windowMs = tonumber(ARGV[2]) local limit = tonumber(ARGV[3]) local member = ARGV[4] redis.call('ZREMRANGEBYSCORE', key, 0, now - windowMs) local count = redis.call('ZCARD', key) if count < limit then redis.call('ZADD', key, now, member) redis.call('EXPIRE', key, windowMs) return 1 end return 0

Java 侧调用时，member 必须唯一，否则同一个请求 ID 会覆盖旧记录。可以用 UUID，也可以用“用户ID + 当前时间戳 + 随机数”。滑动窗口的缺点是内存占用高，每个请求都往 ZSET 里写一条。生产环境对超高频 IP 限流时，我会用“多层固定窗口”近似滑动窗口，比如同时维护 1 秒、5 秒、1 分钟的计数器，不同粒度覆盖不同流量形态，比单一大 ZSET 更省内存。

令牌桶限流则适合控制平均速率和应对突发流量，Redis 里用 HASH 存令牌数和上次更新时间，Lua 脚本里按时间差补充令牌。面试时能说出“固定窗口简单但有临界问题，滑动窗口精确但费内存，令牌桶适合突发流量”这句总结，基本就够了。

4.2 名单和特征缓存，以及穿透处理

风控名单是 Redis 里第二大类数据。用户黑名单、IP 黑名单、设备黑名单，一般用 String 或 Hash 存储，key 形如risk:black:user:{userId}。名单更新通过 Kafka 广播到所有实例，每个实例再刷新本地缓存，避免每次请求都打到 Redis。

这里有个关键优化：名单判断不能只走 Redis，否则百万级黑名单在 Redis 里全量常驻也是很大的内存成本。常用方案是布隆过滤器 + Redis + 数据库三层：

• 布隆过滤器判断“肯定不在名单里”，直接放行；
• 命中布隆过滤器后再去 Redis 查完整名单确认；
• Redis 没有时去数据库兜底。

布隆过滤器有误判率，会把不在名单里的用户判成“可能在”，所以命中后必须二次确认，这个细节说出来会让面试官觉得你真的处理过数据规模问题。

还有一个隐蔽的坑是缓存穿透。攻击者拿一批不存在于名单的随机 userId 刷请求，每次 Redis 和数据库都查不到，就会直穿数据库。解决办法是对“查无记录”也做空值缓存，缓存几分钟即可。至于缓存雪崩，要给同类数据设置不同的过期时间，避免整点一到全部失效。

4.3 消费幂等和分布式锁的管理

Kafka 消费幂等已经在上一节写过了，Redis 里还有一类重要数据是分布式锁。

风控场景里为什么要加锁？举个例子，规则要求“同一账号每日提现不超过 5 万”，如果两个请求并发到达，风控引擎同时读取 Redis 里今天的累计金额，两个请求都发现没超限，一起放行，金额限制就被绕过了。解决办法是按用户粒度加分布式锁，串行执行风控决策：

SET risk:lock:user:10001 uuid-xxxx NX PX 3000

锁粒度要细到用户，不能全局一把锁，否则所有用户的风控都被串行化，吞吐量直接崩掉。锁超时要设置合理，业务处理时间超过锁过期时间会导致锁提前释放，另一个线程拿到锁后并发执行，又回到最开始的问题。生产环境一般用 Redisson 这类带看门狗自动续期的方案，或者自己实现“业务结束主动释放 + 超时兜底”。

Redis 的淘汰策略在风控场景必须单独说：不能用allkeys-lru，这会让风控名单和限流计数器在内存压力下被随机逐出，直接导致限流失效。正确做法是volatile-lru只对设置了过期时间的非核心缓存生效，名单类关键数据不设过期，或单独走持久化存储。

5. 完整流程演练：一次登录请求的风控全旅程

5.1 请求在应用内的处理时序

拿一个最常见的登录场景串一遍完整链路，面试时把这几个节点讲清楚，架构感就出来了。

第一步，客户端提交用户名密码到POST /api/auth/login，请求进入 Spring Security 过滤器链。

第二步，LoginRiskFilter在认证过滤器之前执行，先查 Redis 里该 IP 维度、该账号维度的登录失败计数和风险状态。如果失败次数超过阈值，或者账号已经进入观察名单，直接返回“触发验证码风控”或“请求被拒绝”，并异步发送一条登录风控事件到 Kafka，记录本次拦截。

第三步，请求通过前置风控后，进入UsernamePasswordAuthenticationFilter执行真正的认证。密码正确时，Spring Security 发布AuthenticationSuccessEvent，监听器清空 Redis 中的失败计数，写入在线会话信息；密码错误时发布失败事件，监听器递增失败计数。

第四步，认证成功后，请求进入授权过滤器，角色和权限校验通过后进入 Controller。

第五步，Controller 生成 token、落库登录日志，同时通过KafkaTemplate异步发送登录成功事件，事件体包含 userId、deviceId、IP、城市、tokenId、设备指纹等字段。

第六步，Kafka 消费端拉取登录成功事件，执行实时规则引擎。规则包括：该设备是否为用户历史上首次出现、登录 IP 是否属于常驻城市、账号是否在短时间内多端登录、是否触发了异地登录组合规则。综合打分后，把结果写回 Redis。

第七步，如果分数超过高风险阈值，风控引擎把 userId 加入观察名单，并通过 Kafka 通知用户服务强制执行“二次认证”或“强制下线”。

注意，整个第六、七步都在用户请求已经返回之后异步完成，主链路只增加了最前置的计数和名单校验，耗时基本只有一次 Redis 读取。

5.2 可参考的过滤器与事件上报代码

前置风控过滤器核心逻辑，可以浓缩成下面这个骨架：

public class LoginRiskFilter extends OncePerRequestFilter { @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws IOException, ServletException { if (!"/api/auth/login".equals(request.getRequestURI())) { chain.doFilter(request, response); return; } String ip = request.getRemoteAddr(); String account = request.getParameter("username"); // 1. IP 维度黑名单 if (isBlockedIp(ip)) { writeRiskResponse(response, 403, "ip_black"); return; } // 2. 账号维度失败计数检查 String failKey = "risk:login:fail:" + ip + ":" + account; Long failCount = redisTemplate.opsForValue().get(failKey); if (failCount != null && failCount > 10) { riskProducer.sendRiskRejectEvent(account, ip, "login_fail_limit"); writeRiskResponse(response, 429, "login_too_frequent"); return; } chain.doFilter(request, response); } }

登录成功之后发送行为事件，注意用异步发送，不能阻塞主线程：

@Component public class LoginEventPublisher { public void publishLoginSuccess(String userId, String deviceId, String ip) { Map<String, Object> event = new HashMap<>(); event.put("eventId", UUID.randomUUID().toString()); event.put("type", "LOGIN_SUCCESS"); event.put("userId", userId); event.put("deviceId", deviceId); event.put("ip", ip); event.put("timestamp", System.currentTimeMillis()); kafkaTemplate.send(TopicConstants.RISK_LOGIN_EVENT, userId, JSON.toJSONString(event)) .whenComplete((result, ex) -> { if (ex != null) { log.error("send login event failed", ex); // 降级：写入本地日志或本地队列，稍后重发 } }); } }

这套代码真正跑起来还要处理很多细节，但作为面试的“关键实现展示”，能说明逻辑和数据流就够了。

5.3 把“进-存-算-执”讲给面试官听

到了表达环节，我建议直接用四个字概括整个架构：进、存、算、执。

“进”是指所有关键用户行为统一进到风控链路。在 Spring Security 这一层做主流程前置校验，在业务层做事件埋点，两条路径最终汇入 Kafka。

“存”是指状态数据分两层存。Redis 存实时计数器和风险状态，保证毫秒级读取；Kafka 和持久化存储存全量行为流，保证可回溯、可重放。

“算”是指风控规则计算分实时和离线。实时计算用 Redis 和本地缓存做简单规则汇总，毫秒级返回；复杂规则和关联分析放到 Kafka 消费者和离线分析链路做，不阻塞主流程。

“执”是指决策结果分级执行。放行、验证码、二次认证、拒绝、冻结、人工审核，每个动作对应不同的业务实现。规则引擎算出一个风险分，再由决策层映射到具体动作，规则可以热更新，而不是改代码发版。

这套话术的好处是结构清晰、有层次感，面试官顺着“进-存-算-执”追问下去时，你也有足够的细节兜住。

6. 高频追问与线上排查技巧实录

6.1 面试追问速查表

整理几个我见过的高频追问，把问题和参考回答方向列成一张表：

这张表基本覆盖了面试官在“Spring Security + Kafka + Redis 风控系统”这道题上能挖的点。答的时候不要背答案，要把自己的思考过程带出来。

6.2 线上常见风控事故与排查顺序

风控系统上线后最常见的坑，我按踩过的频率排一下：

第一是限流误杀。阈值设太紧，正常用户在某个操作上稍微集中就被挡。排查时先看 Redis 计数器分布，是被单个 IP 刷出来的还是所有用户都被限，再决定是调阈值、加白名单还是升级为动态阈值。

第二是 Redis key 集中过期。给一批限流计数设置了相同的 TTL，整点一到所有 key 同时失效，攻击者正好在过期瞬间猛冲，限流完全失效。解决方法是 TTL 加随机偏移。

第三是 Kafka 消费积压。消费者处理事件时调用了外部 RPC 且没有超时设置，下游一抖动，消费者线程全部卡在等响应上，Lag 迅速上涨。排查顺序是先看消费组 Lag，再看消费者线程状态，最后定位外部调用。治理手段包括调大max.poll.records、减少单条消息的重活、异步化外部调用。

第四是缓存穿透打崩数据库。攻击者用不存在的随机 userId 反复请求风控接口，Redis 和数据库都没有记录，请求直达存储层。治理方案就是前面说的空值缓存和布隆过滤器。

排查风控线上事故有一个通用顺序：网关日志看请求是否到达，Redis 监控看内存和 key 是否异常，Kafka 监控看消费 Lag 和 offset 提交是否正常，最后看应用日志里风控过滤器和消费端有没有异常堆栈。按这个顺序走，大部分问题十分钟内能定位。

6.3 我的三点落地建议

真要在项目里落地这套架构，我建议按这个顺序迭代，不要一上来就搞全套。

先从登录防爆破和验证码限流开始，这是投入产出比最高的风控能力，只需要 Spring Security 过滤器 + Redis 计数就能覆盖大多数撞库和短信轰炸场景。跑通之后再扩展下单和支付的行为风控，最后再上设备指纹、关系网络分析这类重武器。

第二个建议是每个风控决策都要可解释。线上被误伤的用户一定会找客服申诉，如果查不到这个用户当时为什么被拦截，问题会非常难处理。所以每次风控决策必须记录 traceId、命中的规则、当时的特征快照。Kafka 负责留痕，Redis 负责短时状态，MySQL 或者数仓负责决策明细持久化。没有审计能力，风控系统等于只挖坑不填坑。

最后一点是风控规则一定要可配置、可灰度。新规则不要全量上线，先按 1% 的流量观察误杀率，再逐步放量。阈值设置永远是权衡题，不是越大越好也不是越小越好，关键是出现问题时能快速回滚。这三点做到位，这套架构才能真正从面试题变成生产系统的骨干，而不是留在简历上好看。