一、风控概述：实时风控到底是什么
大家好，我是老张。在风控这个领域摸爬滚打了十来年，今天咱们聊聊实时风控。
很多人一听到「风控」，第一反应就是「银行审批贷款」或者「信用卡盗刷」。其实没那么简单。实时风控，说白了就是在用户操作发生的瞬间，判断这个行为是不是「好人」干的。如果判断是坏人，系统得在几百毫秒内拦住他。
核心定义：实时风控 = 毫秒级决策 + 多维度特征 + 动态规则/模型
它不是事后查账，而是事中拦截。
1.1 为什么需要「实时」？
我刚开始做风控那会儿，很多公司还是 T+1 跑批。就是今天的数据，明天才能出报表。你想想看，黑客盗刷了一笔钱，等第二天发现，钱早就转到境外了。
实时风控解决的就是这个痛点。用户点击「支付」按钮，到看到「支付成功」页面，中间大概 1-2 秒。风控系统必须在这 1-2 秒内完成：
- 收集当前请求的上下文（IP、设备、地理位置）
- 查询用户历史行为（过去 5 分钟登录了几次？）
- 跑规则引擎（是否命中黑名单？是否触发频次限制？）
- 调用模型打分（这个行为异常概率是多少？）
- 返回决策结果（通过/拒绝/人工审核）
嗯，这里要注意。整个链条的耗时，通常要求小于 200 毫秒。超过这个时间，用户体验就会明显变差。
1.2 风控在业务中的位置
风控不是独立存在的。它像是一个「安检门」，架在业务系统和用户之间。我画了一张图，帮你理解这个位置关系。
你看这个流程。用户请求先到流量接入层，然后同步调用风控引擎。风控引擎拿到特征数据，做出决策。只有风控放行，请求才会到达业务核心系统。
我在项目中遇到过一种情况：有些业务方觉得风控「太慢」，想绕过风控直接处理请求。结果呢？上线第一天就被薅羊毛薅了 200 万。从那以后，再也没有人敢提「绕过风控」了。
避坑指南：我曾经见过一个团队，把风控做成异步的——先放行业务，再异步跑风控。结果坏人已经得手了，风控才发出告警。记住：实时风控必须是同步拦截，异步只能做辅助分析。
1.3 常见风控场景
实时风控不是只有支付场景。我把它分成三大类，每一类的技术侧重点都不一样。
| 场景 | 典型风险 | 实时要求 | 常用特征 |
|---|---|---|---|
| 支付风控 | 盗刷、洗钱、套现 | 极高（<100ms） | 设备指纹、交易金额、地理位置、商户黑名单 |
| 登录风控 | 撞库、暴力破解、账号盗用 | 高（<200ms） | IP 信誉、登录频次、设备变化、行为轨迹 |
| 营销风控 | 薅羊毛、虚假注册、刷单 | 中（<500ms） | 手机号批量检测、设备关联、IP 聚集度 |
1.3.1 支付风控
支付是实时风控最核心的场景。为什么？因为钱直接流走了。
我记得有一次处理一个盗刷 case。用户人在北京，凌晨 3 点突然在境外消费了一笔。传统 T+1 风控根本拦不住。但实时风控可以：
- 检测到设备指纹与历史不符
- IP 归属地是高风险国家
- 交易金额超过用户历史均值 10 倍
三个特征叠加，规则引擎直接返回「拒绝」。整个过程 80 毫秒。
个人经验：支付风控的规则不要设得太死。比如「单笔超过 5000 元就拒绝」，那用户买台电脑都不行。我建议用动态阈值——根据用户的历史消费习惯，自动调整风控边界。
1.3.2 登录风控
登录风控是风控系统的「第一道门」。坏人进不了门，后面的事就干不了。
登录场景有个特点：请求量极大。一个大型电商平台，每秒可能有几万次登录请求。风控引擎必须扛住这个并发。
我常用的登录风控策略：
- 频次控制：同一 IP 1 分钟内登录失败超过 5 次，直接限流
- 设备变化检测：用户上次用 iPhone，这次突然用安卓，触发二次验证
- 异地登录检测：上次登录在北京，10 分钟后在洛杉矶登录，基本是盗号
嗯，这里有个坑。频次控制不能只按 IP 来。我曾经遇到过一个攻击者，用几千个代理 IP 轮询登录，每个 IP 只试一次。后来我们改成按用户 + 设备指纹做频次，才真正拦住。
1.3.3 营销风控
营销风控，说白了就是防「薅羊毛」。很多公司做活动，预算几百万，结果 80% 被羊毛党撸走了。
营销风控的难点在于：羊毛党的行为看起来和正常用户很像。他们也会浏览商品、也会凑单、也会用优惠券。
怎么区分？我总结了几条经验：
- 设备聚集度：同一个设备上注册了超过 10 个账号，基本是羊毛党
- 手机号特征：170/171 号段、虚拟运营商、刚激活的号码
- 行为模式：注册后 5 秒内就领券、下单，没有浏览行为
核心思路：营销风控不是要「拒绝所有可疑用户」，而是把优惠券发给真正有消费意愿的人。所以规则可以适当放宽，但模型要精准。
1.4 实时风控的技术挑战
说了这么多场景，你可能觉得「不就是写几条规则吗？」。其实没那么简单。实时风控面临几个硬骨头：
| 挑战 | 说明 | 我的解法 |
|---|---|---|
| 低延迟 | 200ms 内完成全链路决策 | 特征预计算 + 本地缓存 + 异步加载 |
| 高并发 | 峰值每秒几万甚至几十万请求 | 无状态服务 + 水平扩展 + 熔断降级 |
| 特征时效性 | 需要「秒级」的特征更新 | Flink 实时流处理 + Redis 高速存储 |
| 规则迭代 | 黑产变化快，规则要快速上线 | 可视化规则引擎 + 灰度发布 + A/B 测试 |
你想想看，一个规则从发现到上线，如果走传统开发流程要一周，黑产早就换招了。所以实时风控系统，规则引擎必须是可配置的，运营同学在后台拖拽就能上线新规则。
1.5 本章小结
实时风控不是什么黑科技。它就是在正确的时间点，用正确的数据，做出正确的决策。
- 它位于用户请求和业务系统之间，是同步拦截
- 三大场景：支付、登录、营销，各有侧重
- 技术核心：低延迟、高并发、实时特征、快速迭代
我个人习惯把实时风控比作「机场安检」。你不能等飞机起飞了再查行李，也不能让所有乘客都不安检直接登机。实时风控就是在「效率」和「安全」之间找平衡。