RTA背景RTA投放模式在近两年逐渐兴起。目前，国内主流流量媒体方均已推出该能力。例如，腾讯/今日头条将在2020年正式推出这项服务，帮助客户进一步提升广告的精准投放效果。RTA（全称Real-TimeAPI），实时API接口，是媒体与广告商之间进行通信的一套接口服务。主要流程如下：开启后，媒体每次向用户曝光广告前，媒体会通过RTA接口询问广告主是否参与本次曝光（参与竞争）；广告主接受请求后，返回自己的数据和策略信息是否公开（参加比赛）以及进一步的决策结果；媒体根据广告主的结果信息进行优化，最终提升广告主的广告效果。RTA具有许多商业价值。比如可以根据场景进行个性化优化，也让广告主有机会参与广告曝光的决策。对于大多数客户来说，自己的隐私数据是非常宝贵的，RTA可以很好的保护隐私数据。通常情况下，广告商希望对流量进行过滤，例如圈定或排除某类人群。常规的方法是将一些定向数据打包，作为定向投放数据包上传到媒体的DMP平台。这样就无法实时更新数据，操作繁琐。最重要的是，广告商的数据将直接暴露给媒体。在很多情况下，数据是公司非常重要的资产，尤其是在数据敏感的金融行业。有些数据不方便提供，RTA可以很好的解决此类问题。RTA准入要求虽然RTA的商业价值显而易见，但媒体对广告主准入RTA的门槛较高。这里主要讨论技术门槛。由于实时参与竞争，媒体要求广告主具备一定的技术和数据能力，即面对高并发流量时能够快速做出决策并实时响应。下面列出了今日头条要求广告商满足的硬性技术指标：接口响应时间在60ms以内（包括网络和处理时间）超时率低于2%预计高点流量可以达到10w/s~12w/s其他媒体比如腾讯、快手、百度等也有类似的需求。接口的响应时间必须在60ms以内，需要能够支持高QPS。根据业务场景的部署，实际流量上限会有所不同。但是，通常媒体端有一个超时率阈值。如果不达标，媒体方会有降级最终清关机制（即关闭广告主的RTA接入通道）。ToBRTA的业务场景是通过上面RTA背景的了解，知道RTA在精准营销和不泄露隐私数据方面有很好的表现。但是RTA的准入门槛比较高。对于一些小公司来说，他们中的大多数没有获得技术的能力。而与营销SaaS平台的合作，一般采用与SaaS服务商联合建模的方式，对隐私数据不是特别敏感。通常的实现方式是：广告主在营销SaaS提供商侧上传众包，SaaS提供商提供众包分析和RTA接口实现。广告主在媒体端开户，设置竞价相关信息。将SaaS供应RTA接口配置为策略。RTA基于http-protobuf实现API接口数据交换格式。腾讯/今日头条都采用了这种方式。Protobuf序列化可以获得很好的压缩性能。合约由媒体方提供，接口服务根据合约开发。这个还是比较简单的。数据存储的选择对于数据存储的选择，其实这种场景下纯内存数据库是最合适的，但是应用实现也需要取舍。考虑到公司基础设施的完备性，选择Hbase和aerospike。首先Hbase是不行的，因为Hbase在最坏的情况下可能会有秒级的延迟。但是对于kv这种存储类型，当v比较小时，aerospike的磁盘利用率很低。考虑使用云厂商提供的kv数据库，但是被安全拒绝了，数据安全高于一切！！！最后采用自建redis集群作为数据存储层。应用架构的实现原理是基于RTA的高并发和实时业务需求。我们前期和安全/运维/DBA/基础组件进行了沟通，保证我们的基础设施在并发情况下能够有效承载。同时，一些设施在上面进行了有效的资源隔离，以防止RTA影响其他服务。经过综合考虑，我们做出了如下选择和主要设计原则：机房隔离：由于公司大部分业务都在杭州机房，为保证有效隔离，RTA应用部署在上海机房。避免阻塞/耗时操??作：可以使用异步方法；对于那些需要降低下游QPS的地方，可以通过队列、缓存、批处理等方式来优化超时降级：部分请求可能会出现毛刺，导致超时的雪崩和带宽的阻塞，超时请求必须降级。资源保护/细节优化：例如跨系统边界的调用、有风险的本地代码块等，都可以作为资源进行保护，并提供有效的降级机制。通过方法内联优化代码并降低调用成本。系统视图主要有以下服务：rta-uig：前端接收请求，后端应用负载均衡。config：分布式配置中心，业务人员为每个RTA请求制定策略是否暴露（参与竞争），并通知数据变化。rtaapp：rta核心服务，缓存客户配置信息，处理请求，返回竞争数据。data-trans：广告主数据处理，数据定时同步到redis集群。以下是API接口的主要处理流程：为了保证HTTP线程不被阻塞，尽量采用异步处理。而且直接依赖API的两个数据源是Redis和JVM内存，可以满足实时性要求。网络问题我们上面提到了接口的响应时间要在60ms以内，所以网络问题影响很大。其实我们的大部分时间都花在了网络上，距离的远近直接影响到网络延迟。从目前接入的一些媒体来看，从接口消耗时间来看，北京到上海大约需要30ms，上海公有云到公司机房的专线大约需要2ms。上线后，当媒体端的请求量增加时，由于网络抖动导致tcp重传，导致带宽瞬间爆满，请求全部被拒绝。更换带宽更大的设备后，问题有所缓解，但带宽成本非常昂贵。后期希望和安全部门协商，看能不能对数据的安全级别进行分级，可以把部分数据上传到公有云，让数据部署在离媒体端电脑更近的地方房间。资源保护保护和有效降解资源非常重要。保护点主要是根据业务的考虑来确定的，可以是任意的代码片段，并尽可能提供降级的手段，保证我们的主营业务不受影响。如果依赖的下游服务宕机或者GC导致进程挂起，请求必须超时降级。对于海量请求的超时处理，可以借鉴时间轮的原理，将时间复杂度控制在O(1)，大大提升性能。具体可以参考我之前的文章。关于RTASaaS的思考随着业务的发展和接入客户的增多，产品SaaS是一种趋势。SaaS将不可避免地面临多租户数据之间的隔离和数据量的快速增长。如何处理这些事情，减少提高效率，用少量的资源做更多的事情，满足各项性能指标，是一个值得思考的问题。Redis内存方面，对于存储在Redis中的业务数据，结合业务数据的特点，可以采用hash/zset存储结构来限制key的个数和长度，使用ziplist可以节省大部分内存和成本。采用二次编码的方式。整体采用哈希存储后，查询100万条记录的耗时仅增加了不到500毫秒。详见我之前的文章。在下面的需求中，需要对暴露的设备实施一些策略，限制每个设备每天到达的媒体数量，不再暴露，这取决于对设备的计数。未来多媒体互联，设备暴露请求数据总量可能高达每天数百亿，预计每天有数十亿的去重设备。结合业务特点，设计如下：设备具有并发性，必须进行原子操作，只能选择INCR命令（string、hash、zset）。媒体设备单独统计，每条媒体统计业务规则都有上限（每天10次以内）。这意味着每个计数器的最大可能计数值是确定的，即计数器所需的位数是有限的和固定的。比如Redis中整数类型使用的内部编码是int编码，对应Java中的long类型，占用8个字节。一个8字节可以拆开，适当的位数可以作为一定的媒体数。结合哈希存储后，还可以节省数倍的空间。热点数据优化由于业务的特点，我们会面临大量的数据存储需求，业务中的一条小规则可能会占用大量的存储资源。这就需要我们精心设计数据存储，寻找有效的访问结构。业务使用的数据可以分为以下两种存储：JVM本地存储：系统业务配置、业务规则策略、业务控制信息、热键、黑名单等Redis存储：策略计算需要大量不同的数据，数据量比较大，每条数据都在上亿级别。对于JVM本地存储，以热键的处理为例进行说明。热键是指媒体重复发出同一设备号的曝光请求。在业务上线初期，我们发现很多设备请求被多次发出，有的一天可达几千万次，造成处理资源浪费，需要一定的策略来处理。为此，我们设计了一种收集反馈的方式，具体过程：API实例本地LFU队列【LFU（LeastFrequentlyUsed）算法根据数据的历史访问频率淘汰数据，其核心思想是“如果数据过去被访问过多次，那么以后被访问的频率会更高。”】采集->报表->统计->反馈给API实例，如下图：总结RAT已经正常运行了一段时间，在运行过程中发现了一些问题。目前系统运行比较稳定。等到模型效果得到验证之后，就可以开始SaaS的演进了。从这个项目推进的过程中可以发现，应用机房的选择很重要，数据部署最好不要离媒体侧机房太远；尽可能去掉返回字段和响应头，节省带宽（带宽更贵）；在数据存储方面，使用内存数据库，研究存储类型的数据结构，使用合理的数据结构，节省存储成本；做好接口超时降级处理，使用高效的超时判断机制，将应用性能的损失降到最低。本文转载自微信公众号“小王哥写代码”，可通过以下二维码关注。转载本文请联系小王写代码公众号。
