实时风控系统架构实战：毫秒级决策引擎的设计与优化

凌晨一点，首尔江南区的外卖订单进入每周最高峰。同一秒里，炸鸡店、炸酱面店、宵夜烤串店的支付请求几乎是同时涌进来，伴随的还有新用户注册、优惠券领取、虚拟资产充值。每一笔都要在几百毫秒内完成风险判断——是正常用户，还是盗刷团伙在批量试探？是真实消费意愿，还是套现风控规则的攻击流量？我在这个项目里负责的是支付风控链路的实时决策引擎，从第一版规则脚本到全链路毫秒级响应的风控平台，中间经历了大量结构设计、延迟优化和故障复盘，这篇文章把其中最核心的工程决策和落地经验整理出来，希望对正在做实时风控或者准备做实时风控的同学有实质帮助。

先交代一个前提：这套系统服务的是跑在韩国本地市场的电商、外卖和票务类业务。这些业务共同的特点是决策不能等，用户从点击下单到完成支付，整个交互的等待时间窗口非常短。业务侧给到风控的同步调用预算，从一开始就卡在一百毫秒以内。所有设计——存储选型、缓存策略、规则编排、模型推理、降级容灾——都围绕这个硬指标展开。这不是一个算法问题，而是一个系统工程问题。

1. 首尔高频场景的特殊性：先搞清楚我们在防什么

1.1 脉冲式流量：高频业务和普通电商的最大区别

很多人一听说“高频”，第一反应是并发高。但实际上，首尔这类大都市的本地生活业务，真正的挑战不是平均并发高，而是流量以脉冲形式集中爆发。

典型的场景有三个。第一是外卖平台的午晚高峰，尤其是周五晚上和下雨天，订单量在几分钟内可以冲到平时的五到八倍。第二是票务平台的演唱会开票瞬间，热门场次开票后一秒内涌入的请求量能超过普通时段一天的总和。第三是限量商品的发售，比如潮玩盲盒、K-pop周边、品牌联名款，这类发售价低、转手溢价高，天然吸引大量自动化脚本和真人代抢。

脉冲流量的本质问题是：系统的每一层都必须按峰值设计，但平时又都处于低负载状态。这对风控系统尤其致命——风控为了拦截风险，需要在峰值瞬间做更复杂的判断，但峰值瞬间恰恰是系统资源最紧张、外部依赖响应最慢的时候。我们的压测基准从线上正常流量改成了“周五晚八点峰值流量回放”之后，才发现很多在平时跑得飞快的接口，在峰值条件下会出现成倍甚至数量级的延迟退化。

1.2 支付渠道碎片化：风控策略必须适配“每个国家的支付国情”

韩国市场的支付生态跟国内完全不同。国内基本是微信和支付宝两分天下，但韩国是典型的碎片化支付市场：信用卡占比最高，其次是实时转账，然后是KakaoPay、Toss、NaverPay这类电子钱包，还有手机小额月结、虚拟资产充值等长尾渠道。

每一种支付渠道的风险特征都不一样。信用卡依赖卡组织授权链路，存在卡信息盗用的可能；实时转账的资金即时到账，一旦放行就很难追回；电子钱包通常绑定了实名银行账户，但账号被盗后可以在极短时间内完成大额转账。

这意味着风控系统不能只做一套通用的“风险评分”，必须根据支付渠道分流执行不同的策略组合。同一个用户在信用卡渠道可以被直接放行，但如果用实时转账支付高价商品，可能就需要额外的设备指纹校验和交易频率检查。这种按渠道差异化的策略编排，直接影响了规则引擎的设计——规则不能是简单的“if-then”堆叠，而是要支持按业务场景、支付通道、用户分层进行多维度配置和动态加载。

1.3 监管合规的双向作用：数据本地化与实名验证是刚约束

韩国对个人信息保护有非常严格的法律框架，外国企业处理韩国用户数据时要满足数据本地化及相关合规要求。这些监管要求表面上是约束，实际上推动了风控系统的自动化程度。

实名验证是其中最有代表性的约束。韩国的很多支付场景强制要求实名，出生日期、姓名、手机号、CI（连接信息）都是用户身份的关键锚点。这些信息本身也是风控的天然特征——一个韩国人的姓名和出生日期组合，能用来做很强的人证一致性校验。盗号团伙往往能拿到账号密码，但很难同时完成手机号的实时验证。

另外，监管要求风控决策记录必须留存一定期限。这意味着决策引擎除了要做毫秒级判断，还要把完整的决策上下文（请求参数、特征快照、命中规则、模型得分）异步落盘，供审计和事后追溯。这块不能小看，决策上下文的数据量非常大，如果设计不好，存储成本和写入性能会成为新的瓶颈。

2. 延迟解剖：一笔订单在风控系统里经历的100毫秒

2.1 同步拦截：高频业务场景的必然选择

做风控有一个绕不开的架构决策：风险判断是同步做还是异步做？

异步方案的思想是“先放行、后分析”，业务请求不等待风控结果，风控在后台异步处理日志和特征，发现风险后再做惩罚性动作。这个方案的好处是实现简单、不影响业务延迟，但问题在于：风险动作已经发生，资金已经流转。对外卖、电商这类交易场景，异步发现的盗刷订单通常已经发货，追回成本极高；对虚拟资产充值场景，异步发现时资产可能已经被转移，损失不可逆。

我们的选择很明确：核心交易链路全部走同步拦截。用户点击支付后，业务方调用风控接口，风控系统必须在预算时间内返回“放行”“拒绝”或“人工审核”的决策。同步拦截带来两个硬性要求：一是接口延迟必须足够低，不能拖垮用户体验；二是风控系统自身的可用性必须极高，因为一旦风控接口超时或报错，业务要么选择放行（承担资损风险），要么选择拒绝（误杀正常用户）。

2.2 全链路环节拆解：100毫秒花在了哪里

一次风控决策不是简单跑一条规则或一个模型，而是一个完整的处理链路。我把一次决策拆成了六个环节：

请求接入 -> 参数校验 -> 特征聚合 -> 策略执行 -> 决策落库 -> 异步回写

请求接入负责鉴权和路由，把请求分发到具体的处理节点。参数校验确认请求格式合法、必填字段完整，这一步能拦掉大量伪造的低质请求。特征聚合是核心环节，要根据请求中的用户ID、设备ID、IP、订单信息，去特征存储里拉取该用户的历史行为、设备风险画像、IP风险等级、商户历史数据等，整合成一条特征向量。策略执行拿到特征向量后，依次执行黑白名单、频控规则、业务规则、模型评分，最后汇总成决策结果。决策落库要把决策结果和请求摘要写入存储，供审计和回扫使用。异步回写则把特征消费情况回传给特征系统，用于近线更新。

在实际压测中，最耗时的往往不是策略执行本身，而是特征聚合。规则和模型跑的再快，如果特征数据读取要花七八十毫秒，整体延迟照样超标。

2.3 延迟预算表：先算账，再动手

在项目启动阶段，我们做了一张延迟预算表，把所有可分配的时间切成细块：

这张表的意义不在于数字有多精确，而在于把“性能优化”这个模糊的目标翻译成了可验收的工程指标。后面每一个技术选型，我们都会先问一句：这个方案在预算内吗？比如特征数据，如果决定从数据库实时查询，单次查询平均要8毫秒，而一个请求平均要查10个特征，光这一项就要80毫秒，直接超标。所以特征存储必须用内存级方案，这一条路就被堵死了。

2.4 超时怎么办：fail-open与fail-close的边界

即使做了延迟预算，系统仍然可能超时。关键问题是：风控决策超时后，业务方应该怎么处理？

业内有两个方向：fail-open（超时放行）和fail-close（超时拒绝）。这两个方向没有绝对的对错，取决于业务场景的资损容忍度。

我们的实践是分场景设定默认值。对低风险、高频、小额场景，比如外卖点餐、便利店扫码支付，默认fail-open，但放行的订单会进入异步回扫队列，离线模型在几分钟内重新评估，发现异常立即触发订单取消和账户限制。对高风险、大额、不可逆场景，比如大额转账、虚拟货币提现、礼品卡购买，默认fail-close，宁可误杀一个正常用户，也不能放走一笔可疑资金。fail-close会带来用户体验伤害，所以必须在超时页面提供清晰的人工申诉入口。

这个边界设计直接影响系统架构——回扫机制不是可选项，而是fail-open策略成立的前提。回扫队列必须扛得住高峰期的放行量，离线模型必须在几分钟内处理完积压数据，否则放行后的风险窗口就会被无限拉长。

3. 特征存取架构：风控的快，七成取决于数据到得有多快

3.1 特征分层：离线、近线、实时各自的边界

风控特征五花八门，但按时效性可以分成三层。

第一层是离线特征，比如用户过去30天的下单金额、历史退货率、注册时长、绑卡数量。这类特征变化慢，由离线任务每天或每小时计算一次，写入特征存储，供在线查询。离线特征的特点是量大，一个用户几十上百个字段很常见，但它们不需要实时计算，预计算好直接查就行。

第二层是近线特征，比如最近5分钟的下单次数、最近1小时的登录设备数、当天已用优惠券数量。这类特征依赖流式计算，通过消费业务日志，用Flink或Spark Streaming做窗口聚合，结果同步到特征存储。近线特征的时效性一般在分钟级，能捕捉到用户在短时间内行为的突变——比如一个用户平时一天下一单，突然在5分钟内下了20单，这通常就是风险信号。

第三层是实时特征，比如当前订单金额、设备指纹、IP风险分、卡BIN所属银行。这类特征只能在请求到来时获取，没法预计算。实时特征是决策中最具区分度的部分，但获取成本也最高。

分层的意义在于：不同时效性的特征用不同的计算和存储策略，不会把所有特征都塞进实时计算，也不会让离线特征拖慢在线查询。简单说，离线特征追求全量，近线特征追求准实时，实时特征追求精准。

3.2 两级缓存：把毛刺磨平的工程手段

特征查询是延迟大头，缓存是解决这个问题的核心手段。我们最终采用的是两级缓存架构。

第一级是应用本地缓存，使用Caffeine。每个风控节点在内存中保存最近查询过的高频特征数据，比如设备风险分、IP风险等级、商户历史违规记录。本地缓存的优势是零网络开销，查询耗时在微秒级；劣势是每个节点各存一份，存在数据不一致的可能，且内存有限。

第二级是分布式缓存，使用Redis Cluster。本地缓存未命中时，查询Redis。Redis的查询耗时要看网络情况，同机房内大约在1到3毫秒，跨机房可能到10毫秒以上。所以机房规划上，风控服务必须和Redis部署在同可用区，尽量避免跨机房同步读取。

两级缓存的组合效果是：绝大多数特征查询能从本地缓存直接命中，只有少量请求需要穿透到Redis。我们把Redis的命中率控制在80%以上，加上本地缓存后，综合命中率超过95%，特征聚合的平均耗时才被压到了30毫秒以内。

两级缓存带来的问题就是一致性。我们的处理原则是：接收最终一致，但必须有兜底。特征写入时携带版本号和更新时间戳，查询时如果发现数据过期超过阈值，宁可返回缓存数据也不做穿透查询——因为穿透查询打爆下游的代价更大，过期数据的风险可以通过规则阈值修正。

3.3 缓存穿透、热key和大key：高频场景的三个坑

缓存设计得再好，落地时还是会踩到几个经典的坑。

第一个是缓存穿透。恶意攻击者会构造不存在的用户ID或设备ID去请求风控接口，这类请求在缓存和存储中都查不到数据，会直接打到下游数据库。如果攻击者用脚本高频循环请求，数据库很快就会被拖垮。我们的方案是布隆过滤器加参数校验：先把所有白名单用户ID和正常设备ID写入布隆过滤器，查询前先走过滤器，过不去的请求直接返回默认特征，不打存储；同时对请求参数做严格校验，非法格式直接拒绝。

第二个是热key。热门商户、热门商品、头部主播的特征数据，在一段时间内会被超高频率查询。如果这些特征集中在同一个Redis key上，这个key所在的节点就会成为热点。我们做了热点key探测，统计每个key的查询频率，超过阈值就把这个key的数据按用户维度或设备维度拆分到多个key，并同时在本地缓存中多放一份热key数据。

第三个是大key。有些用户的行为数据特别多，比如一个疑似机器人的账号可能积累了上万个事件记录。把这些数据整体作为一个key存进Redis，读写的开销都会很大，还可能触发Redis的阻塞操作。处理方案是：特征存储不做全量事件存储，而是把事件聚合成统计指标（计数、均值、最大值、最近一次事件时间），以定长数据结构存储，从源头消灭大key。

3.4 数据一致性：最终一致在风控场景的可接受边界

实时风控对数据一致性有一种天然的妥协：我们接受最终一致，但拒绝无限期不一致。

具体来说，离线特征每天用T+1任务全量刷新，刷新过程中允许查询到前一天的数据；近线特征通过流式任务实时更新，正常情况下更新延迟在一分钟以内，但发生了堆积时可能延迟到五到十分钟。在这个时间窗口内，如果系统基于旧数据做决策，可能会漏掉一些刚发生的风险行为，但可以通过规则层面的频控兜底来弥补。

我们的兜底方案是“双时间戳校验”。特征存储中每个字段记录update_time，业务传入请求时间event_time，决策引擎比较两者，如果特征数据更新时间距离当前时间超过设定阈值，则给该特征打一个“过期”标记。模型评分时，带过期标记的特征会被降权处理；规则引擎中配置了“依赖过期特征”的规则，会被标记为低置信度，需要额外的实时特征来交叉验证。

这套机制保证了：即使数据同步出现了问题，决策引擎也不会拿陈旧数据做激进的拦截或放行。这是风控系统鲁棒性的一个重要细节。

4. 决策引擎：规则与模型协同，怎样设计才能又准又快

4.1 别迷信重型规则引擎：轻量决策树才是常态

很多团队一上来就选Drools或URBP这类重型规则引擎，理由是功能强大、支持复杂规则。但在毫秒级决策链路上，重型规则引擎的复杂匹配算法可能成为性能瓶颈。规则越多，规则之间的条件叠加越复杂，匹配耗时呈指数级增长，这是很多规则引擎的隐藏成本。

我们的方案是自己设计了一套轻量决策引擎，核心思想是把规则预先编译成决策树结构。每条规则拆解成条件表达式和后置动作，条件表达式支持基本的比较运算、逻辑运算、集合运算和正则匹配。规则在配置中心维护，变更后推送到各节点，在内存中编译成决策树，运行时按树结构逐级匹配，跳过无关分支。

实测下来，1000条规则的情况下，单次请求的规则匹配耗时可控制在2毫秒以内，而用Drools跑到同样数据，耗时会高出数倍。不是Drools不好，而是在这样严苛的延迟预算下，重型引擎的通用性我们不缺，缺的是确定性。

4.2 规则分层：准入、频控、业务策略的执行顺序

规则不是一股脑全跑，我们把它分成三层，严格按顺序执行。

第一层是准入规则，也就是黑名单和白名单。黑名单包含已确认的盗号账号、恶意设备、风险IP、可疑卡号；白名单包含内部测试账号、高信用老用户、已验证的商家账号。黑名单命中直接拒绝，白名单命中直接放行。这一层规则最简单，但价值最大——用一个只读的HashSet就能完成O(1)的查询，准确又快速。

第二层是频控规则，检查单位时间内的行为次数。比如“同一设备5分钟内支付失败超过3次”“同一用户10分钟内下单超过10单”“同一IP 1小时内注册账号超过5个”。频控依赖近线特征，需要特征聚合阶段先把对应的计数数据准备好。频控是打击脚本和自动化攻击最有效的手段，也是毫秒级决策的兜底。

第三层是业务策略规则，比如金额阈值、异地登录、新设备大额交易、虚拟资产快速转出等。这些规则依赖的维度最多，计算最复杂，但区分度也最高。业务策略规则允许配置权重和阈值，支持规则命中得分累加，超过阈值触发不同级别的处置动作。

层与层之间是短路关系：第一层命中直接结束决策，不需要继续往下跑。这不仅提高了决策效率，也保证了风险处置的确定性——黑名单不应该因为后面的模型分数低就被放行，这是风控决策的底线。

4.3 模型推理的毫秒之路：小模型加预计算加ONNX Runtime

规则能覆盖已知的风险模式，但未知的、变形的攻击手法需要模型来兜底。在线模型的选型和推理优化，是毫秒级风控的另一个硬骨头。

我们在线模型主要用的是XGBoost和轻量级DeepFM。XGBoost训练完导出成ONNX格式，用ONNX Runtime加载推理；DeepFM则把特征做充分离散化，embedding向量用离线任务预计算好，在线侧只做查表和简单内积。一个关键原则是：模型要小而精，不能贪大。在线模型的单次推理耗时被严格控制在5毫秒以内，特征维度不能超过几百个，层数和树深都有上限。

另一条关键的优化思路是特征预计算。很多模型特征是从原始特征转换而来的，比如“30天消费金额的分位数排名”“7天登录天数的离散化编码”。这些转换如果用Python或Java在推理时实时算，耗时非常可观。我们把所有可预计算的特征转换全部搬到离线任务里，在线推理时直接查表拿最终特征值，推理引擎只做矩阵乘法和激活函数，完全不用做特征工程。

实测数据：ONNX Runtime在CPU上跑一个200棵树的XGBoost模型，单次推理稳定在1到3毫秒。再加上规则匹配的2毫秒，策略执行的25毫秒预算还剩下大片余量，足够支撑后续增加更复杂的策略。

4.4 模型灰度、版本管理与效果监控

模型的迭代频率远高于规则，但模型的误伤影响也远大于规则。我们为模型上线设计了完整的灰度流程。

新模型训练完成后，先在离线数据集上回测，确认AUC、KS、召回率等指标达标。然后执行影子部署：新模型和线上模型同时跑，但新模型的输出不参与决策，只记录评分结果。影子阶段通常跑三到七天，积累足够的新旧模型得分对，分析两者在相同样本上的分歧。只有分歧率低于阈值，才允许进入正式灰度。

正式灰度采用按流量比例放量，从1%开始，逐步提升到5%、10%、20%，每一步都观察线上指标。这里的关键是：不仅要看模型的拦截率是否提升，还要看误伤率有没有恶化。误伤率的观测不能只看总体，要拆到渠道、用户分层和业务场景——一个模型可能总体表现很好，但在某个特定渠道上的误伤率高得惊人。

模型上线后还要做持续监控。我们每天生成一份模型效果日报，包含拦截率、误伤率、资损估算、评分分布漂移等指标。一旦发现某个指标偏离历史基线超过三倍标准差，会触发告警，由算法工程师判断是数据分布变化还是模型退化，决定是重新训练还是回滚旧版本。

5. 高可用与容灾：风控系统不能变成业务故障的源头

5.1 优雅降级：从全量决策到核心保护的降级路径

风控系统的可用性要求比普通业务系统更苛刻，因为风控挂了，业务侧往往只能二选一：全部放行（承担资损风险）或全部拒绝（业务直接停摆）。两个选项都不可接受，所以必须设计分级的降级方案。

我们的降级路径分为四级。

第一级是全量决策，正常运行状态，全部规则和模型参与判断。

第二级是策略裁剪，当特征存储的延迟升高到阈值时，自动跳过依赖分布式缓存的业务策略规则，只跑本地缓存能覆盖的准入规则和频控规则。这一步牺牲的是决策的精细度，保住的是核心的底线风险防控。

第三级是本地降级，当Redis彻底不可用时，决策引擎只运行各节点本地内存中的静态黑名单和基础频控。这个状态下拦截能力大幅下降，但至少能挡住已知的恶意账号和设备。

第四级是逃生通道，当风控进程本身出现OOM或线程池耗尽时，直接返回fail-open的结果，让业务继续运转。逃生通道的语义就是“风控能力归零，业务保命优先”。

每一级降级都有一个开关，部署在配置中心，可以由值班人员一键触发。降级动作必须记录审计日志，降级期间的放行请求全部进入高优回扫队列，由离线模型在几分钟内重新评估，发现风险立即冻结。

5.2 多机房部署与流量治理：首尔场景的容灾细节

首尔的业务流量高度集中，机房的选址对整个系统的延迟和可用性影响巨大。

我们最终采用“单城市多可用区”的部署策略：风控服务在首尔及周边地区的多个可用区各部署一套，前置负载均衡层做流量分发。正常情况下，同一可用区的流量优先转发到同一可用区的风控节点，避免跨可用区的同步调用；当一个可用区异常时，负载均衡自动切走流量，由其他可用区接管。

这里面有个容易踩的坑：很多团队做了多机房部署，但特征存储的Redis没有做跨机房同步，导致流量切走后，新机房的缓存全部未命中，全部请求穿透到数据库，引发连锁故障。我们的方案是Redis采用多副本架构，主副本在一个可用区，从副本在其他可用区，风控节点优先读取本可用区的从副本。虽然存在秒级的数据延迟，但换来了灾备切换时不需要重建缓存。

还有一点是依靠网关层的流量治理。风控接口的前置网关做了流量染色，把同一用户、同一设备的请求会话保持在同一可用区的节点上，避免同一笔交易的多次风控请求分散到不同节点，减少跨节点数据不一致的问题。

5.3 全链路压测：以周五晚上的峰值流量为基准

上线前的压测如果只用普通压测工具造数据，很难发现真实的问题。我们用的是流量回放方案：把线上高峰期的真实请求流量录制下来，在压测环境回放，同时构造一定的流量放大倍数，模拟峰值条件下的系统表现。回放工具最初用GoReplay，后来因为需要复杂的流量修改和编排，干脆自己写了一个基于轻量级代理的回放服务。

压测过程中发现了不少有意思的问题。第一次压测，我们就发现风控接口的P99延迟在流量放大到三倍时从80毫秒飙升到接近400毫秒。排查下来罪魁祸首不是特征查询，而是线程池配置：核心线程数太小，任务排队时间过长，加上线程切换开销，整体延迟直接崩塌。

还有一次压测发现了超时配置的问题。网关层给风控接口配置的读超时是200毫秒，但风控内部依赖Redis的操作超时设的也是200毫秒。当Redis出现偶发慢查询时，风控内部先超时了，返回了一个错误给网关，但网关还在等待，最终报错给业务方。这是一个典型的超时嵌套问题，我们的教训是：下游依赖的超时时间必须小于上游调用方的超时时间，至少留出三分之一的安全余量。

5.4 监控告警：从“系统稳定”到“决策质量”的全维度观测

基础设施层面的监控大家都懂，CPU、内存、磁盘、网络、GC、线程池，这套指标用Prometheus加Grafana就能基本覆盖。但在风控系统上，我们额外关注两类业务质量指标。

一类是决策质量指标，包括：拦截率（被拒绝的请求占全部请求的比例）、误伤率（被拒绝但事后申诉成功的正常请求比例）、资损金额估算（模型预测风险订单的金额加权和）、回扫命中率（异步回扫中确认有风险的订单占比）。

另一类是特征健康度指标，包括：特征平均获取耗时、特征过期率、本地缓存命中率、分布式缓存命中率、特征存储错误率。特征健康度直接决定了决策质量的稳定性——如果特征大面积过期，模型的判断依据就是残缺的，在线指标再好也白搭。

告警阈值不是随便拍的。我们采用基线动态浮动的方式：以最近七天的同期数据为基线，当实时指标偏离基线超过二倍标准差时触发告警。比如拦截率平时稳定在1%到1.2%之间，突然涨到2%以上，这通常意味着规则或模型出现了系统性偏移，需要立即排查。

6. 四个真实故障的复盘：踩过的坑才是最好的文档

6.1 缓存穿透：构造无效设备ID拖垮下游特征库

上线后第一次重大故障，来源于一次针对注册风控接口的攻击。攻击者用脚本批量构造不存在的设备ID和手机号，每次请求都会先去查特征库，查不到再回源到下游的明细数据库，导致下游数据库的连接数被打满，正常用户的风控请求也被拖累。

排查链路是这样的：监控面板上先看到特征存储的错误率飙升，紧接着风控接口的错误率也跟着飙升。查看调用链，发现大量请求都卡在特征查询上，而这些请求的设备ID从来没有在缓存中出现过。进一步分析请求参数的分布，发现设备ID明显是随机生成的字符串，根本不符合正规设备指纹的格式。

修复分两步。第一步是紧急止血：在下游数据库前加了一层防穿透保护，查询不到特征时直接返回默认特征，不允许请求继续穿透。第二步是长效机制：引入布隆过滤器过滤无效ID，同时加强请求参数的合法性校验，对设备指纹格式、手机号格式做前置校验，非法请求直接返回默认决策。这个故障给我们的教训是：风控接口天然会被攻击者重点照顾，所有外部入参都不能完全信任，每一层都要有默认值和处理路径。

6.2 Full GC尖刺：堆内缓存策略的教训

第二个故障发生在一次大促压测期间，现象是风控接口的延迟曲线出现周期性的尖刺，每过一段时间P99就会突然飙到500毫秒以上，持续几秒钟后恢复。

通过GC日志查看，发现Old区在每轮周期内持续增长，触发了几次Full GC，每次Full GC都伴随着长时间的应用线程暂停。堆内存分析显示，本地缓存Caffeine存储的特征数据占用了大量堆空间，尤其是存放近线特征的部分，数据量大、更新频繁，Old区被迅速填满。

修复方案有三条线同时推进。第一，限制本地缓存的总大小和单条数据的容量，设置最大权重，超过后按LRU淘汰。第二，把部分大容量的特征缓存迁到堆外内存，使用堆外存储来存放这些数据，既能保留本地零网络访问的优势，又不会压垮堆空间。第三，调整GC策略，从默认的GC算法切换为基于区域的收集器，并针对风控服务的对象分配特点做了参数调优，把停顿控制在一个可接受的范围内。

这次故障之后，我养成了一个习惯：任何引入堆内存缓存的技术方案，都要先算清楚内存上限，再评估GC影响。

6.3 规则误伤：大促期间“静默拦截”的数字上升了

第三个故障不是系统性能问题，而是决策质量问题。某次K-pop周边限量发售活动中，我们监控到拦截率从平时的1.1%上升到2.8%，但同期申诉率并没有明显上升——这意味着大量用户被拦截后索性放弃了购买，根本没有走申诉流程。

深入排查后，发现误伤主要来源于两条规则的叠加。第一条是“新设备大额支付”，因为周边商品单价高，而大量真实粉丝都是这次活动才首次使用App下单，设备是新的。第二条是“同一IP短时间内多个账号下单”，因为学生宿舍、公司办公室的多个用户通过同一个出口IP访问，完全符合这一规则的特征。

问题出在规则没有感知场景。发售活动的特征是“大量新用户+高消费意愿+集中时段下单”，这在平时是明显的风险信号，但在活动场景下就是正常的用户行为。修复方案是给规则增加场景因子：配置了活动白名单规则，在特定活动时段自动降低对“新设备大额支付”和“同IP多账号”的权重，同时引入“时段性衰减”机制，让规则的影响随时间递减。

这个案例也让我意识到，风控不能只看“拦截了多少风险”，还要看“误伤了多少正常”。很多被误伤的用户不会申诉，而是直接流失，这种隐性损失比资损更可怕。

6.4 跨机房专线抖动：同步依赖的代价

第四个故障来自一次机房网络的局部抖动。我们有两个可用区部署了风控服务，正常情况下每个可用区各处理本区的流量。但一次专线故障导致负责可用区B到特征存储集群的网络延迟从2毫秒飙升到150毫秒，结果可用区B的所有风控请求的延迟都大幅超标，因为大量请求在等待跨可用区的特征查询。

修复思路是彻底消除同步跨机房依赖。首先，风控节点读取特征时，严格按“本可用区副本优先”的顺序，本地可用区没有就从本可用区的缓存读取，只有缓存全部未命中且本可用区副本损坏时才降级跨区读取。其次，为所有特征数据都设置了本地兜底策略——即使本可用区缓存也拿不到数据，宁可返回过期数据加“低置信度”标记，也不能同步等待跨区查询的慢响应。

这次故障的根源不是某个组件坏了，而是架构上存在一个不合理的同步依赖。风控系统追求的是确定性延迟，任何跨机房的同步调用都应该被视为潜在的不稳定因素，必须在架构层面消除。

当下这套系统在首尔跑了大半年，线上最忙的时候每秒处理上万次风控决策，P99稳定在80毫秒上下，降级只触发过两次，其中一次还是我们自己演练时手动触发的。回看整个设计和落地过程，最深的体会是：实时风控系统没有一劳永逸的银弹，所有好的工程决策都来源于对预算的敬畏——延迟预算、内存预算、终局一致性容忍度的预算，每一笔账都要提前算清楚。先把数字定下来，再开始写代码，这是比任何技术选型都重要的一步。如果这篇文章能让准备做实时风控的你少走几个弯路，那就值了。