https://latnx.github.io/docs/notes/d-d64ff9df5332ca3a/Recent content in 实习 on Tequila's 学习笔记Hugo -- gohugo.iozh-cn© 2026 Tequilahttps://latnx.github.io/docs/notes/d-d64ff9df5332ca3a/n-8d5196b783d60f01/Mon, 01 Jan 0001 00:00:00 +0000https://latnx.github.io/docs/notes/d-d64ff9df5332ca3a/n-8d5196b783d60f01/规则引擎 # 规则引擎通过模型，算⼦等⽅式对流量进⾏分析，判断是采取放过，封禁，记录等具体⾏为。 当⽹管层antifiler 服务命中策略后将请求转发到AntionlineServer，AntionlineServer会针对改请求的uri 获取相应的规则，⾸先会尝试从redis中获取规则，如果成功则直接进⾏规则引擎处理，否则查询DB，查 询后同步到redis中，DB的策略时从宙斯盾平台进⾏下发的。 规则分类 # 读取到规则后，规则引擎根据规则的ruleID运⾏特定的逻辑，⽬前规则⼀共分为11种，⿊裤，⽇活，昊天 镜，下载场景参数计数，请求特征异常封禁，SVIP权益异常发现，SVIP组合封禁，双通道校验，（rand， rand2，jstoken 校验），qq浏览器aes校验。 举例说明其中的规则 # 背景 # 打击NA端会员状态篡改破解端，解决普通⽤户获取端上视频播放倍速，⾼清播放权益等问题。破阶端⽤户在端上篡改其会员状态从⽽在端上盗⽤SVIP权益（以倍速播放为代表），其真实身份为普通⽤户。 ⽬前解决⽅案： # 通过新增rule7，rule8对可疑流量进⾏组合封禁： rule7 负责将可疑流量推⼊消费队列，由worker消费，worker通过算⼦判断是否作弊，并将作弊⽤户写⼊缓存。 rule8 则通过缓存来判断⽤户请求是否拦截。 流程说明： rule7： 对query中带有vip=2（svip）的流量进⾏检测，通过clienttype，devuid，version三个值算出MD5值， 之后worker将通过MD5值进⾏封禁。 通过uid设置天级锁，防⽌重复⼊队列消耗资源。 将可疑流量推⼊队列，worker进⾏消费，算⼦判断账号状态以及处置。 worker： 离线worker消费rule7推⼊队列中的数据，通过消息中的模型，算⼦信息 执⾏对应的模型以及算⼦。算 ⼦判断⽤户是否为SVIP，如果是，就放过；否则写⼊redis，之后由rule8执⾏封禁。 antiOnline redis计数 rule8： 通过clienttype，devuid，version 三个值算出的md5值，查询缓存中是否有封禁的MD5 key，如果有则 直接拦截，没有则放过。 rule7 流程图Pasted image 20260512105841.png Pasted image 20260512105926.png Pasted image 20260512110049.png Pasted image 20260512110122.pnghttps://latnx.github.io/docs/notes/d-d64ff9df5332ca3a/n-35bfa97d32e4b211/Mon, 01 Jan 0001 00:00:00 +0000https://latnx.github.io/docs/notes/d-d64ff9df5332ca3a/n-35bfa97d32e4b211/⿊产在带宽作弊、运营活动作弊、流量爬取作弊等场景，都是使⽤bduss模拟登录的⽅式来调⽤接⼝。 他们会⾃⾏修改⼀些业务参数，例如devuid、clienttype、version、UA等来模拟不同客户端类型（Android,iOS,PC,MAC,浏览器）请求。 基于以上背景，我这边想要精准管控bduss在不同设备的使⽤。所以想建设UID+BDUSS+DEVUID+UA的 特征，在某些核⼼的业务接⼝，开启校验。如果发现bduss被乱⽤，采取延迟召回封禁、踢bduss失效等 处置。⽤来提⾼作弊⾏为的召回率、阻⽌作弊⾏为等 存储量⼤。由于bduss失效不会通知该服务，⽆法清理数据。数据积累会越来越⼤。 梳理核⼼接⼝，尤其是扫码登录等登录后⼀定会调⽤的接⼝。并且增加⼀些校准策略。来确定 UID+BDUSS+DEVUID+UA 的特征值。量级较⼤，采⽤延迟处理的⽅式。⼏⼩时更新⼀次。 redis 存储 50G key: uid_md5(bduss)_md5(devuid)_uatype mysql 存储 (100G-1024 个分表)： uid, md5(bduss), devuid, ua, clienttype, status, remark, create_time, update_time Pulsar 消息队列（200G）：baidu/netdisk/antibehavior // mysql 存储: uid, md5(bduss),devuid,uatype,create_time,update_time // redis 存储: key:uid, hash : uid_md5(bduss)_md5(devuid)_uatype：16+16+16+6+3= 57B 接口请求频控制 1个UID，每24小时请求>5次 实时 1个设备，每24小时请求>15次 返回未抢中的业务文案提示 1个IP，每24小时请求>100次 先抽奖，后购买会员。黑产通过刷量先抽中大奖，再买会员，针对于抽奖接口 抽奖接口：1个UID每天请求>20次，则命中策略；1个ip每天请求>400次，则命中策略；1个设备1个接口每天请求>120次，则命中策略； 客户端 接口 状态 web /api/getsyscfg /api/gettemplatevariable /rest/2.0/membership/user /api/loginStatus 采集 wap /api/user/getinfo /api/report/user /api/quota 采集 android （未提供具体接口） 采集 iOS /api/getconfig /api/quota /api/usercfg 采集 pc /api/multidevice/check 采集 mac /rest/2.https://latnx.github.io/docs/notes/d-d64ff9df5332ca3a/n-8a7f0a67a104b931/Mon, 01 Jan 0001 00:00:00 +0000https://latnx.github.io/docs/notes/d-d64ff9df5332ca3a/n-8a7f0a67a104b931/架构与数据流（Q1-Q3） # 1. 你先整体讲一下百度网盘这套反作弊系统的架构，数据流是怎么走的？从请求进入到最终拦截，中间经过了哪些组件？ # 用户请求 ↓ Gateway (Nginx/OpenResty) ↓ Antifilter (Lua 模块，嵌入网关进程) │ - 从 DB 加载策略到共享内存（热更新） │ - 匹配请求 URI + header/query/body 参数 │ - 命中 → 转发到 AntiOnlineServer │ - 未命中 → 透传业务后端 ↓ AntiOnlineServer (Go 服务) │ - 从 Redis 读取规则缓存（miss 则查 DB 回填） │ - 多 Goroutine 并发执行策略 │ - 11 种规则类型：黑库/日活/昊天镜/下载计数/SVIP检测/rand校验… │ - 返回 proxy_type: 1=拦截, 0=放行 ↓ 处置动作：封禁 / 验证码 / 观察 / 记录日志 Antifilter 和 AntiOnlineServer 的分工：Antifilter 只做轻量匹配（URI+参数正则），AntiOnlineServer 做重量过检（查 DB、查缓存、调风控接口）。关键设计：Antifilter 到 AntiOnlineServer 的调用设了超时，到时间没返回就当放行，保证网关响应延迟可控。