化思索 Rta 广告投放技术成功及 SaaS
RTA背景
RTA这种投放形式这两年逐渐兴起，目前国际干流的流量媒体方都推出该项才干。如腾讯/头条在2020年正式对外推出该项服务，以此来协助客户进一步优化广告的精准投放成果。
RTA(全称Real-Time API)，实时API接口，是媒体和广告主之间通讯的一套接口服务。关键流程如下：
RTA有很多业务上的价值，比如可以针对场景做共性化的优选，也让广告主有了介入广告曝光决策的时机。
关于大局部客户来说自身的私有数据是十分宝贵的，RTA能很好的包全私有数据。通常状况下广告主想启动流量的挑选比如想圈定或许扫除某一局部人群，惯例做法是打包一些定向数据上行给媒体的DMP平台作为定向投放数据包。该形式下数据不可实时升级、而且操作繁琐，最关键的是还会将广告主的数据间接泄露给媒体方。很多时刻，数据是一个公司十分关键的资产尤其对数据比拟敏感的金融行业，某些数据不繁难提供出去，RTA能很好地处置该类疑问。
RTA接入要求
只管RTA业务价值很显著，但媒体对可以接入RTA的广告主设有不小的门槛，这里咱们关键探讨的是技术上的门槛。
由于要启动实时的参竞，媒体要求广告主方有肯定的技术和数据才干，亦即面对高并发的流量时能极速作出决策启动实时回答。上方罗列了头条要求广告主方肯定到达的硬性技术目的：
其余媒体比如腾讯、快手、百度等的要求相似，接口的照应期间都要在60ms内，须要能允许高QPS。依据业务场景投放的不同，实践的流量下限会有所不同。但通常媒体方一侧都设有超时率门槛，针对不达标的状况媒体方会有升级和最终的清退机制(即封锁广告主的RTA接入通道)
ToB RTA 的业务场景
经过上方对RTA背景的了解，知道了RTA在精准营销及私有数据不外泄方面有不错的体现。然而RTA的接入门槛比拟高，关于一些体量较小的公司，大局部不具有技术接入的才干。而且关于和营销SaaS平台的协作，普通驳回和SaaS服务提供商联结建模的形式协作，关于私有数据并不是特意敏感。通常的成功形式是：
RTA成功
API接口数据替换格局是基于http-protobuf，腾讯/头条均驳回该形式，protobuf序列化可以取得不错的紧缩性价比，契约由媒体方提供，依照契约启动开发提供接口服务。这个还是比拟繁难的。
数据存储的选型
关于数据存储的选型上，这种场景下其实纯内存的数据库是最适合的，然而运行成功也须要掂量。思索到公司基建的完善水平，在Hbase,aerospike中启动选用，首先Hbase是不行的，由于Hbase 最坏的状况下或许会有秒级提前。然而关于kv这种存储类型，在v比拟小状况下，aerospike的磁盘应用率很低。思索到经常使用云厂商提供的kv 数据库，然而被安保启动否决，数据安保高于一切啊!!!
最终，驳回了自建redis cluster 作为数据存储层。
运行架构成功准则
基于RTA高并发且实时的业务要求，咱们在前期和安保/运维/DBA/基础组件的同窗沟通，确保该并发的条件下咱们的基础设备可以有效地承载，同时在一些设备上方启动有效的资源隔离，以防止RTA影响到其余业务。
综合考量后，咱们作出如下的选用和关键设计准则：
系统视图
关键有一下几个服务：
上方是API接口的关键处置流程：
为保障HTTP的线程不阻塞，尽或许优先驳回异步处置形式。而且API间接依赖的2个数据源是Redis和JVM内存，这样可以满足实时性的要求。
网络疑问
咱们上方提到接口的照应期间要在60ms以内，因此网络的疑问影响很大。
理想上咱们的期间大局部破费在网络上，距离的远近间接影响着网络时延。以目前对接的一些媒体来看，在接口消耗期间上，北京到上海大略30ms左右，上海私有云到公司机房的专线大略要2ms。在上线后，当媒体方恳求量增大时，由于网络颤抖造成tcp重传，从而造成带宽被瞬间打满，一切的恳求都被拒绝，在改换更大带宽的设备后，疑问获取缓解，然而带宽老本是十分低廉的。前期宿愿和安所有门协商，看看能不能把数据的安保等级启动分类，局部数据可以上私有云，这样可以将数据部署里媒体侧机房更近的中央。
资源包全
对资源启动包全和有效升级十分关键。包全点关键基于业务上思索来确定，可以是恣意的代码片段，并尽或许提供升级手腕，以保障咱们的主业务不受影响。假设依赖的下游服务宕机或许GC的造成进程暂停，肯定对恳求启动超时升级。对应海量恳求的超时处置，可以自创期间轮的原理，把期间复杂度控制在O(1)，大幅优化性能，详细可以参考我前面的文章。
RTA SaaS化的思索
随着业务的开展，接入客户的增多，产品SaaS化是一个趋向，SaaS化肯定面临着多租户数据之间的隔离，数据量的极速增长，怎样来处置这些事情，降本增效，应用大批的资源做更多的事情，各种性能目的也能达标，是一个值得思索的疑问。
Redis 内存方面
关于经常使用Redis存储的业务数据，结合业务上的数据特点，可以经常使用hash/zset存储结构，限度key的数量长度，经常使用ziplist，省下了大局部内存，浪费了老本。驳回二级编码的形式。全体上驳回hash存储后，查问100万条耗时，也仅仅参与了500毫秒不到。详细可以看我之前的文章。
在前面的需求中，要对曝光的设备做一些战略，限度媒体每个设备每日抵达多大批后不再启动曝光，这依赖于对设备启动计数。前面会对接多个媒体，总设备曝光恳求数据每日或许高达上百亿次，估量每日会有数十亿的去重设备量。结合业务上的的特点，设计如下：
例如Redis中关于整数类型驳回的外部编码是int编码，对应Java里的long类型，占8个字节。可以将一个8字节拆开，取适合的bit数量作为某个媒体计数，结合hash存储后还可以取得数倍的空间节俭。
热点数据的优化
由于业务上的特点，咱们会面临少量的数据存储需求，业务上一个很小的规定或许会经常使用很大的存储资源。这要求咱们审慎设计数据存储，寻觅有效的存取结构。
业务上用的数据，可以归纳为如下2类存储：
关于JVM本地存储，以对热key的处置为例启动说明。热key是指同一个设备号的曝光恳求被媒体重复下发。在业务上线的初期，咱们发现很多设备恳求被下发很屡次，有的每日可达上千万次，糜费了处置资源，须要某种战略启动应答。为此，咱们设计了搜集反应的形式，详细流程：API实例本地LFU队列【LFU(LeastFrequently Used) 算法依据数据的历史访问频率来淘汰数据，其外围理想是“假设数据过去被访问屡次，那么未来被访问的频率也更高”。】搜集 ->上报 -> 统计 -> 反应到API实例，如下图所示：
总结
RAT曾经反常运转了一段期间，在运转中也发现了一些疑问，目前来看系统运转比拟稳固，等到模型成果验证后可以开局SaaS化演进，从这次名目推进的环节中,可以发现，运行机房的选用十分关键，数据部署最好和媒体侧机房不要距离太远;接口的设计方面，尽量简洁，关于不用要前往的字段和照应头，尽量去掉，浪费带宽(带宽比拟贵);数据存储方面，经常使用内存型数据库，钻研存储类型的数据结构，应用正当的数据结构浪费存储老本;做好接口超时升级处置，应用高效的超时判别机制，尽量少的缩小对运行性能的损耗。
