[[433078]]

RTA背景

RTA這種投放模式這兩年逐漸興起， 目前國內主流的流量媒體方都推出該項能力。如騰訊/頭條在2020年正式對外推出該項服務，以此來幫助客戶進一步提升廣告的精準投放效果。

RTA(全稱Real-Time API)，實時API接口，是媒體和廣告主之間通信的一套接口服務。主要流程如下：

• 在開通后在每次媒體將廣告給用戶曝光前，媒體將通過RTA接口來詢問廣告主是否參與本次曝光(參競);
• 廣告主接受請求后結合自身的數據和策略信息返回是否進行曝光(參競)以及進一步的決策結果;
• 媒體結合廣告主的結果信息進行優選，最終提升廣告主的廣告投放效果。

RTA有很多業務上的價值，比如可以針對場景做個性化的優選，也讓廣告主有了參與廣告曝光決策的機會。

對于大部分客戶來說自身的私有數據是非常珍貴的，RTA能很好的保護私有數據。通常情況下廣告主想進行流量的篩選比如想圈定或者排除某一部分人群，常規做法是打包一些定向數據上傳給媒體的DMP平臺作為定向投放數據包。該方式下數據無法實時更新、而且操作繁瑣，最重要的是還會將廣告主的數據直接暴露給媒體方。很多時候，數據是一個公司非常重要的資產尤其對數據比較敏感的金融行業，某些數據不方便提供出去，RTA能很好地解決該類問題。

RTA接入要求

雖然RTA業務價值很明顯，但媒體對可以接入RTA的廣告主設有不小的門檻，這里我們主要討論的是技術上的門檻。

因為要進行實時的參競，媒體要求廣告主方有一定的技術和數據能力，亦即面對高并發的流量時能快速作出決策進行實時答復。下面列舉了頭條要求廣告主方必須達到的硬性技術指標：

• 接口響應時間在60ms內(包括網絡和處理時間)
• 超時率要低于2%
• 預計高點流量可達10w/s~12w/s

其他媒體比如騰訊、快手、百度等的要求類似，接口的響應時間都要在60ms內，需要能支持高QPS。根據業務場景投放的不同，實際的流量上限會有所不同。但通常媒體方一側都設有超時率門檻，針對不達標的情況媒體方會有降級和最終的清退機制(即關閉廣告主的RTA接入通道)

ToB RTA 的業務場景

通過上面對RTA背景的了解，知道了RTA在精準營銷及私有數據不外泄方面有不錯的表現。但是RTA的接入門檻比較高，對于一些體量較小的公司，大部分不具備技術接入的能力。而且對于和營銷SaaS平臺的合作，一般采用和SaaS服務提供商聯合建模的方式合作，對于私有數據并不是特別敏感。通常的實現方式是：

• 廣告主在營銷SaaS供應商側上傳人群包，由SaaS供應商提供人群分析及RTA接口實現。
• 廣告主在媒體側開通賬號，設置競價相關的信息。把SaaS供應RTA接口作為一個策略進行配置。

RTA實現

API接口數據交換格式是基于http-protobuf，騰訊/頭條 均采用該方式，protobuf序列化可以獲得不錯的壓縮性價比，契約由媒體方提供，按照契約進行開發提供接口服務。這個還是比較簡單的。

數據存儲的選型

對于數據存儲的選型上，這種場景下其實純內存的數據庫是最合適的，但是應用實現也需要權衡。考慮到公司基建的完善程度，在Hbase,aerospike 中進行選擇，首先Hbase是不行的，因為Hbase 最壞的情況下可能會有秒級延遲。但是對于kv這種存儲類型，在v 比較小情況下，aerospike的磁盤利用率很低?？紤]到使用云廠商提供的kv 數據庫，但是被安全進行否決，數據安全高于一切啊!!!

最終，采用了自建redis cluster 作為數據存儲層。

應用架構實現原則

基于RTA高并發且實時的業務要求，我們在前期和安全/運維/DBA/基礎組件的同學溝通，確保該并發的條件下我們的基礎設施可以有效地承載，同時在一些設施上面進行有效的資源隔離，以防止RTA影響到其他業務。

綜合考量后，我們作出如下的選擇和主要設計原則：

• 機房隔離：由于公司大部分業務在杭州機房，為了保證有效隔離，RTA應用部署在上海機房。
• 避免阻塞/耗時操作：可采用異步化手段;對于那些需要降低下游QPS的地方，可采用隊列、緩存、批量操作等手段來進行優化
• 超時降級：對于部分請求可能產生毛刺，從而導致超時帶來的雪崩以及帶寬的阻塞，必須對超時請求進行降級處理。
• 資源保護/細節優化：比如跨系統邊界的調用、有風險的本地代碼塊等，都可當成資源進行保護并提供有效的降級機制.通過優化代碼，通過方法內聯降低調用成本。

系統視圖

主要有一下幾個服務：

• rta-uig:前置接收請求，并對后端應用做負載均衡。
• config:分布式配置中心，業務人員對每個RTA請求是否曝光(參競)制訂策略，數據變更通知。
• rtaapp：rta 核心服務，緩存客戶配置信息，處理請求，返回參競數據。
• data-trans:廣告主數據處理和定時將數據同步到redis cluster。

下面是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毫秒不到。具體可以看我之前的文章。

在后面的需求中，要對曝光的設備做一些策略，限制媒體每個設備每日到達多少量后不再進行曝光，這依賴于對設備進行計數。后面會對接多個媒體，總設備曝光請求數據每日可能高達上百億次，預計每日會有數十億的去重設備量。結合業務上的的特點，設計如下：

• 設備有并發，所以一定要原子操作，只能選擇INCR命令(string、hash、zset)。
• 媒體設備分別計數，每日每個媒體計數業務規則上有上限(每日10次以內)。這意味著每個計數器可能達到的最大計數值是確定的，亦即計數器所需的位數是有限的、固定的。

例如Redis中對于整數類型采用的內部編碼是int編碼，對應Java里的long類型，占8個字節?？梢詫⒁粋€8字節拆開，取合適的bit數量作為某個媒體計數，結合hash存儲后還可以獲得數倍的空間節省。

熱點數據的優化

由于業務上的特點，我們會面臨大量的數據存儲需求，業務上一個很小的規則可能會使用很大的存儲資源。這要求我們謹慎設計數據存儲，尋找有效的存取結構。

業務上用的數據，可以歸結為如下2類存儲：

• JVM本地存儲：系統業務配置、業務規則策略、業務的控制信息、熱KEY和黑名單等
• Redis存儲：策略計算需要很多不同的數據，數據量比較大，每份數據以億計

對于JVM本地存儲，以對熱key的處理為例進行說明。熱key是指同一個設備號的曝光請求被媒體反復下發。在業務上線的初期，我們發現很多設備請求被下發很多次，有的每日可達上千萬次，浪費了處理資源，需要某種策略進行應對。為此，我們設計了收集反饋的方式，具體流程：API實例本地LFU隊列【LFU(Least Frequently Used) 算法根據數據的歷史訪問頻率來淘汰數據，其核心思想是“如果數據過去被訪問多次，那么將來被訪問的頻率也更高”。】收集 -> 上報 -> 統計 -> 反饋到API實例，如下圖所示：

總結 

RAT已經正常運行了一段時間，在運行中也發現了一些問題，目前來看系統運行比較穩定，等到模型效果驗證后可以開始SaaS化演進，從這次項目推動的過程中,可以發現，應用機房的選擇非常重要，數據部署最好和媒體側機房不要間隔太遠;接口的設計方面，盡量簡約，對于不必要返回的字段和響應頭，盡量去掉，節約帶寬(帶寬比較貴);數據存儲方面，使用內存型數據庫，研究存儲類型的數據結構，利用合理的數據結構節約存儲成本;做好接口超時降級處理，利用高效的超時判斷機制，盡量少的減少對應用性能的損耗。

本文轉載自微信公眾號「小汪哥寫代碼」，可以通過以下二維碼關注。轉載本文請聯系小汪哥寫代碼公眾號。