1. 为什么会有第三篇RTB与RTA的边界问题还远没解决前两篇把概念聊透了RTB实时竞价解决的是每次曝光机会怎么拍卖给谁RTA实时接口解决的是广告主在拍卖前怎么表达我要不要。原理听起来都不复杂但真到了工程落地你会发现一堆概念解释不了的问题——RTA到底放在竞价前还是竞价后调用接口超时了平台怎么处理名单同步延迟了会不会误伤预算这些才是在一线做广告技术每天要面对的事。我写这篇文章的动机很简单。两篇发出去之后后台收到不少私信问的东西不约而同地集中在同一类不是RTB和RTA什么区别这种概念题而是我们打算接RTA但不知道服务端该怎么做平台给的接口文档就一张纸返回0和1但线上老出时序问题这类实战题。所以这篇我不再重复名词解释直接把我在项目里踩过的坑、验证过的架构方案、跟不同平台对接时总结出来的规则掰开讲。这篇适合的读者大概有两类一类是广告技术岗的同学想看RTA服务端怎么从零搭起来、怎么跟RTB链路配合不翻车另一类是广告投放或增长团队的技术负责人需要判断RTA这个事值不值得做、成本到底有多大、风险在哪个环节。概念部分我会快速带过重点全部放在真正跑线上之前你必须想清楚的事。2. 一条广告请求的完整旅程从曝光机会到RTA决策要理解RTA在工程上为什么麻烦先得把它放回一条真实广告请求的完整链路里看。很多方案讨论到最后变成扯皮根本原因是参与方默认的时序不一样。2.1 链路中各参与方到底在做什么一次典型的信息流广告请求从用户端发起链路大致是这样的用户在App里刷出内容媒体前端向自家广告系统请求广告广告系统媒体侧把这次曝光机会打包成竞价请求发给自己对接的ADX交易平台ADX再把请求广播给所有参与竞价的DSPDSP拿到请求后根据广告主预设的策略决定是否出价、出多少价然后把竞价响应返回ADXADX收集所有DSP的出价选出最高价返回给媒体媒体渲染广告展示。过去没有RTA的时候DSP这一层就是广告主在程序化链条里的全部话语权。DSP内部用离线人群包、规则引擎帮你做判断这个用户在人包里出价不在人包里不出价。问题在于这份提前圈好的人和此刻必须要决策的人之间总有缝隙。用户今天下午刚在你的App里下过单晚上刷信息流又刷到你的广告离线人群包压根没更新预算白烧。RTA把决策权从离线圈选挪到了实时在线查询。DSP在收到ADX的竞价请求之后多一步操作把这次请求的用户标识、广告位信息、上下文参数打包调一次广告主自建或托管的RTA接口问一句这个用户你要不要要不要出价出多少钱RTA接口返回决策结果DSP再据此决定是否参与竞价。2.2 两种时序模式出价前调用与竞价中调用RTA在整条RTB链路里的触发时机不同平台有不同实现这是最容易被忽略的差异点。第一种叫出价前RTA也叫预竞价RTA。DSP在竞价响应发出之前先向广告主RTA发起查询。RTA说拦截DSP就不参与出价RTA说放行DSP才进入后续的出价策略计算。这种模式的好处是干净拦截的流量根本不会进入竞价环节广告主不会浪费一分钱。坏处是路径变长了DSP内部本身就有策略计算、出价预估、预算控制一堆逻辑现在前面又加了一道网络远程调用延迟压力全部压给了时间预算。第二种叫竞价中RTA也叫竞得后RTA。DSP先按默认策略正常出价如果竞拍赢了在真正向媒体下发素材之前再调一次RTA确认要不要展示。这种模式对延迟更宽容一些因为竞价还没结束之前已经过去了半程但问题在于它很尴尬——如果你已经竞下来了RTA却返回拦截那这次曝光要么硬着头皮展示违背了广告主的意图要么放弃展示媒体可能扣DSP的钱甚至影响后续竞价资格。所以很多平台实现的是混合模式核心大预算广告主用出价前RTA长尾广告主用竞得后RTA兜底。我自己对接过的几家平台绝大多数建议用出价前RTA并且会在接口文档里给你标清楚RTA超时后平台的默认行为。这个默认行为特别关键一会儿单独讲。时序模式触发位置优点缺点典型场景出价前RTADSP竞价响应前拦截彻底、不浪费出价延迟敏感、链路变长高预算品牌、效果广告主竞价中RTADSP竞得后延迟容忍度较高竞得后再拦截成本高候选广告主、素材优选2.3 时间预算怎么算留给RTA的只有20毫秒现在聊那个最现实的问题RTA调用到底有多少时间预算。媒体侧对整条广告请求的时限要求通常很苛刻从用户触发曝光到媒体拿到可渲染的广告总预算一般控制在100毫秒到200毫秒之间。你可以把它理解成一条流水线媒体前端占40毫秒ADX内部决策占20毫秒DSP竞价计算占50毫秒网络传输来回占剩下的。RTA作为DSP内部决策的一部分它从DSP侧发起到广告主RTA服务返回响应整个网络调用加业务计算的预算通常只有10到30毫秒。我在实际项目里测过一个普通的HTTP/HTTPS调用如果连接没复用光TCP建连加TLS握手就能吃掉5到15毫秒。换句话说如果你的RTA服务还在用最原始的方式每次请求现建连接那你还没开始算业务逻辑时间预算就已经烧了大半。所以RTA服务端第一个要做的事不是优化算法而是把网络链路理顺连接复用、长连接、网关直连、避开跨地域的物理距离。在这儿多说一句千万别小看GC停顿。Java写的RTA服务在高峰期一次Full GC停顿控制在50毫秒以内都算可以了但在RTA场景里你可能只有20毫秒预算一次停顿就会造成连锁超时。很多团队后来把高频判定逻辑从Java挪到C或者Go并不是因为Java写不了业务而是因为内存管理和调度上Go和C在极低延迟场景下更可控。2.4 RTA返回值不只是0和1平台接口文档里最常见的RTA返回值是1放行、0拦截。但真实业务里只靠一个0/1远远不够。我见过最实用的做法是返回一个整型枚举不同数值对应不同后续策略。比较典型的取值设计1放行按广告主默认出价策略参与竞价2放行且提高出价系数用于核心高价值人群抢量3放行但降低出价系数用于泛人群试探性出价4拦截不参与竞价5仅观察出价但结果只记录不干预灰度对照把这个枚举设计放在RTA服务端的意义在于你可以用同一套接口做灰度实验。线上先跑模式5记录RTA决策和实际大盘数据的差异确认命中率、误伤率符合预期之后再把模式切到真正的拦截或提价。我在某平台项目里就是这么做的先观测两周决策日志跟投放报表做对比发现拦截名单的曝光占比和历史人工圈选数据只差0.7个百分点才放心切了硬拦截。没有灰度模式你根本不敢直接上代码。3. RTA服务端的架构取舍与超时控制讲完请求链路接着讲你自己的RTA服务怎么搭。这一节的内容是我在多个项目里反复调整后沉淀下来的不一定是最优解但绝对是最不容易踩坑的套路。3.1 接口形态与性能目标先定指标再选协议RTA服务对外暴露的接口形态基本跟着平台方的规范走。绝大多数平台支持HTTPSJSON少数大流量平台支持HTTP/2或gRPC。如果平台给选择我的建议是优先HTTP/2或gRPC原因只有一个连接复用。普通HTTP/1.1每次请求都要建连TLS握手成本反复发生在高并发下还会触发服务器TIME_WAIT堆积。HTTP/2多路复用同一条连接可以并发多个请求连接的建立成本被摊薄到大批请求上RTA这种短请求、高并发、低延迟场景简直是为它量身定做的。性能指标上我自己用的标准线单机QPS目标做到1万以上接口延迟TP99稳定在10毫秒以内TP999尽量控制在30毫秒以内。为什么是TP99而不是平均延迟因为平均延迟在广告这个场景里没有意义你被晚返回的10%请求拖了后腿平台照样给你算超时超时率才是决定你被降级的关键指标。服务端语言选型我没有强烈的站队偏好但有一点必须承认在RTA这种纯查询、无状态服务的场景里Go和C的优势比Java明显。Java的JIT预热、内存占用和GC难以预测这三点在低延迟在线服务里都是负分项。如果你的团队只有Java背景也不是不能做只是要在JVM参数、堆内存规划和GC选择上花更多工夫。3.2 数据存储与检索全量放Redis还是本地算RTA服务要查的数据本质上是一堆名单和规则黑名单、白名单、已购人群、高频活跃人群、竞品拦截名单每份名单底下是几千万甚至上亿的用户ID。查询语义很简单给我一个用户ID告诉我他在名单里还是在名单外。最直接的实现是全量名单放RedisRTA请求进来先查Redis判断命中后返回。这个方案看起来简单但有个隐患Redis的访问延迟稳定但每多一次网络往返就在消耗你的超时预算。RTA服务到Redis的网络往返在数据中心内部一般是0.5到1毫秒听起来不多但如果你的判断链路由三段组成——查黑名单、查白名单、查频控——累计网络开销就直接逼近预算上限了。我在项目里用的是分层策略热数据放本地内存冷数据放Redis再用BloomFilter做一层确定不在名单里的快速判断。具体来说每份名单在RTA服务本地维护一个BloomFilter或者类似的有损索引请求来了先用它判断如果BloomFilter说不在名单里就直接返回放行根本不用碰Redis如果BloomFilter说可能在名单里再去Redis确认精确状态。实测下来因为绝大多数流量本来就不在名单里BloomFilter帮你过滤掉了八九成的Redis查询而且BloomFilter的误判方向可控——它只会把不在名单里的流量误判成可能在名单里绝不会把在名单里的流量漏掉。精确匹配和近似匹配的代价差异要算清楚。全量名单进本地内存几千万条用户ID大概占用几百MB到1GB内存单机上可以承受但如果你有十份名单内存就有点紧了。BloomFilter把内存占用压缩一个数量级用极小的误判成本换掉大量网络IO这笔交易非常划算。3.3 降级与熔断宁可放错不可漏投的默认方向RTA服务面向的是高并发生产环境宕机、网络抖动、代码Bug都只是时间问题。所以防的是最坏情况你的RTA服务挂了平台那边收到超时会怎么处理。这里有一个必须先想清楚的选择题RTA接口超时或不可用时平台的默认兜底行为是放行还是拦截大部分平台默认是放行也就是RTA查不到结果就按广告主愿意投来处理。对广告主来说这意味着服务不可用期间你的广告继续投放但所有过滤规则全部失效。如果你接RTA的目的是拦截已购用户、拦截竞品人群那这种情况下就是裸奔钱在不断烧但你看到的后台数据还一切正常。少数平台默认是拦截RTA不通就不投。这种兜底反过来带来问题一次网络抖动就能让你的投放量瞬间归零后面恢复的时候预算又可能激进反弹。所以降级方向不能简单地说哪个对必须结合你的业务目标。我在某电商广告主的项目里把数据分成两类处理一类是必须拦截的数据比如已购用户这类数据在RTA服务本地做了一份静态镜像即使服务异常也能用本地文件继续判断另一类是可放行的数据比如竞品拦截名单服务异常时直接放行让投放系统继续跑。这样既避免了全量失效也避免了全量停投的极端情况。熔断器的设计也要提前规划。RTA服务自身要监控两个指标RTA请求的成功率和响应延迟。如果成功率连续下跌或者TP99大面积超过平台给的超时线就要主动触发熔断让RTA快速返回默认值而不是让请求在服务里排队等待。有个细节很多文章不会提平台侧的调用超时时间一般比你自己的超时时间短。你设定RTA服务内部超时10毫秒但平台从发起请求到等待响应的超时可能是200毫秒。这中间有个差值就导致了大量平台上显示超时但你没感受到慢的诡异情况。解决办法是在每次日志里记录平台侧的竞价请求时序戳你自己统计出从平台发起到RTA收到请求的网络耗时才能定位到延迟到底出在哪个环节。4. 时序陷阱与数据一致性对账和容错那些事RTA服务本身写起来不难难的是它依赖的数据一直在变。用户在下单、在取消关注、在把广告关掉你用来决策的名单却可能还是昨天下午的镜像。这一节讲的就是数据怎么同步、同步坏了怎么兜底、线上怎么对账。4.1 名单同步的双向链路离线导入加增量消息你的RTA服务需要的数据一半在广告主业务系统里一半可能在媒体平台侧。名单同步链路通常有两段。第一段是业务数据到RTA存储。广告主的用户订单表、注册表、会员表经过ETL汇入数据仓库离线任务每天生成一次全量名单导入到RTA服务的评测库与此同时订单、退单等实时事件通过MQ发到RTA服务更新增量数据。全量覆盖保证最终一致性增量流保证时效性两者配合是标配。第二段是媒体侧的交互数据。用户在你的广告位上点了不感兴趣这个操作记录在媒体平台侧DSP当时就收到了相关事件但要把这份数据同步到广告主的RTA名单里链路可能绕上一圈。有的平台提供离线报表可以让广告主拉取屏蔽名单有的通过事件回调接口通知。这块的建设程度每家平台差别很大建议对接时先确认清楚。4.2 延迟与丢失场景下的兜底设计同步链路一长时序问题就来了。最经典的一个场景用户今天下午5点下单订单增量消息在5点03分发出RTA消费消息更新名单花了5秒但用户6点又刷到广告——按理说已购用户不该投了但名单更新其实已经完成了为什么还在投排查下来大概率不是RTA名单的问题而是媒体平台侧的缓存。很多DSP会对RTA决策结果做短期缓存同一个用户几分钟内不打第二次RTA直接用上一次的决策结果。这是为了控制RTA的QPS但副作用就是你刚更新的名单在下一次缓存过期之前不生效。这类问题不在你自己的控制范围内只能通过两种办法缓解一是跟平台约好缓存时间短期名单场景把缓存调到最短二是接受这个延迟把RTA应用在容忍分钟级延迟的场景而不是几十秒级敏感场景。消息丢失也是高发问题。增量消息队列如果出现积压或丢消息可能导致某个用户的名单状态持续错误。我建议全量快照的频次不要只做每日一次核心名单可以做到每4到6小时拉一次全量作为增量消息的兜底。全量快照任务本身占用带宽但胜在能自愈——即使增量丢了下一次全量会把状态纠正过来。4.3 决策日志与对账体系怎么搭RTA服务上线后第一件事是建对账第二件事才是调策略。没有对账体系你根本不知道RTA在线上到底做了什么。RTA服务每次决策至少要落一条日志字段包含请求ID关联竞价请求、用户ID加密脱敏后的、广告位ID、决策模型版本号、决策结果放行/拦截/提价/降级、决策耗时、当时名单版本号。这条日志本身很简单但它是对账的基础。对账分两级。小时级对账主要看量级RTA调用的请求数跟媒体平台下发的竞价请求数之间有没有明显偏差。如果RTA请求量远小于应触达的竞价量说明你的RTA部署没有完全生效可能有一些流量根本没触发RTA如果RTA请求量大于预期可能是某些流量重复触发了。日级别对账看明细把RTA日志跟曝光日志、点击日志关联核心指标是RTA放行但未曝光的占比。这个占比如果异常高说明RTA放行之后又被竞价失败或素材审核卡掉了可能是出价不够或素材有问题。我在实践中踩过的一个坑对账时发现RTA拦截了某个人群但报表里这群人的曝光量还在涨。一开始以为RTA没生效排查了半天才发现是平台对RTA的缓存时间过长拦截结果要等缓存过期才真正落地。最后是靠把RTA日志和曝光日志按用户维度关联定位到拦截决策发出但曝光发生在缓存期内的时间窗口才把问题坐实。所以建议各位在一开始对接平台时就要把RTA结果缓存策略写进技术评审清单。5. 成本与收益RTA到底值不值聊完了怎么做最后一节聊一个被忽略最多的问题RTA到底值不值得做。很多团队兴致勃勃地把RTA服务搭起来一看月账单傻眼了——机器钱、带宽钱、开发维护成本一加ROI算不明白。5.1 一次RTA调用的真实成本拆解RTA的成本按调用量级算非常清晰。假设你的广告账户日均请求量是1亿次曝光机会其中经过DSP侧过滤后真正触发RTA调用的假设是1000万次我们来拆一下成本盘子。机器成本目标单机QPS 1万1000万次调用集中在高峰时段假设高峰4小时每小时250万折算每秒约700实际上需要按峰值估算而不是按均值所以日常准备单机8核16G的RTA服务节点至少8到10台按云厂商价格月成本大概在几千元到一万出头的区间。存储成本名单总量5000万条用Redis存原始ID加BloomFilter存索引内存总占用大概1到2GB按月计费用占比不大但如果你的名单膨胀到几个亿内存成本会快速上升。带宽与网络成本每次调用请求体和响应体都不大千字节级别1000万次调用大约几十GB流量成本有限。账算下来RTA本身的直接成本并不高真正贵的是开发维护和对接的人力成本。这就是为什么很多中型广告主会纠结RTA这个事前期要投入人力做服务端、做对账、做数据管道后期还要有人运维。如果只是为了过滤一个几百万量级的黑名单其实用DMP人群包就够了没必要上RTA。5.2 从ROI角度看RTA的适用场景那么什么场景下RTA才值回票价我的判断标准是两条第一名单变化频率高小时级别甚至分钟级别的变化离线人群包根本追不上第二单次无效曝光的成本足够大大到值得为拦截它付出额外技术成本。典型的高价值场景是电商广告主的已购用户过滤。双十一大促期间一个用户一天之内可能下单三次你用离线人群包过滤最早也只能隔天生效中间的曝光费用全浪费了。RTA把名单更新压缩到秒级分钟级每一分无效曝光都能拦下来这个场景下RTA的ROI极高。反过来说如果你的业务是品牌广告本来就不指望用户看了广告马上下单人群过滤的颗粒度要求也没那么细那RTA带来的增量收益就很有限。这时候不如把预算花在素材优化上。5.3 实操中的几个优化思路最后分享几个我实际用下来有效的省钱降本思路按优先级排第一加一层前置本地过滤。不要把全部流量都打到RTA服务在DSP内部先用规则引擎做粗筛高频黑名单、媒体侧屏蔽名单、预算控盘等规则本地就能判断只有拿不准的流量才走RTA。我见过一个项目90%的请求在本地拦截掉只有10%的流量走到RTAQPS压力瞬间降了一个数量级。第二RTA结果做短期缓存但缓存时间要和业务容忍度对齐。像是否已购这种分钟级感知的需求缓存设60到120秒是可以接受的像是否点击过广告这种秒级感知的需求缓存要尽量短甚至不缓存。第三先上观测模式再切拦截。前面两种响应模式的灰度思路在这里同样适用用观测成本换决策风险。我在某项目里用这个方法前期只记录了RTA决策的概率分布和命中率没有真正拦截任何流量两周之后拿到的决策日志和真实投放数据做了完整比对确认结果的精准度才正式打开拦截开关。整个过程里没有一次因误拦截造成的投放事故。RTA的实时价值往往被高估也往往被低估。被高估的一面在于它不可能帮你解决所有的人群定向问题它只是把决策时延从T1压缩到毫秒级被低估的一面在于这个时延压缩带来的预算节省效果往往比你在报表上看到的直观数据大得多。我的体会是上不上RTA不是技术实力问题而是你的业务数据是否真的值得一套实时决策体系。如果答案是肯定的那这篇文章里的链路设计、架构选型和踩坑经验大概率能帮你少走几段弯路。
1. 为什么会有第三篇RTB与RTA的边界问题还远没解决前两篇把概念聊透了RTB实时竞价解决的是每次曝光机会怎么拍卖给谁RTA实时接口解决的是广告主在拍卖前怎么表达我要不要。原理听起来都不复杂但真到了工程落地你会发现一堆概念解释不了的问题——RTA到底放在竞价前还是竞价后调用接口超时了平台怎么处理名单同步延迟了会不会误伤预算这些才是在一线做广告技术每天要面对的事。我写这篇文章的动机很简单。两篇发出去之后后台收到不少私信问的东西不约而同地集中在同一类不是RTB和RTA什么区别这种概念题而是我们打算接RTA但不知道服务端该怎么做平台给的接口文档就一张纸返回0和1但线上老出时序问题这类实战题。所以这篇我不再重复名词解释直接把我在项目里踩过的坑、验证过的架构方案、跟不同平台对接时总结出来的规则掰开讲。这篇适合的读者大概有两类一类是广告技术岗的同学想看RTA服务端怎么从零搭起来、怎么跟RTB链路配合不翻车另一类是广告投放或增长团队的技术负责人需要判断RTA这个事值不值得做、成本到底有多大、风险在哪个环节。概念部分我会快速带过重点全部放在真正跑线上之前你必须想清楚的事。2. 一条广告请求的完整旅程从曝光机会到RTA决策要理解RTA在工程上为什么麻烦先得把它放回一条真实广告请求的完整链路里看。很多方案讨论到最后变成扯皮根本原因是参与方默认的时序不一样。2.1 链路中各参与方到底在做什么一次典型的信息流广告请求从用户端发起链路大致是这样的用户在App里刷出内容媒体前端向自家广告系统请求广告广告系统媒体侧把这次曝光机会打包成竞价请求发给自己对接的ADX交易平台ADX再把请求广播给所有参与竞价的DSPDSP拿到请求后根据广告主预设的策略决定是否出价、出多少价然后把竞价响应返回ADXADX收集所有DSP的出价选出最高价返回给媒体媒体渲染广告展示。过去没有RTA的时候DSP这一层就是广告主在程序化链条里的全部话语权。DSP内部用离线人群包、规则引擎帮你做判断这个用户在人包里出价不在人包里不出价。问题在于这份提前圈好的人和此刻必须要决策的人之间总有缝隙。用户今天下午刚在你的App里下过单晚上刷信息流又刷到你的广告离线人群包压根没更新预算白烧。RTA把决策权从离线圈选挪到了实时在线查询。DSP在收到ADX的竞价请求之后多一步操作把这次请求的用户标识、广告位信息、上下文参数打包调一次广告主自建或托管的RTA接口问一句这个用户你要不要要不要出价出多少钱RTA接口返回决策结果DSP再据此决定是否参与竞价。2.2 两种时序模式出价前调用与竞价中调用RTA在整条RTB链路里的触发时机不同平台有不同实现这是最容易被忽略的差异点。第一种叫出价前RTA也叫预竞价RTA。DSP在竞价响应发出之前先向广告主RTA发起查询。RTA说拦截DSP就不参与出价RTA说放行DSP才进入后续的出价策略计算。这种模式的好处是干净拦截的流量根本不会进入竞价环节广告主不会浪费一分钱。坏处是路径变长了DSP内部本身就有策略计算、出价预估、预算控制一堆逻辑现在前面又加了一道网络远程调用延迟压力全部压给了时间预算。第二种叫竞价中RTA也叫竞得后RTA。DSP先按默认策略正常出价如果竞拍赢了在真正向媒体下发素材之前再调一次RTA确认要不要展示。这种模式对延迟更宽容一些因为竞价还没结束之前已经过去了半程但问题在于它很尴尬——如果你已经竞下来了RTA却返回拦截那这次曝光要么硬着头皮展示违背了广告主的意图要么放弃展示媒体可能扣DSP的钱甚至影响后续竞价资格。所以很多平台实现的是混合模式核心大预算广告主用出价前RTA长尾广告主用竞得后RTA兜底。我自己对接过的几家平台绝大多数建议用出价前RTA并且会在接口文档里给你标清楚RTA超时后平台的默认行为。这个默认行为特别关键一会儿单独讲。时序模式触发位置优点缺点典型场景出价前RTADSP竞价响应前拦截彻底、不浪费出价延迟敏感、链路变长高预算品牌、效果广告主竞价中RTADSP竞得后延迟容忍度较高竞得后再拦截成本高候选广告主、素材优选2.3 时间预算怎么算留给RTA的只有20毫秒现在聊那个最现实的问题RTA调用到底有多少时间预算。媒体侧对整条广告请求的时限要求通常很苛刻从用户触发曝光到媒体拿到可渲染的广告总预算一般控制在100毫秒到200毫秒之间。你可以把它理解成一条流水线媒体前端占40毫秒ADX内部决策占20毫秒DSP竞价计算占50毫秒网络传输来回占剩下的。RTA作为DSP内部决策的一部分它从DSP侧发起到广告主RTA服务返回响应整个网络调用加业务计算的预算通常只有10到30毫秒。我在实际项目里测过一个普通的HTTP/HTTPS调用如果连接没复用光TCP建连加TLS握手就能吃掉5到15毫秒。换句话说如果你的RTA服务还在用最原始的方式每次请求现建连接那你还没开始算业务逻辑时间预算就已经烧了大半。所以RTA服务端第一个要做的事不是优化算法而是把网络链路理顺连接复用、长连接、网关直连、避开跨地域的物理距离。在这儿多说一句千万别小看GC停顿。Java写的RTA服务在高峰期一次Full GC停顿控制在50毫秒以内都算可以了但在RTA场景里你可能只有20毫秒预算一次停顿就会造成连锁超时。很多团队后来把高频判定逻辑从Java挪到C或者Go并不是因为Java写不了业务而是因为内存管理和调度上Go和C在极低延迟场景下更可控。2.4 RTA返回值不只是0和1平台接口文档里最常见的RTA返回值是1放行、0拦截。但真实业务里只靠一个0/1远远不够。我见过最实用的做法是返回一个整型枚举不同数值对应不同后续策略。比较典型的取值设计1放行按广告主默认出价策略参与竞价2放行且提高出价系数用于核心高价值人群抢量3放行但降低出价系数用于泛人群试探性出价4拦截不参与竞价5仅观察出价但结果只记录不干预灰度对照把这个枚举设计放在RTA服务端的意义在于你可以用同一套接口做灰度实验。线上先跑模式5记录RTA决策和实际大盘数据的差异确认命中率、误伤率符合预期之后再把模式切到真正的拦截或提价。我在某平台项目里就是这么做的先观测两周决策日志跟投放报表做对比发现拦截名单的曝光占比和历史人工圈选数据只差0.7个百分点才放心切了硬拦截。没有灰度模式你根本不敢直接上代码。3. RTA服务端的架构取舍与超时控制讲完请求链路接着讲你自己的RTA服务怎么搭。这一节的内容是我在多个项目里反复调整后沉淀下来的不一定是最优解但绝对是最不容易踩坑的套路。3.1 接口形态与性能目标先定指标再选协议RTA服务对外暴露的接口形态基本跟着平台方的规范走。绝大多数平台支持HTTPSJSON少数大流量平台支持HTTP/2或gRPC。如果平台给选择我的建议是优先HTTP/2或gRPC原因只有一个连接复用。普通HTTP/1.1每次请求都要建连TLS握手成本反复发生在高并发下还会触发服务器TIME_WAIT堆积。HTTP/2多路复用同一条连接可以并发多个请求连接的建立成本被摊薄到大批请求上RTA这种短请求、高并发、低延迟场景简直是为它量身定做的。性能指标上我自己用的标准线单机QPS目标做到1万以上接口延迟TP99稳定在10毫秒以内TP999尽量控制在30毫秒以内。为什么是TP99而不是平均延迟因为平均延迟在广告这个场景里没有意义你被晚返回的10%请求拖了后腿平台照样给你算超时超时率才是决定你被降级的关键指标。服务端语言选型我没有强烈的站队偏好但有一点必须承认在RTA这种纯查询、无状态服务的场景里Go和C的优势比Java明显。Java的JIT预热、内存占用和GC难以预测这三点在低延迟在线服务里都是负分项。如果你的团队只有Java背景也不是不能做只是要在JVM参数、堆内存规划和GC选择上花更多工夫。3.2 数据存储与检索全量放Redis还是本地算RTA服务要查的数据本质上是一堆名单和规则黑名单、白名单、已购人群、高频活跃人群、竞品拦截名单每份名单底下是几千万甚至上亿的用户ID。查询语义很简单给我一个用户ID告诉我他在名单里还是在名单外。最直接的实现是全量名单放RedisRTA请求进来先查Redis判断命中后返回。这个方案看起来简单但有个隐患Redis的访问延迟稳定但每多一次网络往返就在消耗你的超时预算。RTA服务到Redis的网络往返在数据中心内部一般是0.5到1毫秒听起来不多但如果你的判断链路由三段组成——查黑名单、查白名单、查频控——累计网络开销就直接逼近预算上限了。我在项目里用的是分层策略热数据放本地内存冷数据放Redis再用BloomFilter做一层确定不在名单里的快速判断。具体来说每份名单在RTA服务本地维护一个BloomFilter或者类似的有损索引请求来了先用它判断如果BloomFilter说不在名单里就直接返回放行根本不用碰Redis如果BloomFilter说可能在名单里再去Redis确认精确状态。实测下来因为绝大多数流量本来就不在名单里BloomFilter帮你过滤掉了八九成的Redis查询而且BloomFilter的误判方向可控——它只会把不在名单里的流量误判成可能在名单里绝不会把在名单里的流量漏掉。精确匹配和近似匹配的代价差异要算清楚。全量名单进本地内存几千万条用户ID大概占用几百MB到1GB内存单机上可以承受但如果你有十份名单内存就有点紧了。BloomFilter把内存占用压缩一个数量级用极小的误判成本换掉大量网络IO这笔交易非常划算。3.3 降级与熔断宁可放错不可漏投的默认方向RTA服务面向的是高并发生产环境宕机、网络抖动、代码Bug都只是时间问题。所以防的是最坏情况你的RTA服务挂了平台那边收到超时会怎么处理。这里有一个必须先想清楚的选择题RTA接口超时或不可用时平台的默认兜底行为是放行还是拦截大部分平台默认是放行也就是RTA查不到结果就按广告主愿意投来处理。对广告主来说这意味着服务不可用期间你的广告继续投放但所有过滤规则全部失效。如果你接RTA的目的是拦截已购用户、拦截竞品人群那这种情况下就是裸奔钱在不断烧但你看到的后台数据还一切正常。少数平台默认是拦截RTA不通就不投。这种兜底反过来带来问题一次网络抖动就能让你的投放量瞬间归零后面恢复的时候预算又可能激进反弹。所以降级方向不能简单地说哪个对必须结合你的业务目标。我在某电商广告主的项目里把数据分成两类处理一类是必须拦截的数据比如已购用户这类数据在RTA服务本地做了一份静态镜像即使服务异常也能用本地文件继续判断另一类是可放行的数据比如竞品拦截名单服务异常时直接放行让投放系统继续跑。这样既避免了全量失效也避免了全量停投的极端情况。熔断器的设计也要提前规划。RTA服务自身要监控两个指标RTA请求的成功率和响应延迟。如果成功率连续下跌或者TP99大面积超过平台给的超时线就要主动触发熔断让RTA快速返回默认值而不是让请求在服务里排队等待。有个细节很多文章不会提平台侧的调用超时时间一般比你自己的超时时间短。你设定RTA服务内部超时10毫秒但平台从发起请求到等待响应的超时可能是200毫秒。这中间有个差值就导致了大量平台上显示超时但你没感受到慢的诡异情况。解决办法是在每次日志里记录平台侧的竞价请求时序戳你自己统计出从平台发起到RTA收到请求的网络耗时才能定位到延迟到底出在哪个环节。4. 时序陷阱与数据一致性对账和容错那些事RTA服务本身写起来不难难的是它依赖的数据一直在变。用户在下单、在取消关注、在把广告关掉你用来决策的名单却可能还是昨天下午的镜像。这一节讲的就是数据怎么同步、同步坏了怎么兜底、线上怎么对账。4.1 名单同步的双向链路离线导入加增量消息你的RTA服务需要的数据一半在广告主业务系统里一半可能在媒体平台侧。名单同步链路通常有两段。第一段是业务数据到RTA存储。广告主的用户订单表、注册表、会员表经过ETL汇入数据仓库离线任务每天生成一次全量名单导入到RTA服务的评测库与此同时订单、退单等实时事件通过MQ发到RTA服务更新增量数据。全量覆盖保证最终一致性增量流保证时效性两者配合是标配。第二段是媒体侧的交互数据。用户在你的广告位上点了不感兴趣这个操作记录在媒体平台侧DSP当时就收到了相关事件但要把这份数据同步到广告主的RTA名单里链路可能绕上一圈。有的平台提供离线报表可以让广告主拉取屏蔽名单有的通过事件回调接口通知。这块的建设程度每家平台差别很大建议对接时先确认清楚。4.2 延迟与丢失场景下的兜底设计同步链路一长时序问题就来了。最经典的一个场景用户今天下午5点下单订单增量消息在5点03分发出RTA消费消息更新名单花了5秒但用户6点又刷到广告——按理说已购用户不该投了但名单更新其实已经完成了为什么还在投排查下来大概率不是RTA名单的问题而是媒体平台侧的缓存。很多DSP会对RTA决策结果做短期缓存同一个用户几分钟内不打第二次RTA直接用上一次的决策结果。这是为了控制RTA的QPS但副作用就是你刚更新的名单在下一次缓存过期之前不生效。这类问题不在你自己的控制范围内只能通过两种办法缓解一是跟平台约好缓存时间短期名单场景把缓存调到最短二是接受这个延迟把RTA应用在容忍分钟级延迟的场景而不是几十秒级敏感场景。消息丢失也是高发问题。增量消息队列如果出现积压或丢消息可能导致某个用户的名单状态持续错误。我建议全量快照的频次不要只做每日一次核心名单可以做到每4到6小时拉一次全量作为增量消息的兜底。全量快照任务本身占用带宽但胜在能自愈——即使增量丢了下一次全量会把状态纠正过来。4.3 决策日志与对账体系怎么搭RTA服务上线后第一件事是建对账第二件事才是调策略。没有对账体系你根本不知道RTA在线上到底做了什么。RTA服务每次决策至少要落一条日志字段包含请求ID关联竞价请求、用户ID加密脱敏后的、广告位ID、决策模型版本号、决策结果放行/拦截/提价/降级、决策耗时、当时名单版本号。这条日志本身很简单但它是对账的基础。对账分两级。小时级对账主要看量级RTA调用的请求数跟媒体平台下发的竞价请求数之间有没有明显偏差。如果RTA请求量远小于应触达的竞价量说明你的RTA部署没有完全生效可能有一些流量根本没触发RTA如果RTA请求量大于预期可能是某些流量重复触发了。日级别对账看明细把RTA日志跟曝光日志、点击日志关联核心指标是RTA放行但未曝光的占比。这个占比如果异常高说明RTA放行之后又被竞价失败或素材审核卡掉了可能是出价不够或素材有问题。我在实践中踩过的一个坑对账时发现RTA拦截了某个人群但报表里这群人的曝光量还在涨。一开始以为RTA没生效排查了半天才发现是平台对RTA的缓存时间过长拦截结果要等缓存过期才真正落地。最后是靠把RTA日志和曝光日志按用户维度关联定位到拦截决策发出但曝光发生在缓存期内的时间窗口才把问题坐实。所以建议各位在一开始对接平台时就要把RTA结果缓存策略写进技术评审清单。5. 成本与收益RTA到底值不值聊完了怎么做最后一节聊一个被忽略最多的问题RTA到底值不值得做。很多团队兴致勃勃地把RTA服务搭起来一看月账单傻眼了——机器钱、带宽钱、开发维护成本一加ROI算不明白。5.1 一次RTA调用的真实成本拆解RTA的成本按调用量级算非常清晰。假设你的广告账户日均请求量是1亿次曝光机会其中经过DSP侧过滤后真正触发RTA调用的假设是1000万次我们来拆一下成本盘子。机器成本目标单机QPS 1万1000万次调用集中在高峰时段假设高峰4小时每小时250万折算每秒约700实际上需要按峰值估算而不是按均值所以日常准备单机8核16G的RTA服务节点至少8到10台按云厂商价格月成本大概在几千元到一万出头的区间。存储成本名单总量5000万条用Redis存原始ID加BloomFilter存索引内存总占用大概1到2GB按月计费用占比不大但如果你的名单膨胀到几个亿内存成本会快速上升。带宽与网络成本每次调用请求体和响应体都不大千字节级别1000万次调用大约几十GB流量成本有限。账算下来RTA本身的直接成本并不高真正贵的是开发维护和对接的人力成本。这就是为什么很多中型广告主会纠结RTA这个事前期要投入人力做服务端、做对账、做数据管道后期还要有人运维。如果只是为了过滤一个几百万量级的黑名单其实用DMP人群包就够了没必要上RTA。5.2 从ROI角度看RTA的适用场景那么什么场景下RTA才值回票价我的判断标准是两条第一名单变化频率高小时级别甚至分钟级别的变化离线人群包根本追不上第二单次无效曝光的成本足够大大到值得为拦截它付出额外技术成本。典型的高价值场景是电商广告主的已购用户过滤。双十一大促期间一个用户一天之内可能下单三次你用离线人群包过滤最早也只能隔天生效中间的曝光费用全浪费了。RTA把名单更新压缩到秒级分钟级每一分无效曝光都能拦下来这个场景下RTA的ROI极高。反过来说如果你的业务是品牌广告本来就不指望用户看了广告马上下单人群过滤的颗粒度要求也没那么细那RTA带来的增量收益就很有限。这时候不如把预算花在素材优化上。5.3 实操中的几个优化思路最后分享几个我实际用下来有效的省钱降本思路按优先级排第一加一层前置本地过滤。不要把全部流量都打到RTA服务在DSP内部先用规则引擎做粗筛高频黑名单、媒体侧屏蔽名单、预算控盘等规则本地就能判断只有拿不准的流量才走RTA。我见过一个项目90%的请求在本地拦截掉只有10%的流量走到RTAQPS压力瞬间降了一个数量级。第二RTA结果做短期缓存但缓存时间要和业务容忍度对齐。像是否已购这种分钟级感知的需求缓存设60到120秒是可以接受的像是否点击过广告这种秒级感知的需求缓存要尽量短甚至不缓存。第三先上观测模式再切拦截。前面两种响应模式的灰度思路在这里同样适用用观测成本换决策风险。我在某项目里用这个方法前期只记录了RTA决策的概率分布和命中率没有真正拦截任何流量两周之后拿到的决策日志和真实投放数据做了完整比对确认结果的精准度才正式打开拦截开关。整个过程里没有一次因误拦截造成的投放事故。RTA的实时价值往往被高估也往往被低估。被高估的一面在于它不可能帮你解决所有的人群定向问题它只是把决策时延从T1压缩到毫秒级被低估的一面在于这个时延压缩带来的预算节省效果往往比你在报表上看到的直观数据大得多。我的体会是上不上RTA不是技术实力问题而是你的业务数据是否真的值得一套实时决策体系。如果答案是肯定的那这篇文章里的链路设计、架构选型和踩坑经验大概率能帮你少走几段弯路。
