第一章：风控系统概述
1.1 什么是风控系统
风控系统，说白了就是一套「防坏人」的系统。
我见过不少刚入行的朋友，一听到「风控」就觉得特别高大上。其实没那么玄乎。你想想看，一个电商平台，用户下单后系统要判断：这人是不是盗刷？是不是恶意退货？是不是机器刷单？这些判断，就是风控系统在做的事。
我个人习惯把风控系统比作「守门员」。业务系统是前锋，负责进球（产生交易）；风控系统是守门员，负责挡住不该进的球（拦截风险）。一个好的守门员，不能漏球，但也不能把自家前锋的球也扑出去——这就是风控的平衡艺术。
核心定义：风控系统是一套基于规则、模型、策略的实时决策引擎，用于识别、评估、拦截业务中的各类风险行为。
1.2 风控系统的核心目标
风控系统的目标，其实就三个词：准、快、稳。
- 准（准确性）：该拦的拦得住，不该拦的别误伤。我在项目中遇到过，某次策略调得太严，结果双十一当天大量正常用户被拦截，客服电话被打爆。嗯，那场面，记忆犹新。
- 快（低延迟）：用户点一下支付，你风控系统不能让人家等3秒。用户早跑了。
- 稳（高可用）：风控系统挂了，业务往往也得停。因为没人敢在风控失效的情况下继续放行交易。
这三个目标，其实是有矛盾的。你想更准，就得算更多特征、跑更复杂的模型，那就慢了。你想更快，就得砍掉一些计算，那可能就不那么准了。怎么平衡？这就是架构师要解决的问题。
我的经验：大多数场景下，延迟是第一优先级。因为用户等不了。宁可放过一个坏人，也别误伤十个好人——这是很多互联网公司的风控哲学。
1.3 低延迟的定义与挑战
什么叫「低延迟」？不同业务场景，标准完全不同。
| 业务场景 | 可接受延迟 | 典型要求 |
|---|---|---|
| 线上支付 | < 200ms | 99% 请求在 100ms 内完成 |
| 注册/登录 | < 500ms | 用户体验可容忍稍长等待 |
| 内容审核 | < 1s | 异步处理为主，实时要求较低 |
| 反欺诈实时决策 | < 50ms | 极高要求，通常需要专用架构 |
为什么会这么严格？因为每一毫秒的延迟，都意味着真金白银的损失。我记得有次做压测，发现风控接口平均耗时从 30ms 涨到了 80ms，结果业务方反馈支付成功率下降了 2%。2% 听起来不多，但乘以每天的订单量，那就是几百万的损失。
低延迟的挑战，主要来自这几个方面：
- 数据获取：风控需要查用户画像、设备指纹、历史行为、关联网络……这些数据分散在不同的存储系统里。每查一次，就是一次网络开销。
- 特征计算：原始数据不能直接用，得加工成特征。比如「过去5分钟该IP的登录次数」，这需要实时聚合计算。
- 规则/模型执行：几百条规则、十几个模型，串行跑肯定慢。怎么并行？怎么剪枝？这是架构设计的核心。
- 网络开销：微服务架构下，一次风控请求可能要调用 5-8 个下游服务。每个服务多 5ms，加起来就是 40ms。
避坑指南：我曾经接手过一个风控系统，延迟一直降不下来。查了半天，发现每次请求都要查一次 Redis 里的黑白名单，而那个 Redis 实例和风控服务不在同一个机房。网络往返就要 10ms。后来把 Redis 搬到同机房，延迟直接砍半。有时候，问题不在代码，在架构部署。
1.4 低延迟风控的架构思路
要解决低延迟问题，我总结了几条核心思路：
- 缓存为王：能缓存的绝不实时查。用户画像、设备信息这些变化不频繁的数据，本地缓存一份。
- 预计算：有些特征可以提前算好。比如用户的「历史交易次数」，每天凌晨算一次存起来，实时决策时直接取。
- 异步化：非关键路径的决策，可以异步处理。比如「事后稽核」类的规则，没必要在实时链路里跑。
- 并行化：规则之间如果没有依赖关系，就并行执行。用 CompletableFuture 或者响应式编程，把串行变并行。
- 就近部署：风控服务和数据源尽量部署在同一机房，甚至同一台物理机。减少网络跳数。
下面这张图，是我个人习惯用的低延迟风控系统架构概览：
这张图展示的是我比较推崇的分层架构。每一层只做一件事，层与层之间通过轻量级协议通信。核心决策引擎放在中间，上下都通过缓存来加速数据访问。
一个小技巧：很多团队喜欢把所有逻辑都塞进决策引擎里。我建议反过来——决策引擎只做「决策」，数据获取和特征计算都交给前置层去做。这样决策引擎本身可以保持轻量，方便横向扩展。
好了，第一章就聊这么多。风控系统不是什么神秘的东西，它就是一个在「准」和「快」之间找平衡的系统。后面的章节，我会深入每个模块的具体实现，包括规则引擎怎么设计、模型怎么部署、缓存怎么用才不会出问题。
记住一句话：风控不是拦住所有坏人，而是在用户还没感觉到痛的时候，把风险处理掉。