廣告系統主要解決一個問題：在給定展示場景、使用者的情況下，返回收益最大化的廣告。下圖是一個廣告系統最簡單的架構圖。其中，Router，檢索模組，排序模組一般稱為廣告系統的核心。同時，與之輔助的至少包含三大系統：特徵計算系統，計費系統，投放系統。

先介紹一下三個輔助系統的主要功能：

• 特徵計算系統：實時計算廣告展示環境 (網頁，APP) 的特徵，使用者的特徵。並提供實時查詢功能。

• 計費系統：實時處理廣告的展現 (CPM)、點選 (CPC)、轉化 (CPA)資料，並計算廣告的剩餘預算。需要包括反作弊功能。

• 投放系統：供廣告主使用，設定廣告的基本資訊和定向條件。

核心部分包含了三個模組：

• Router：對外提供HTTP服務。接收請求後，依次與特徵計算系統、檢索模組、排序模組互動，最後返回廣告。

• 檢索模組：檢索模組主要解決相關性問題。首先，根據廣告主設定的定向條件篩選出本次請求能否返回的廣告；然後，按多種定向策略篩選出與本次請求最相關的若干個廣告。

• 排序模組：排序模組主要解決收益最大化的問題。通用的排序標準是eCPM。以CPC廣告系統為例，eCPM=eCTR*CPC，CPC是廣告主設定的，排序模組的核心就是使預估的eCTR儘可能地接近實際CTR。

本文討論檢索模組的架構設計。在檢索模組中使用的資料一般可以分為三類：

1. 廣告本身的資訊。例如ID，標題，描述，出價，投放時間，預算餘額等。

2. 廣告的定向資料。例如國家，裝置，人群等。

3. 各個定向策略使用的內部資料。例如，預先計算出的各個廣告的特徵，人群的興趣點擴充資料等。

同樣，討論架構先說業務特點。

1. 大型廣告系統中，單機的瓶頸首先出現在記憶體上，通常記憶體的使用率在80%以上，只剩餘20%的記憶體空間實際上是非常危險的，後文中會闡述原因。在使用的記憶體中，可以假定70%是廣告資料，30%是各策略使用的內部資料。

2. 資料的更新量佔資料總量的比例很小，一般更新量會比總量少兩個數量級。

3. 資料存在熱點。例如，一些熱門搜尋詞會被大量廣告主購買，一些熱門的人群也會被廣告主大量購買。

帶著這些前提，接下來討論檢索模組的幾個主要問題。

• 冷啟動

檢索模組在提供服務前，需要將最新的廣告資料和策略資料載入到記憶體中。假定檢索模組使用的是記憶體為64G的機器，按記憶體使用率80%計算，系統啟動的時候需要把50G的資料載入到記憶體，可以想象這是一個耗時很長的操作。另外，廣告系統一般都包含正排索引和倒排索引兩種資料，倒排索引是根據正排索引建立的，所以系統啟動的時候不僅僅是載入資料，還存在計算的過程，當然，在不存在指標的情況下，倒排索引也可以預先計算好，可以減少啟動時間。

全量與增量。因為廣告資料是實時在變化的，所以一般的方案是定期對資料庫做快照，並記錄下時間點。系統啟動時，載入最新的一個快照的資料，並且載入完所有該快照生成時間之後的所有更新，才可以對外提供服務。快照一般稱為全量，更新一般稱為增量。另外，這裡說的時間，不一定是真實的時間，也可以是邏輯時間。例如，建立一個高可用服務，對外提供始終自增的id，每一條資料更新都關聯一個唯一的id，做快照的時候，快照的id就是最新一條記錄的id。

預生成索引檔案。資料庫的快照一般是以文字檔案的形式儲存的。但是，系統在啟動的時候處理文字檔案，是非常耗時的。所以一般會使用一臺單獨的機器預先載入快照檔案，將資料轉換為與檢索模組相同的二進位制的格式，再dump到二進位制檔案中，這樣檢索模組啟動的時候直接載入二進位制檔案，可以達到很好的效能。注意，為了提高載入資料的效率，二進位制資料往往沒有經過任何序列化，因此建立索引的服務必須使用和檢索模組同樣的作業系統和配置。

• 記憶體資料結構設計

檢索模組使用的資料結構必須具備兩個特性：高效儲存，高效更新。

高效儲存是指如何使用盡可能小的記憶體空間儲存給定的資料。因此工程師需要對記憶體進行精確的控制（記憶體中的資料排列，分配和釋放），這也是為什麼大多數對記憶體要求嚴格的系統都使用C/C++開發的原因（無意引起語言之爭）。位操作在檢索模組中很常見，同時在設計結構體時，要充分考慮資料對齊（可參考的資料很多，這裡不展開）。下面重點介紹兩種常見的技術。

MemoryPool

MemoryPool是C++中常用的記憶體分配技術。大的物件或陣列往往是分配在堆上，系統中時刻都有不同的物件被建立和銷燬，如果每次都使用 malloc/free 去建立/銷燬物件，則容易造成記憶體碎片。MemoryPool的作用是，為常見的物件批量申請記憶體並預留，在系統需要建立物件的時候，從預留的記憶體中選擇一塊空間，作為新的物件，供系統初始化和使用。在銷燬物件時，並沒有實際銷燬這段記憶體空間，而是將該空間記錄在MemoryPool內部的列表中 (freelist)，在下次分配空間的時候優先從該列表分配。

常見的MemoryPool提供Create和Destroy兩個方法。

• Create即建立一個物件，如果MemoryPool中有預留的空間，則在預留的空間上分配，否則批量向系統申請空間。為了提供效率，Create方法常常返回指標而不是ID，因此MemoryPool不能移動其內部已經分配的空間。在Create方法返回後，常見的是使用Placement Constructor初始化物件。

• Destroy方法接受指標作為引數，該指標指向的記憶體地址必須是MemoryPool分配的。Destroy方法可以呼叫物件的解構函式，然後將該指標加入到freelist。

以上討論的是固定長度的MemoryPool，一般一個結構體對應一個MemoryPool。還有另一種可以儲存多種長度的物件的MemoryPool，在實際使用中比較少見，想了解這方面的設計可以參考TCMalloc。

B+樹

B樹及其變種是資料庫常用的資料結構。在記憶體-磁碟式資料庫中，類B樹的資料結構允許系統只將一部分節點載入到記憶體；在全記憶體資料庫中，類B樹的資料結構允許系統只將一部分節點的資料放入CPU的快取中。類B樹的資料主要有以下幾個優點：

1. 資料的插入和刪除效能相對穩定。

2. 在記憶體不足時，允許只將使用者查詢的索引資料全部或部分放入記憶體，提高查詢效率

3. 在執行新增和刪除操作是，只需要修改很少的節點（修改次數與Fanout有關）

4. locality性比較好，尤其在系統存在熱點資料的情況下更為明顯。

實際使用中，B+樹是比B樹更好的選擇。B+樹相比B樹，主要有兩個優點：

1. 索引和資料相分離，內部節點只儲存索引資料。記憶體中相同大小的內部節點，B+樹可以儲存更多的索引。
   

2. 葉子節點儲存了全部的資料，並且葉子節點通過指標關聯，可以方便地按順序遍歷全部或者部分資料。

B+樹在使用過程中最常見的問題是，往往由於使用方式的不當，導致節點沒有被填滿，導致巨大的記憶體浪費。

在實際實現中，B+樹的節點往往會根據Fanout預留全部的記憶體空間。以插入資料為例，在節點發生分裂時，分裂後的兩個節點都會有一定的空間未被使用，如果沒有合理地選擇插入資料的順序，會造成大量的節點未被充分使用。

例如，我們要將1到10十個數字插入到一顆空的B+樹種，如果順序插入，會得到如下的結果：

如果我們熟悉B+樹的分裂策略，再稍微仔細的計算一下插入順序，會得到不同的結果：

可以看到，順序插入使用了導致B+樹生成了八個節點，打亂一下次序只需要七個節點即可。不要小看這一個節點，當Fanout很大時，會節省非常可觀的記憶體。筆者曾經通過優化B+樹的內部組織，為單機節省了7G的記憶體。

細心的讀者可以發現，在已知全部資料的情況下，是可以計算出插入B+樹的最優方案的。前文提過，廣告系統的資料更新量相比全量會少兩個數量級，因此係統啟動結束之後，記憶體的佈局基本也就固定了，另外系統會隨著上線被頻繁重啟，因此，解決了系統啟動時候B+樹的記憶體佈局，也就解決了大部分問題。B+樹的最優插入方案留給讀者去思考。

• 資料更新

廣告的資料和策略使用的資料都需要更新，但特點不同。廣告資料對實時性要求非常高，廣告主期望在秒級更新，但一天的更新量可能只佔全量的1%不到。策略使用的資料往往需要通過大量的離線計算才能生成，往往幾個小時甚至一天才需要更新一次，但更新的量很大，可能大部分資料都需要被更新。

增量更新 (INC)

廣告資料對實時性要求高，因此一般採用增量更新的方案。回想本文開始的檢索端架構圖，投放系統和計費系統將廣告資料更新到DB，同時傳送給Message Queue，MQ中的每條資料都帶著一個表示邏輯時間的ID。在各個檢索模組的伺服器上部署一個單獨的服務從MQ訂閱資料，該服務在接收到資料後，將資料以檔案的形式持久化到磁碟。檢索模組中有一個執行緒，定期從檔案中讀取更新的增量資料，並更新到記憶體中。

難點在於，檢索模組在資料更新的同時，還需要繼續提供服務，不能出現因為更新資料而鎖住資料的情況。回想前文所說的，為了提高效率，系統中的資料都使用MemoryPool儲存，MemoryPool對外暴露的都是指標，在一次請求過程中基本都在通過指標讀取資料，很少有Copy資料的情況。因此，不能修改當前正在檢索的資料。

這裡一般使用Copy-On-Write的更新策略。即，同一個Key關聯的資料有多個版本，在更新資料時，不更新原始的資料，而是Copy一份原有資料，並在此基礎上最修改，新的資料比原有資料的版本號更大。在更新的過程中，老版本的資料依然可用；在下次查詢中，返回的是最新版本的資料，同時在合適的時機刪除老版本的資料。事實上，這個策略在目前的NoSQL系統中普遍存在。

Copy-On-Write的難點在於，如果保證Copy的資料儘量的小，最好只Copy更新的那個資料（實際上很難實現）。結合上文，讀者可以考慮如何實現一個支援多版本資料的B+樹，並且在Copy的時候儘可能少地Copy節點。

全量更新 (Reload)

策略資料對實時性要求不高，但更新的數量可能會很大，一般會使用Reload的方式進行更新。Reload更新最典型的方案是雙Buffer切換。即，將新的資料全部匯入到一個新的資料物件（Hash表）中，匯入完畢後，使用新的物件替代老的物件。

Reload方法更新的資料，最大的好處是可以假定記憶體中的資料結構是隻讀的，不會出現增量更新方式中對資料結構進行插入和刪除的操作。因此，可以使用一些更加簡單高效的資料結構。

如果使用雙Buffer切換的方式進行Reload資料，需要注意在更新的過程中，該資料的記憶體使用量會翻倍；如果多份資料同時進行Reload，會導致記憶體使用突然激增，甚至會超出系統極限，導致程式崩潰。這樣的案例在生產環境中真實的出現過，雖然系統會自動重啟，但如果大量機器同時觸發這個情況，會出現非常危險的雪崩效應。這也是前文提到的，系統的記憶體使用量在80%以上，其實是有很大的風險的原因。因此，在多份資料都使用Reload的方案更新時，要注意好控制記憶體的使用，通過一些機制避免多個任務並行。

作為大型廣告系統的核心，檢索模組面臨的問題非常複雜，實際的架構設計要緊密結合業務進行展開。沒有統一的方案，只有不同的權衡妥協。本文重點討論了檢索模組一些常見的問題和解決方案，其中有很多細節留給讀者思考。

關注我的公眾號架構叢談 | 最樸素地談架構