1. 风控系统到底是干什么的——把边界先划清楚做交易系统开发的这些年风控系统是我认为最难啃、也最容易被低估的一块。很多人一提到风控脑子里冒出来的就是加几个 if 判断——下单金额超过多少就拒绝持仓超过多少就拦截。这个认知在系统规模小、用户少的时候确实问题不大但只要并发上来了、业务复杂了、资金体量大了风控系统的设计就直接决定了你的平台是稳稳当当跑几年还是隔三差五出资金窟窿。这篇是交易系统开发系列的第三篇专门聊风控系统。我会把风控的定位、整体架构、核心模块、关键参数的推导过程、实操落地方式以及我自己踩过的坑全部摊开讲。不管你是刚接触交易系统的新人还是正在重构风控模块的老手应该都能拿到一些能直接抄作业的东西。先把一句容易误导人的话说在前面风控系统不是一个功能而是一条贯穿整个交易生命周期的检查链条。从用户点击下单按钮到订单进入撮合引擎再到成交、清算、结算每一步都有对应的风险点风控要做的就是把这些风险点用一套统一的、可配置的、能实时执行的规则管起来。风控做得好用户几乎感觉不到它的存在风控做得烂要么天天误杀正常交易被用户投诉要么漏掉真正的风险导致平台穿仓。1.1 一次下单请求里藏着的风险点我们先跟着一笔普通的下单请求走一遍看看风控到底要在哪些地方插一脚。用户在客户端点买入 1 手 BTC 永续合约请求发到交易网关。网关这时候要做的第一件事就是身份与权限校验——这个账户是不是被冻结了、是不是被限制交易了、是不是处于只读模式。这道检查过不了请求直接打回连订单都不该生成。这是账户级风控。身份过了接着要校验订单本身合不合理价格是不是偏离盘口太远防止乌龙指或者恶意挂单、数量是不是超过单笔限额、下单频率是不是太高防止程序化刷单把撮合引擎打爆。这是订单级风控。订单本身没问题了就要算钱这个用户可用余额够不够、冻结保证金要多少、下单之后整体风险度会不会超过阈值。这是资金与仓位级风控也是整个链条里计算量最大、最容易出问题的一环。订单成交之后事情还没完。持仓在变化行情在波动用户账户的风险度是实时变化的。当行情剧烈波动导致某个账户的风险度跌破维持保证金线系统必须能及时触发预警甚至强制平仓。这是持仓与行情级风控往往需要独立于交易主链路之外异步运行。把这四道检查串起来看你会发现风控系统要处理的数据种类非常多账户状态、订单参数、资金余额、持仓明细、实时行情、历史成交。它既要在主链路上做实时拦截延迟必须控制在毫秒级又要在后台做持续监控不能漏掉任何一个账户。这就是为什么风控系统不能简单地写成几个 if它本质上是一个独立的、有状态的服务。1.2 事前、事中、事后三段式风控的边界业内在划分风控时普遍采用事前、事中、事后三段式。这个划分方式我一开始觉得挺虚的后来做多了才理解它的价值——它明确界定了每一段风控的目标、手段和性能要求也决定了代码该怎么拆。事前风控发生在订单进入撮合引擎之前目标是不让不该进的订单进来。它的特点是同步、阻塞、延迟敏感。用户点了下单必须等风控返回结果才能继续所以事前风控的每一条规则都要足够快通常要求整个检查在 1 到 5 毫秒内完成。事前风控一旦判断失误误杀用户会立刻感知到所以准确率要求极高。事中风控发生在订单成交过程中目标是成交过程中不出乱子。它处理的是并发订单之间的相互影响比如同一个账户在极短时间内下了大量方向相反的订单可能是在试探系统或者进行市场操纵、或者试图用多个子账户绕开单账户限额。事中风控往往是异步的允许有一定的延迟但需要能看到全局视角。事后风控发生在日终或实时清算阶段目标是账要平、数要对、异常要复盘。它包含对账、资金核对、风险报告、异常交易回溯。事后风控对实时性要求最低但对完整性和准确性要求最高——这一环出错往往意味着真金白银的损失。提示不要把三段风控塞进同一个服务里。我早期做过一个大一统的风控服务结果就是性能被事后风控的对账逻辑拖死事前拦截延迟从 2ms 飙到 80ms。后来拆成独立的几个进程各管各的问题才解决。2. 风控系统的整体架构与模块拆解搞清楚风控要管什么之后接下来是架构层面的事。这块内容直接决定你的风控系统是能跑还是能扛。我见过太多团队在项目初期把风控做成一堆散落在业务代码里的判断等业务量上来之后想改规则发现改一处牵动全身最后只能推倒重来。所以这一节我想重点讲清楚架构选型和模块划分背后的逻辑。2.1 从单体风控到独立风控服务的演进小规模系统最常见的是嵌入式风控风控逻辑直接写在交易服务的下单方法里读的是交易服务自己的内存数据。这种做法的好处是简单、延迟低不用跨进程通信缺点是耦合严重、无法复用、水平扩展困难。当业务量增长到一定程度就必须走向独立风控服务。独立的理由有三个第一风控需要全量的账户、持仓、行情数据这些数据分散在不同服务里只有独立出来才能统一汇聚第二风控规则变更频繁独立服务可以独立发布、独立扩缩容不影响交易主链路第三风控的性能特征和交易服务完全不同混在一起会互相拖累。独立风控服务的典型架构是交易网关在下单前调用风控服务做同步校验RPC 调用风控服务内部维护账户的风险快照同时订阅行情和成交消息做异步更新。这个架构的关键难点在于数据一致性——风控服务里维护的账户余额、持仓必须和交易服务、账务服务保持一致。我们的做法是让账务服务成为唯一数据源风控服务通过消费账务变更事件来更新本地快照并定期做全量状态校准。下面这张表对比了两种架构的适用场景你可以对照自己的业务量来选架构形态适用规模延迟水平可维护性扩展性嵌入式风控日活千级以内极低微秒级差规则改动成本高差独立风控服务日活万级以上低毫秒级好规则可配置好独立服务 多级缓存日活百万级低亚毫秒级好需额外维护缓存一致性很好2.2 五个核心风控模块的职责划分独立风控服务内部我习惯按风险类型拆成五个模块。这个拆法不是拍脑袋定的而是按照数据来源和检查时机来划分的每个模块的数据依赖不同计算逻辑也可以独立优化。第一个是账户风控模块。它维护账户的状态机正常、冻结、只可平仓、限制交易等等。这个模块的数据量最小每个账户就几个状态位但查询频率最高因为每个下单请求都要查。我们把这个模块的数据全部放在本地内存里配合一个高效的位图结构单次查询基本就是纳秒级。第二个是订单风控模块。它负责单笔订单的参数校验价格笼子价格偏离盘口不能超过多少、单笔数量上限、最小下单单位、价格精度对齐。这个模块的规则相对静态通常做成配置项启动时加载到内存变更时热更新。第三个是资金风控模块。它负责计算订单所需的保证金、检查可用余额是否充足、判断下单后风险度是否超限。这个模块的计算最重涉及保证金公式、手续费预估、资金费率预估等。我们后来把常用计算做成预计算缓存只有参数变化时才重算。第四个是持仓风控模块。它负责持仓限额、集中度控制、多空双向持仓管理等。这个模块需要感知用户的全部持仓还要处理平仓单和开仓单的差异——平仓单不应该占用新的保证金也不应该受开仓限额限制这是很多人容易写错的地方。第五个是行情风控模块。它监控行情异常比如价格在极短时间内暴涨暴跌、盘口深度骤降、行情源中断。这个模块的规则往往和具体业务强相关需要独立配置阈值。注意模块划分要高内聚、低耦合但也不要分得太碎。我见过有人把风控拆成十几个微服务结果一个下单请求要串行调用十几个服务延迟直接爆炸。我建议初期就是单体服务内的五个模块等真的有性能瓶颈了再往细拆。3. 核心风控规则的设计与参数计算前面讲的都是架构层面的事这一节进入真正的硬核部分——风控规则到底怎么设计参数怎么算。这部分内容网上的资料要么太浅只讲概念不讲公式要么太散东一榔头西一棒槌我尽量系统地把推导过程讲清楚让你不仅知道该配多少还能自己推。3.1 保证金、风险度与强平价的计算逻辑保证金是合约交易风控的核心。我们先把几个基础概念理清楚再上公式。一笔仓位的合约价值Notional Value等于合约价值 标记价格 × 持仓数量 × 合约面值其中标记价格是风控使用的价格基准它不等于最新成交价而是经过平滑处理的公允价格为了防止有人用一笔异常成交价来操纵强平。初始保证金是开仓时必须冻结的资金初始保证金 合约价值 / 杠杆倍数比如 10 倍杠杆下开 1 手价值 10000 USDT 的合约初始保证金就是 1000 USDT。维持保证金是维持仓位不被强平的最低资金要求维持保证金 合约价值 × 维持保证金率维持保证金率通常远小于 1/杠杆比如杠杆 10 倍时维持保证金率可能只有 0.5%。初始保证金和维持保证金之间的差额就是系统留给用户的缓冲垫。账户风险度是衡量账户健康程度的核心指标风险度 账户权益 / 占用保证金账户权益 钱包余额 未实现盈亏。占用保证金 所有仓位初始保证金之和。当风险度下降到 1 附近说明账户接近强平线风险度跌到维持保证金线以下就该触发强平了。强平价格的推导稍微复杂一点以逐仓做多为例强平发生的条件是账户权益等于维持保证金开仓保证金 (强平价 - 开仓价) × 数量 × 面值 强平价 × 数量 × 面值 × 维持保证金率解这个方程得到做多强平价强平价 开仓价 × (1 - 初始保证金率 维持保证金率) / 1注意这里初始保证金率 1/杠杆。做空方向的符号相反推导逻辑一样。这个公式是风控系统的核心每一次账户状态变化都要重算或增量更新强平价。提示强平价的计算看似简单但实际系统里要考虑手续费、资金费率、部分平仓、多空双向持仓等一堆因素。我们的做法是把强平价计算封装成一个独立函数用大量单元测试覆盖各种边界情况任何一个参数改动都要重新在测试网上跑一遍验证。3.2 限频、限仓、限价三道闸门怎么设保证金解决的是钱够不够的问题限频、限仓、限价解决的是行为合不合理的问题。这三道闸门设计得好能挡掉绝大多数异常流量和恶意操作设计得不好就是无尽的用户投诉。限频Rate Limit最常见的实现是令牌桶算法。每个账户维护一个令牌桶以固定速率补充令牌每次下单消耗一个令牌桶空了就拒绝。令牌桶的容量决定了允许的突发流量。参数怎么设我一般根据撮合引擎的抗压能力倒推如果撮合引擎单分区能扛 5 万 TPS一个分区下有 1000 个活跃账户那理论上每个账户平均 50 TPS。但平均值没意义要设成能挡住尾部流量我通常把账户级限频设在 20 到 50 TPS 之间再叠加一个 IP 级限频兜底。令牌桶的关键参数有三个速率每秒补充多少令牌、容量桶最多存多少令牌、初始令牌数。速率决定持续承载能力容量决定突发容忍度。比如速率 20、容量 40意味着用户平时每秒 20 单攒满后可以瞬间爆发 40 单。限仓分三个层次单笔限仓、单账户限仓、全市场限仓。单笔限仓防止一笔巨单砸穿盘口单账户限仓防止单一用户头寸过大全市场限仓防止整体杠杆过高。参数设置要考虑市场流动性我一般把单账户限仓设成该合约市场总持仓量的 1% 到 5% 作为起点再根据实际运行情况调整。限价就是价格笼子限制订单价格不能偏离标记价格或盘口中间价太远。做市商除外——做市商需要挂远离盘口的单子提供流动性所以要给做市商单独开白名单。普通用户我一般把价格笼子设在盘口价的 ±3% 到 ±5%具体看合约波动率。3.3 规则引擎的设计与配置化管理风控规则最容易失控的地方就是硬编码。早期我见过一个项目所有风控规则都是一堆 if 判断写死在代码里运营想调整一个阈值都要发版开发每次发版都提心吊胆。所以从一开始风控规则就应该做成可配置、可热更新、可灰度的。我的做法是设计一个轻量级的规则引擎。每条规则包含几个要素规则 ID、规则类型账户/订单/资金/持仓/行情、触发条件、执行动作拒绝/预警/降杠杆、优先级。规则配置存在配置中心风控服务监听配置变更实时热加载。规则条件的表达我倾向用简单的表达式引擎而不是上重型规则引擎比如 Drools因为后者性能开销大、学习成本高对风控这种追求极致延迟的场景不划算。下面是一个规则配置的示例结构你可以直接参考字段说明示例ruleId规则唯一标识order_price_deviationruleType所属模块orderpriority执行优先级数字越小越先执行10condition触发条件表达式abs(price - markPrice) / markPrice 0.05action命中后的动作REJECTenabled是否启用truegrayList灰度生效的账户范围[vip_*, whitelist_001]热更新的时候有个坑要特别注意规则切换的原子性。如果一条规则从拒绝改成预警在切换的瞬间可能有一半请求走旧规则、一半走新规则导致行为不一致。我们的做法是用一个版本号来标记规则集风控执行的整个链路锁定同一个版本号切换时新请求走新版本存量请求继续走旧版本直到结束。4. 实操搭一个能扛住并发的实时风控引擎前面讲的都是设计这一节进入实现。我会用一个简化的例子把风控引擎的数据结构、执行流程、性能优化点都讲一遍。语言我用 Java 举例其他语言的思路完全一样。4.1 数据模型与内存结构设计风控引擎的核心是账户风险快照RiskSnapshot。它把风控需要的所有数据聚合成一个对象避免每次检查都去查数据库。一个 RiskSnapshot 大致包含这些字段public class RiskSnapshot { private long accountId; private int accountStatus; // 账户状态位 private BigDecimal walletBalance; // 钱包余额 private BigDecimal unrealizedPnl; // 未实现盈亏 private BigDecimal usedMargin; // 占用保证金 private BigDecimal maintenanceMargin; // 维持保证金 private ListPosition positions; // 持仓列表 private MapString, RateLimiter limiters; // 各维度限频器 private long version; // 快照版本号用于乐观锁 }这个对象全部放在本地内存里用 ConcurrentHashMap 按 accountId 索引。快照的更新走两条路一是消费账务和成交的变更事件做增量更新二是定时做全量校准。增量更新的关键在于幂等——同一个事件重复消费多次快照结果必须一致所以每个事件都带一个递增的序列号快照记录已处理的最大序列号遇到旧事件直接丢弃。内存占用是我踩过一个大坑。一张快照算下来一两 KB账户数到百万级就是几个 GB 的内存。我们的优化是冷账户快照落盘热账户快照常驻内存。判定冷热的标准就是最近一次交易时间超过 24 小时没交易的账户快照序列化到 Redis内存只保留一个引用下次交易时再按需加载回内存。4.2 风控检查的执行流程与代码骨架一次完整的事前风控检查执行流程是固定的账户状态检查、订单参数检查、资金持仓检查、限频检查任何一步失败立即返回。这个顺序不能随意调换——便宜的检查放前面昂贵的检查放后面这是性能优化的基本原则。账户状态检查几乎零成本放最前资金持仓计算最重放最后。这样一旦前面拒绝后面的重计算直接跳过。代码骨架大致是这样的public RiskCheckResult check(OrderRequest req) { RiskSnapshot snapshot snapshotCache.get(req.getAccountId()); if (snapshot null) { return RiskCheckResult.reject(ACCOUNT_SNAPSHOT_MISSING); } // 1. 账户状态成本最低 RiskCheckResult r accountRuleChecker.check(snapshot, req); if (r.isRejected()) return r; // 2. 订单参数成本低 r orderRuleChecker.check(snapshot, req); if (r.isRejected()) return r; // 3. 限频成本中等 r rateLimitChecker.check(snapshot, req); if (r.isRejected()) return r; // 4. 资金持仓成本最高放最后 r marginRuleChecker.check(snapshot, req); if (r.isRejected()) return r; return RiskCheckResult.pass(snapshot.getVersion()); }这里有个细节要强调资金持仓检查是唯一会修改状态的步骤因为订单通过后要冻结保证金、占用额度所以它必须在所有只读检查通过之后执行避免只读检查失败后还要回滚状态。冻结操作要保证原子性我们用 CASCompare-And-Swap配合版本号实现如果冻结时发现版本号变了说明有并发请求改了快照就重试。4.3 性能与一致性怎么保证风控引擎的性能瓶颈通常出现在三个地方快照查询、规则计算、限频计数。我逐一说说优化手段。快照查询的优化点是索引结构。accountId 用 long 类型做主键ConcurrentHashMap 的哈希分布已经足够均匀正常情况下单次查询就是几十纳秒。真正拖慢的是快照 miss 时的加载加载涉及 Redis 或数据库 IO动辄几毫秒这时候整个请求就被卡住了。解决办法是预热 异步加载交易活跃期开始前把活跃账户的快照批量预加载miss 时先快速拒绝并触发异步加载避免阻塞主链路。规则计算的优化点是预计算和缓存。保证金公式里的很多参数杠杆、维持保证金率、合约面值在一段时间内是固定的我们把这些参数缓存起来每次计算只做必要的乘除。另外同一个账户连续下单时如果行情没变、持仓没变风险度计算的结果可以复用。我们用参数指纹来做缓存 key指纹未变就直接返回上次的结果。限频计数的优化点是避免锁竞争。令牌桶如果用 synchronized 实现在高并发下会严重排队。我们改成无锁的原子操作用 AtomicLong 记录上次补充令牌的时间戳和当前令牌数每次请求用 CAS 尝试更新失败就重试。实测下来无锁方案在 10 万 TPS 下延迟比加锁方案低一个数量级。一致性的保障是另一条线。风控快照和账务数据之间一定会有短暂的不一致因为事件是异步消费的关键是要控制不一致的窗口并且在不一致发生时倾向于保守。比如账户余额快照比真实值多了可能导致超额下单比真实值少了只是误杀。所以我们做增量更新时如果事件乱序或者缺失宁可把账户标记成待校准并临时降低其限额也不冒险放行。提示风控系统的降级策略一定要提前设计好。我遇到过一次快照服务整体不可用结果风控直接拒绝所有下单整个平台交易瘫痪了半小时。后来我们加了降级逻辑当风控服务部分不可用时只保留最核心的账户状态和余额检查其余检查全部放行走异步补查。宁可事后追责也不能因为风控自己故障把交易全掐死。5. 常见问题与排查技巧实录风控系统上线之后问题会以各种意想不到的方式冒出来。这一节我把这些年遇到过的典型问题整理出来配上排查思路和解决办法做成速查表的形式方便你遇到问题时对照定位。5.1 风控误杀、漏杀与穿透误杀是用户投诉最多的。最常见的误杀原因是快照滞后用户刚入金账务服务更新了余额但风控快照还没消费到这笔事件导致用户下单被拒。排查方法很简单对比风控快照的 version 和账务服务的 version看差多少。解决办法是给关键操作入金、出金加穿透机制——这类操作完成前允许通过直接查账务服务来校验绕过快照。漏杀则危险得多。漏杀通常发生在并发场景两个请求同时读取了同一个快照都通过了检查然后都去冻结保证金结果账户被超额占用。根因是检查和使用之间没有原子性。解决办法就是前面说的 CAS 版本号冻结时校验版本号版本变了就重试整条检查链。穿透指的是用户找到规则漏洞绕过限制。我见过最典型的穿透案例单账户限仓 100 手用户开了 100 手然后想通过先平后开的方式在同一秒内既持仓 100 手又完成新开仓。我们的限仓逻辑当时没考虑平仓和开仓在同一瞬时的执行顺序导致限额被短暂突破。修复方式是引入瞬时持仓上限即在计算开仓后持仓时不考虑同时发起的平仓单只看已有持仓加新开仓。5.2 高并发下的延迟与热点问题高并发场景下风控引擎会遇到两类典型问题长尾延迟和热点账户。长尾延迟表现为 P99 延迟远高于 P50。比如平均 1ms但 P99 到了 200ms。根因通常是偶发的 GC、快照 miss、锁竞争。排查要分两步先用火焰图定位 CPU 热点再用 JFRJava Flight Recorder或类似工具看 GC 停顿。我们的经验是风控服务的堆内存不要设太大4 到 8 GB 就够用 G1 或 ZGC能把 GC 停顿控制在个位数毫秒。热点账户是指少数账户占据了大部分请求量比如做市商或者量化团队。一个热点账户可能每秒发起几万次查询把对应分片的 CPU 打满。解决办法是热点探测 独立处理对访问频率超阈值的账户单独标记把它们的快照独立出来甚至单开一个专用的处理线程或实例避免影响普通用户。5.3 问题速查表我把常见问题、排查方向和解决手段整理成表方便你现场对照问题现象可能原因排查方向解决手段用户下单频繁被拒快照滞后、限频阈值偏低对比 version、查看限频日志加穿透机制、调整阈值账户出现超额占用检查与冻结非原子查看并发冻结流水CAS 版本号重试P99 延迟突然飙升GC 停顿、热点账户火焰图、JFR、分片监控调整 GC、热点隔离强平价计算偏差参数缓存过期、公式边界单元测试、标记价格核对修复缓存刷新、补测试风控服务频繁重启内存溢出、快照膨胀堆内存监控、账户数统计冷热分离、快照落盘规则更新不生效配置中心推送失败对比本地规则版本加重试、加版本校验6. 一些上线后才明白的经验风控系统这个东西纸上谈兵和真刀真枪跑起来完全是两回事。我在实际运行中攒了几条经验都是文档里不会写、只有踩过坑才明白的。第一条是风控的日志必须完整且可回溯。每一条被拒绝的订单都要能查到是被哪条规则、在什么数据状态下拒绝的。我们最初日志打得太随意出了问题根本查不到原因后来改成结构化日志每次风控检查都把快照的关键字段和命中的规则 ID 一起打出来排查效率提升了不止一个档次。第二条是风控参数不要一次调到最优要留观察期。新规则上线时我建议先跑影子模式——规则照常执行、照常记录命中但不真的拒绝订单。观察一周看看命中率、命中账户特征确认没有大面积误杀再切换到真实拒绝。这个习惯帮我们避开了好几次大规模误杀事故。第三条是永远不要相信单一数据源。风控的快照、账务的余额、撮合的持仓这三个数据对不上是常态对上了才是意外。所以定期做全量对账是必须的发现不一致要能自动修复或者至少告警。我们的对账任务每小时跑一次把风控快照和账务数据逐账户比对差异超过阈值的账户自动冻结交易并通知人工介入。最后想说的是风控系统没有做完的那一天。市场在变、用户在变、攻击手段在变风控规则也得跟着变。把它设计成一个规则可配置、状态可观测、故障可降级的系统比一开始就把规则写得多么严密要重要得多。我现在维护的这套风控引擎核心代码三年没大改过但规则配置改了几百版靠的就是这种引擎稳定、规则灵活的架构思路。
