rta背景
rta這種投放模式這兩年逐漸興起， 目前國内主流的流量媒體方都推出該項能力。如騰訊/頭條在2020年正式對外推出該項服務，以此來幫助客戶進一步提升廣告的精準投放效果。
rta（全稱real-time api），實時api接口，是媒體和廣告主之間通信的一套接口服務。主要流程如下：
在開通後在每次媒體将廣告給使用者曝光前，媒體将通過rta接口來詢問廣告主是否參與本次曝光（參競）；
廣告主接受請求後結合自身的資料和政策資訊傳回是否進行曝光（參競）以及進一步的決策結果；
媒體結合廣告主的結果資訊進行優選，最終提升廣告主的廣告投放效果。
rta有很多業務上的價值，比如可以針對場景做個性化的優選，也讓廣告主有了參與廣告曝光決策的機會。
對于大部分客戶來說自身的私有資料是非常珍貴的，rta能很好的保護私有資料。通常情況下廣告主想進行流量的篩選比如想圈定或者排除某一部分人群，正常做法是打包一些定向資料上傳給媒體的dmp平台作為定向投放資料包。該方式下資料無法實時更新、而且操作繁瑣，最重要的是還會将廣告主的資料直接暴露給媒體方。很多時候，資料是一個公司非常重要的資産尤其對資料比較敏感的金融行業，某些資料不友善提供出去，rta能很好地解決該類問題。
雖然rta業務價值很明顯，但媒體對可以接入rta的廣告主設有不小的門檻，這裡我們主要讨論的是技術上的門檻。
因為要進行實時的參競，媒體要求廣告主方有一定的技術和資料能力，亦即面對高并發的流量時能快速作出決策進行實時答複。下面列舉了頭條要求廣告主方必須達到的硬性技術名額：
接口響應時間在60ms内（包括網絡和處理時間）
逾時率要低于2%
預計高點流量可達10w/s~12w/s
其他媒體比如騰訊、快手、百度等的要求類似，接口的響應時間都要在60ms内，需要能支援高qps。根據業務場景投放的不同，實際的流量上限會有所不同。但通常媒體方一側都設有逾時率門檻，針對不達标的情況媒體方會有降級和最終的清退機制（即關閉廣告主的rta接入通道）
通過上面對rta背景的了解，知道了rta在精準營銷及私有資料不外洩方面有不錯的表現。但是rta的接入門檻比較高，對于一些體量較小的公司，大部分不具備技術接入的能力。而且對于和營銷saas平台的合作，一般采用和saas服務提供商聯合模組化的方式合作，對于私有資料并不是特别敏感。通常的實作方式是：
廣告主在營銷saas供應商側上傳人群包，由saas供應商提供人群分析及rta接口實作。
廣告主在媒體側開通賬号，設定競價相關的資訊。把saas供應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重傳【這裡要說明的是：媒體側做了tfo 優化，tcp 握手75ms 對方為了他們整個服務的穩定不會改，rtt 比較小，但是北京到上海的網絡抖動，勢必會造成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化演進，從這次項目推動的過程中,可以發現，應用機房的選擇非常重要，資料部署最好和媒體側機房不要間隔太遠；接口的設計方面，盡量簡約，對于不必要傳回的字段和響應頭，盡量去掉，節約帶寬（帶寬比較貴）；資料存儲方面，使用記憶體型資料庫，研究存儲類型的資料結構，利用合理的資料結構節約存儲成本；做好接口逾時降級處理，利用高效的逾時判斷機制，盡量少的減少對應用性能的損耗。