QQ 空間社交廣告系統技術架構實踐

作者｜馮啟航 編輯｜小智 QQ 空間的在增值營收服務上探索了多年，本文將展示負責增值服務體系的後台工程師如何在眾多增值業務需求面前找到最合適的技術架構的支撐這個年入幾十億的產品，以及如何利用好大數據為增值營收帶來新的增長引擎。

註：本文整理自 QCon 2017 北京站上的演講，原題為：《QQ 空間平台百億級流量的社交廣告系統海量實踐》

空間里的廣告除了一些效果類的展示廣告外，大部分都是我們自己做的，比如有品牌類展示廣告，這是我們 QQ 空間獨立的 APP，會放一些像 OPPO 這樣的品牌廣告，還有品牌自身做的推直播、黃鑽收入的廣告，大廣告主題和內部廣告主題的問題是我們要解決的。

QQ 空間業務指標 QBOSS，取這個名字是定位於 Qzone 業務支撐系統，它每天日常有三百億左右的流量，流量訪問是很大的，QQ 空間等產品接入廣告渠道有十百個，日常峰值 40 萬每秒，性能要求高，我們的要求是整個計算耗時要在 50ms 內。

做技術架構之前，先挑一些核心功能來看。首先要建立渠道的概念，這是很規範的管理。另外作為平台性來說，防止對用戶進行騷擾，重複看過的廣告還出現這是不允許的。再是定投，不可能什麼廣告都是全可見的，這也是很多做演算法，做數據挖掘可以發揮的空間。第四，我們的客戶系統是在播放端和廣告主之間的一個橋樑，播放端不同渠道有開發訴求，廣告投放這邊廣告的一些核心投放邏輯要實現，是排期性的廣告系統。

定義秩序，中間核心是廣告，根據廣告的業務特點分了四個維度。左邊這個就是廣告位，這是很簡單的事情，針對的角色就是做廣告主的人。右邊體現的是 QQ 空間方向，體現的是產品的運營導向，防止騷擾運作等等。最上面的方向是真正用戶能夠感受到廣告體驗的，資源分為兩部分，一個是數據，比如這個圖片是什麼樣子，視頻是什麼樣子，這是素材問題。還有一個很值得的說的，對開發者來說我們給他一個展示模板的定義機制，能夠支持開發者在客戶層上面制定自己要的是什麼樣的邏輯，自己去開發。第四部分是對下面的用戶細分，廣告來了要給更合適的用戶，數據上來說就是用戶畫像和號碼包。

再講講騰訊通用的技術積累。經典的三層技術層里，接入層有 TGW WNS TSW 都使用的接入的方式，是比較線程可用的。中間這層特別 SPP 是騰訊內部最廣泛使用的多線程模型服務框架，把網路通信相關的功能都已經收歸了。還有一個同步中心，這是我們自研的一部分技術選型，這部分量級產品現在是深圳、上海、天津三地同步服務的，就涉及到數據層面同步問題，都抽象成一個服務建設出來做同步中心。還有是我們用的比較多的是 SSVR，它類似於一種隊列型的服務，但是不像大家用到的雲隊列服務，我們是一個基於本地流水的服務，這個簡單可控，實踐證明這麼多年用下來沒出什麼問題。

存儲層研究比較多，首先 CKV 是最廣泛使用的產品，CDB 是在 MySQL 上建立起來的 Cloud DB，Redis 用的也是比較多，TDW 是針對海量數據做的騰訊資料庫。左邊是一些系統或者組件，比如織雲是我們的運維門戶，L5 是做負載均衡的，羅盤是報表，因為我們廣告系統用的比較多，DC 上報是分散式海量數據上報的收集系統，神盾做推薦的。那我們搭一個海量系統還需要做什麼事情，除了設計之外，用它來湊一湊，海量系統就比較靠譜了。

整個廣告系統麻雀雖小五臟俱全，很多服務過了三年都沒法看了。我劃分了一下，在線服務有策略中心、用戶中心、數據中心，還有離線處理主要把用戶的數據處理上去。主要介紹三個核心服務。

策略中心是很雜的部門，滿足了廣告系統的中控，主要是一些邏輯。

用戶中心服務 DMP，一個部分是像左邊這樣，我們去搜集很多平台相關的活躍特性，比如你是不是黃鑽，是不是登錄活躍用戶，把這些數據建立成標籤，廣告組就可以選出標籤實現定投。還有一種是號碼包方式，騰訊內部還有很多做數據挖掘的團隊，包括數據產生，騰訊的業務實在太大了，很多的數據產生方不能都來我這裡，必須用號碼包的方式組織起來，這個用的比較廣泛。

最開始最簡單的架構就是這樣。對外服務，提供一個協議是不是這個用戶群的，是就回答 YES 不是就 NO，就是做了一個匹配邏輯，數據就很簡單，把號碼包的數據用戶的數據存進去就解決了，這是最簡單最開始的架構。

但是遇到了一些問題，一個是 DMP 要做強大，tag 數據一定要多，年齡、性別、裝扮活躍、登錄時間次數都是 tag 格式，tag 來源很多，很多的數據團隊並不一定把數據放在你這個地方，另外更新頻率也不同，就算是給你離線緩存許可權，存整個平台的數據對客戶系統來說也是很大的負擔。成本還有開發效率，做這個系統的時候人力成本有限制，不像有的廣告系統的團隊專門做 DMP，我們這裡只有一到兩個人開發做這個。還有內存存儲成本，存儲的選型只能用內存，但是內存價格太高了，那這幾百個指標要多少數據？

第一個問題，我們怎麼提高用戶畫像 tag 的建設效率。騰訊內部現在還是這樣做的，比如要做年齡和性別進來，一定數據存進來取一個名字，這樣每增加一個 tag 效率是很低的。後來我們決定，放棄這個結構，按 ID 來劃分，每增加一個 tag 增加一個 ID 是很簡單的事情，ID 針對哪些 bit 位也是比較好映射的，比如有 64 位上去，再上去就是 128 了，反正編號編好，有序列號的，每一個 tag 要新增，就分配一些地方，我新增一堆 tag 沒有工作量只需要分配協議。

還有是增加一個適配層來處理數據來源，有很多團隊有數據，但是沒有渠道擴大用戶，我們把判斷用戶的許可權開放。Adapter Server 是只要滿足協議，把邏輯寫好你自己來開發就好。

第三個問題是號碼包定投，一開始我們想的也比較簡單，存一下用戶在哪個號碼包裡面，每次訪問的時候拿這個數據判斷就行了，看起來很簡單很容易理解，但是實踐的時候會發現缺點。投放難度是很大的，廣告主投放一個五千萬或者一億的號碼包，他需要把這個號碼包所有用戶的數據都拿出來讀一遍寫一遍，一個投放操作會影響在線的服務，因為要改在線的數據，在線的容量也會受到波動，廣告主什麼時候投放號碼包也不確定，投放幾個也不知道。

很大風險是投放一個等待時間又長，並且影響你的在線服務。我們有三個地方的服務，深圳上海天津，如果你在深圳投放還要同步這個服務到上海和天津。存儲回收也比較麻煩，很多號碼包跟著廣告走的，廣告一旦下線，號碼包意義就不大了，很難回收它，你只能把這個號碼包拿出來再更新一下用戶。我們以前做過被動的更新，當用到這個用戶的時候再拿出來檢查號碼包，這是非常被動的。

解決這個問題，我們用了 QZone 自研的存儲利器，叫好友參與系統，非常適合號碼包的 topic 存儲。我們認為 topic 是個主題，號碼包就是一個主題，用了號碼包的都參與到這個主題中來，比如以前最火的 QQ 農場，你可以看到有多少個好友在玩農場，比如上千個好友都要看他是否在玩農場，這是非常大的計算量，於是我們就做了這個存儲系統，可以根據存儲系統的數據結構需求，把順序的號碼包處理成一個 Btree 樹結構，用 tmpfs 處理這些號碼包，使得每個 btree 文件就是可見的包，可視化的。我們的同步也很簡單，原來需要跨地域，現在都是可視化操作了。

數據中心服務難點，主要管理用戶的廣告反饋數據。廣告系統裡面，數據中心和其他的和 UGC 很大的功能不同是，是讀多寫多模型，比如一次廣告曝光，曝光之前需要看一下這個用戶有沒有看過這個廣告，就需要讀一次，如果覺得這個用戶能夠被曝光，就要寫一下曝光記錄，讀和寫的頻次都是很高的。比如我發表一個說說相冊，一般來說都是讀的情況很多，寫的情況相對很少。另外還是需要異地服務接入，數據同步問題也是，因為量大了，就容易堵塞通道。

數據中心服務架構剖析，每一個地區是這樣一個架構設計，首先結構上是簡單的邏輯服務， CKV 存儲曝光點擊記錄，在邏輯讀寫命令是分開部署的，代碼是一起的。另外做了旁路流水，每次寫的時候要做很多事情，比如要統計廣告的曝光點擊量、點擊率，第三方監控，在你這裡投廣告到底有沒有投放需要統計一下，這些需求是很慢的，還有自己的一些統計功能，包括還有同步操作到另外兩地都是很慢的，這個絕對不能放在在線的寫操作里，寫操作只能做關鍵操作即寫 CKV。s_server 起到了一個隊列作用，很快地接收數據值寫到本地文件里去，另外再起一套進程讀文件，按需跟通道通信，後端慢的服務也是按需服務的，只要跑得過流水產生的時間就行了。

我們在統計數據做了兩個通道，左邊是騰訊公司層面做的一個，是基於用戶維度，用戶實際曝光和點擊哪些廣告，在羅盤系統上做出一個統計報表。我們自己做了一個統計的數據，根據廣告 ID 的維度做，不想再處理很大量數據的問題，我們不關注用戶信息了，只關注廣告 ID 的質量，就可以合併寫操作，數據量、訪問量減少，很簡單的數據統計就可以把這個報表生成。兩個通道兩個邏輯，得出的數據是一致的，這個報表的數據就是很準的。

異地同步通常先對比一下通常的功能產品的模型，一般都是三地讀一地寫，比如你要看照片三地都可以看，你要發表一個照片一定要先接入到深圳，然後再同步到上海和天津。它比較簡單，要考慮時序性，如果哪個操作失敗了要重試，一定會堵塞通道。我們一定是要多讀多寫的，在你還在同步過程中，第二次請求已經過來了，比如在上海點了一個廣告，本來不會再次出現了，但是還出現了，因為數據還在深圳往上海趕的路上。所以需要同步起來，三地寫、三地讀就要建六個通道，比一般的產品同步量會大很多，因為它強調的是一致性和時序性。

根據這個我們大膽做了一個不做堵塞通道的同步邏輯，我們敢這麼做，而且我們只同步一些信息，比如我在深圳點了一個廣告，我並不告訴你深圳存的是什麼，上海同步的是什麼，只告訴增量信息，因為很多渠道的接觸方式也不一樣，最後上海天津的存儲容量都不一樣。這樣做，假如通道有一些故障會形成三個孤島，最大的問題是假如用戶在上海點了個廣告，下一次請求他又去深圳了，這個廣告他又看到了，這種情況下，我們大膽地嘗試不用考慮這個問題，實際驗證一下，這樣的用戶按我們的統計，一天影響量才萬分之五，我們就不這麼糾結，這是比較有特點的異地服務。

平台海量服務運營能力，一是監控能力，介面級別監控，實實在在統計成功率和延時，用戶端監控，真正看廣告拉出來的延時，還有廣告數據監控，廣告有沒有按時出現，點擊率是否符合預期。二是服務質量容量，服務質量就是個容量問題，容量夠了質量就好，容量不夠質量就不好。容量怎麼來？這是廣告系統會遇到的問題，廣告計算的負載率會徒增，特別是平台類型的廣告系統，不像效果性廣告可以保持平穩的廣告輸出量，我們這兒不一樣，比如有一些廣告對你的系統有一個徒增或突降的狀況。

每個廣告的計算量都不一樣，我們能做的事情，按照雲計算的彈性能力來做這個事情，現在的情況下保持很好的服務質量還是有難度。至少對未來要承擔的負債有一個大約的預警，你就要有模型去算，因為廣告主都會有提前量，比如下午的廣告上午就投了，不會馬上生效，總有一個時間去檢測負載是否足夠。

還有是做高效能，就留個 5 倍、8 倍的 buffer，你留多了運維就壓力很大，需要提高單機性能，我們一些監測的數據不會在伺服器里編解碼，除了廣告分析數據，都是些 UDP 的協議，盡量簡化這個邏輯操作。還有各種分離部署減少毛刺，比如數據中心讀和寫以及回收等等，一定不是分離的，為了避免有些廣告突然間量上來，有一些操作會帶來代價，平均下來三個九、四個九的成功率沒問題，但是偶爾就是幾分鐘這樣。

容災，我們不會在單機上存一些跟用戶路由相關信息，除非某個機器掛了，做負載均衡覆蓋掉就可以了。包括設備管理，把高優先順序、低優先順序的設備分配管理，針對性做一些工作。支持城市級別容災，這是經過像天津大爆炸一樣的檢驗。還有是細節，所謂容災，在一些很關鍵的地方都是可以覆蓋住的，但是把你弄死的都是一些細節，重在細節，找短板。

再講一下廣告系統 ROI 優化之路，這是我們走過的彎路。走 ROI 就是推薦演算法，包括和騰訊內部合作做一些事情，做完之後可以看看我們做的一些事情。首先在 ROI 優化前先要找准自己的瓶頸，我們做推薦演算法，量級並不大，因為都是大業務的需求，可能廣告里就五個、六個，不大於十個的廣告，但是效果是很大的，甚至會經過初選、細選，複雜度都不一樣，真的可以做到千人千面。需求量也不穩定，但是廣告質量是可控的，因為廣告主離我們比較近，我們了解他們的需求。

做了三種嘗試。第一種是最開始走的彎路，有用戶進來通過各種方式查數據，查在線的優化，會發現就算你知道用戶喜歡哪一類廣告，但是現在的庫存裡面沒有這類廣告，你沒辦法的。第二種方式，同樣一個項目廣告通過更多渠道去做，可能這個廣告的用戶群並沒有在這個渠道上投，他去了另外一個渠道也可以做，對於廣告主來說投放的代價是很大的，因為每個投放會帶來開發成本和投放成本增加，每個渠道都是不一樣的。

第三種是非常有用的方式，還是渠道給你，但是你不能再用一個廣告了，必須要設計多個廣告進來自己跟自己競爭，不同點在於廣告 A 投的是這個用戶群，廣告 B 投的是另外的用戶群。讓用戶投票，二三十分鐘就可以得出每個廣告的點擊率，讓點擊率高的廣告滲透下來，起到廣告主和用戶間的溝通橋樑，你做的工作好壞用戶會給你反饋，這個是刺激到廣告主要去新做一個廣告。

ROI 另外一些很重要的功能點就是負反饋。比如有的人看廣告七次都不會點進來，你給他投放再多次他也不會點，他選擇性地忽視了，這部分人群不要給他出廣告，對他來說體驗也好了，對我們來說收益上也沒什麼損失。還有是頻率限制，流量出來后並不是馬上消耗完，平穩地在一天或者更多天消耗完。深圳發現一個好處，第三方投放的時候，因為他們往往不太知道流量，等到網站頂住了的時候，流量消耗完了，廣告主不知道我們 Qzone 的流量有多厲害，但他肯定知道系統能頂多少量，讓我們給他頻率限制住。

還提供一個工具叫 QBOSS 人群分析統計，你投完廣告之後我們會分析廣告投放地好還是不好，選一組特徵值，曝光人群里占特徵值比例有多少，點擊人群佔百分比有多少，如果兩個持平了，可能說這個在廣告受眾里不是很明顯的東西，如果點擊比例高於曝光的比例，這就是很正向的事情，你後續投這類廣告的時候就要優先投這部分人群。我們提供的只是一種工具，一個渠道讓你做個正負的反饋，廣告主的優化必須是你自己想辦法做的事情，做的好就是百分之四百，做的不好還是百分之十幾。

整個客戶層還有很多體現騰訊海量服務價值觀的東西，比如動態運營、全網調度等等，都在用，我不再贅述。

最後講點心得，技術價值一定要體現在業務上面，我們開始做的廣告系統，比如三大系統聽起來很樸素，但是能解決業務問題就是一個好的東西。還有做職責識別，我們把一個廣告系統分成一個大的方向，每個大的方向有它的職責問題，抽象一下也就能滿足大系統小做，把一個複雜問題簡單化，比如用戶中心只需要判斷這個用戶是不是用戶群的，別的問題都不用管。

再是抽象一個層，可以解決很多需求問題，有些 tag 的識別是非常特殊的，但抽象一個層往往能解決很多複雜問題。善於在存儲上做性能提升例如 redis 的成功，邏輯很簡單，性能也非常好，包括剛才介紹的好友參與系統都能很快解決問題。

低成本，一上來內存做的成本高，可能考慮到其他的存儲介質，看看有沒有一些協議壓縮等等，很多技巧大家都會掌握，但是我建議大家還是從業務角度上考慮問題，可能給你帶來的是上十倍、百倍的成本節約。盡量做無狀態的服務，能夠保證你的負載均衡、一致性，一旦有狀態真的要悲劇了。還有各種部署的分離，在一些小流量系統里這個有點繞，但是在海量系統里這個還是很有必要的。我們所有的架構設計都是依賴自己的數據經驗的，但是在你上線后一定要通過數據驗證它。做異地同步的問題也是，上線後到底少到什麼程度，才能讓這個架構繼續工作。

作者介紹

馮啟航，2010 年畢業於四川大學加入騰訊，負責 QQ 空間功能後台開發工作。負責建設了社交平台基礎增值會員體系、個性化特權業務、營收廣告系統、營銷活動平台等海量服務。技術上踐行海量服務之道和敏捷開發的結合，喜歡做技術驅動型的工作，挖掘技術在業務上的價值體現。2016 年主導了空間寵物 AI 機器人聊天項目，在人工智慧領域從新開始。追求團隊把演算法和工程有機結合在一起，目標為導向讓機器學習、人工智慧真正走入應用場景。