连载中 5/15

风控:黄牛与脚本的对线

2026-09-04 · 485 阅读 · 0 评论 · 0 赞

一秒三千单的"用户"

上一场活动的数据复盘:开抢后一秒内涌入三千笔下单,来自两千个账号——事后核验,真人下单不到三百笔,其余全是脚本:设备指纹高度集中(同一个改机工具的模板)、账号注册时间扎堆、点击轨迹整齐划一到毫秒级。黄牛转手一台加价三百,一次活动薅走几万台。秒杀系统不但要扛住流量,还要在流量里分辨谁是真人——这就是风控的战场。

四类识别信号

单点信号都好伪造,组合起来才有分辨力:设备信号——模拟器、root、改机痕迹、传感器数据异常,设备指纹把同源设备连成网;行为信号——真人的滑动轨迹是带噪声的曲线,脚本是直线;真人答题用秒,脚本用毫秒;画像信号——账号注册时长、历史活跃度、消费记录,养了几天的批量号画像单薄;关系信号——同 IP 段聚集、同收货地址、同支付账户,批量作案的账号在网络关系里抱团。任何一个信号都可以单点绕过,四类交叉后绕过的成本指数级上升。

决策:前置拦与后置清

风控决策分两档执行:前置拦截——开抢前把确定性黑产(历史黄牛、明显脚本)挡在漏斗外,省下的是系统容量;后置清算——疑似但不确定的,放行下单、延迟发货,活动结束后统一核验,命中特征的取消资格——省下的是误杀成本。这样切分的逻辑是代价不对称:拦错一个真人,损失的是信任与舆情;漏放一个脚本,损失的是一台手机——所以前置只拦十拿九稳的,拿不准的交给后置,加上支付与物流环节还有两道兜底。

// 风控决策三档
RiskResult r = riskEngine.check(userId, deviceId, behaviorCtx);
switch (r.level()) {
    case BLOCK  -> return deny("资格校验未通过");      // 前置拦截:确定性黑产
    case REVIEW -> order.markForReview();             // 放行 + 后置清算
    case PASS   -> continueSeckill();                 // 正常放行
}
// REVIEW 单延迟发货,活动后统一核验,误判率进入风控报表

资格与限购

风控之外还有业务规则:限购(一人一单、一个设备一单)、资格(会员专享、预约优先)。这些规则最好在开抢前预计算——资格名单提前生成进缓存,开抢时只做一次查表,而不是现场跑规则引擎。资格预热的另一个好处是缩小现场决策面:开抢瞬间的每个计算都珍贵,能提前算的绝不现场算。

这是一场持续对抗

没有一劳永逸的风控:黑产会试错你的规则边界,识别规则上线几天就被研究透。对抗的节奏是规则迭代、数据回流、快速响应:每场活动的拦截数据回流标注,误杀与漏放都进报表;规则引擎支持热更新,活动进行中就能调整;黑产的试错成本比平台低,所以平台的策略是抬高他的成本——让脚本的开发周期从三天变成三周,一场活动的收益就覆盖不了成本了。挡在漏斗外的流量已经处理完,接下来是漏斗最关键的一层:库存到底该怎么扣。

☕
503

10 年全栈工程师 · 503咖啡馆主理人

#风控#黄牛#设备指纹#黑产对抗#限购

评论 (0)

热门推荐

连载中 11/22

主从搭建实操:从零配出一主两从

光讲原理不过瘾?手把手搭一主两从:my.cnf 六个参数、复制账号、GTID、CHANGE REPLICATION SOURCE TO、SHOW REPLICA STATUS 验收,附翻车排查清单。

#MySQL#主从复制#GTID#主从搭建#高可用
2026-05-07 · 10101 阅读 · 0 评论 · 0 赞
连载中 16/22

连接池:HikariCP 参数与连接风暴

连接池不是越大越好:8 核机器配 1000 连接反而更慢的数学原理,HikariCP 四个必调参数,maxLifetime 与 wait_timeout 的隐形陷阱。

#MySQL#连接池#HikariCP#maxLifetime#连接风暴
2026-05-10 · 9873 阅读 · 0 评论 · 0 赞
连载中 4/16

缓存穿透:恶意 ID 打穿 MySQL 的四道防线

请求的数据在缓存和数据库里都不存在时,缓存形同虚设。聊聊参数校验、空值缓存、布隆过滤器、限流熔断四道防线的原理与组合打法。

#Redis#缓存穿透#布隆过滤器#高可用
2026-05-16 · 9294 阅读 · 21 评论 · 287 赞