Facebook/Snapchat类平台tracking pixel如何实现动态限流？

这个场景的核心设计底线和普通API限流完全不一样：绝对不能把广告主的合法转化归因请求拦掉，所有限流逻辑的目标是拦恶意流量，而不是卡正常请求的速率，硬阈值一刀切的方案从根上就不适用。

一、动态阈值自动分配机制（解决新老广告主流量差大、人工运维成本高的问题） #

• 新广告主冷启动不做规模预判：没人能提前判断新入驻的是个人小卖家还是头部品牌，完全不用提前做资质审核定阈值。按广告主入驻时选的行业分类给初始弹性基线就行，比如本地服务类小商家初始基线设为日均300次请求，电商、品牌类广告主初始设为日均5000次，这个基线只做异常流量判定的参考值，不是硬拦截的红线。
• 阈值自动滚动升降，零人工运维：用1小时滑动窗口统计每个广告主的有效请求（即通过合法性校验的真实请求）规模，只要连续3个窗口的有效请求占比保持在95%以上，就自动把该广告主的限流阈值上调当前值的50%，多轮调整后自然会匹配头部广告主亿级日请求的规模；如果某个窗口内异常请求占比超过30%，说明大概率遭遇刷量攻击，临时把阈值降到当前窗口有效请求量的120%，先把攻击流量挡在外面，等流量回归正常后阈值会自动回升。
• 全局弹性配额池兜底：从集群总处理能力里划出10%~15%作为共享弹性池，不管广告主当前的阈值是多少，只要请求通过合法性校验，就算超出该广告主的固定阈值，也从共享池里拿配额处理，从机制上避免合法请求被卡。

二、多层前置校验逻辑（先筛恶意流量，避免无效流量占限流配额） #

限流不能只看请求频率，必须先把明显的恶意请求挡在最外层，不让这类请求占用正常业务的配额：

• 第一层：边缘节点无状态校验：在CDN/边缘网关层直接拦截，不需要回源。校验项包括：请求是否携带像素加载必备参数（pixel_id、event_id、设备标识、请求时间戳）、时间戳和当前时间差是否超过24小时、来源IP是否在已知恶意IP/代理IP库、请求UA是否是已知爬虫/扫描器标识、是否缺失正常浏览器请求必带的头字段，这部分拦截的请求直接丢弃，不纳入任何广告主的流量统计。
• 第二层：行为特征校验：请求回源到业务网关后，先判断是不是真实用户触发的有效请求：比如同一个设备ID1秒内发起超过10次像素请求、同一个IP1分钟内给20个以上不同广告主发像素请求、请求没有对应的前置广告曝光/点击日志（即没触达广告直接发转化请求），这类请求标记为低优先级，进入最低等级的等待队列，只有集群有空余能力的时候才处理，资源紧张时优先丢弃，绝对不挤占正常请求的资源。
• 第三层：广告主维度流量基线校验：通过前两层校验的请求，才会计入对应广告主的滑动窗口流量统计。流量在动态阈值范围内的直接放行；超出阈值的请求不直接丢，先暂存到15分钟有效期的消息队列，后台异步做二次特征校验，确认是合法请求就正常处理做归因，确认是刷量就丢弃。

三、极端场景过载兜底机制 #

• 优先级队列调度：所有请求按优先级排队处理，优先级从高到低为：存量广告主阈值内的合法请求 > 新广告主阈值内的合法请求 > 超出阈值待二次校验的请求 > 标记为高风险的待判定请求。集群负载过高时，从最低优先级的请求开始丢弃，绝对不优先丢弃高优先级的合法请求。
• 全局过载熔断：如果集群整体负载超过90%，临时把所有高风险请求的拦截比例拉到100%，同时把弹性共享池的配额全部倾斜给历史转化量Top20%的核心广告主，中小广告主的超阈值请求先暂存到队列，等负载回落后再消费，不做实时丢弃。
• 离线回溯补算：所有被拦截的请求都会留存原始日志24小时，离线跑批时重新做全量校验，把误拦的合法请求挑出来补做转化归因，就算极端场景下有少量合法请求被实时拦截，也能通过离线补算保证归因数据不丢。

踩坑提醒：别用固定时间窗口的限流算法，很容易在窗口边界出现流量突刺打挂服务，所有窗口统计统一用滑动窗口+令牌桶的组合，令牌生成速率和广告主的动态阈值绑定，桶内剩余令牌可以临时借调给有突发正常流量的广告主，不用硬卡速率。

内容的提问来源于stack exchange，提问作者korum