Twitter廣告平臺實時計費系統的架構增強之道,twitter廣告點擊費用

Twitter廣告平臺實時計費系統的架構增強之道

Twitter 是廣告商吸引受眾的一個熱門平臺。當廣告商發起一個新的廣告活動，它們會限定一個廣告預算。Twitter 的廣告服務器會檢查廣告活動的預算，以便確定是否還能繼續投放廣告。如果沒有這個檢查機制，我們可能會在廣告活動達到預算限額后繼續提供廣告服務。我們把這種情況叫作超支。超支會導致 Twitter 的收入損失(由于機會成本的增加——例如，我們本可以在那個位置顯示其他廣告)。所以，我們要建立一個可靠的系統來防止發生超支。

背景簡述

在深入研究超支是如何發生前，先來了解一下我們的廣告系統是如何提供廣告服務的。下面是我們廣告服務管道的高級架構圖：

支出緩存（Spend Cache）——一個分布式緩存服務，可以跟蹤每個廣告活動的當前預算支出。

實時廣告支出計數器(Live Spend Counter，LSC)——一個基于 Apache Heron 的服務，負責聚合廣告活動并更新支出緩存。

廣告回調（Ads Callback）——處理用戶瀏覽事件的管道，為事件添加上下文信息，并將它們發國際快遞 LSC。

廣告服務器（Ad Server）——在處理請求時，決定是否應該從廣告支出緩存中獲取當前活動的支出。需要注意的是，這里所說的廣告服務器包括了向用戶提供廣告的多種服務。

當用戶在 Twitter 上瀏覽廣告時，我們會向廣告回調管道發快遞一個事件。一旦活動支出計數器收到這個事件，它將計算活動的總支出，并在支出緩存中更新活動的支出。對于每個傳入的請求，廣告服務器管道都會查詢支出緩存，以便獲得活動的當前支出，并根據剩余的預算確定是否繼續提供服務。

廣告預算超支

因為我們處理的廣告活動的規模比較大(數據中心每秒有數以百萬計的廣告瀏覽事件)，所以延遲或硬件故障隨時都可能在我們的系統中發生。如果支出緩存沒有更新最新的活動支出，廣告服務器就會獲取到陳舊的信息，并繼續為已經達到預算上限的活動提供廣告服務。我們將永遠無法收取超出廣告預算的那部分費用，導致 Twitter 的收入損失。

例如，假設有一個每天預算為 100 美元的廣告活動，每一次點擊的價格為 0.01 美元。在沒有超支的情況下，這將為活動創造每天 10000 次點擊的機會。

假設廣告回調管道或 LSC 出現故障，導致支出緩存沒有更新，丟失了價值 10 美元的事件，支出緩存只會報告支出為 90 美元，而實際上活動已經支出了 100 美元，那么該活動將獲得額外的 1000 次免費點擊機會。

跨數據中心一致性

Twitter 有多個數據中心，每個數據中心都部署了整個廣告服務管道的副本，包括廣告回調管道、實時支出計數器和支出緩存。當用戶點擊廣告時，回調事件被路由到其中的一個數據中心，這個數據中心里的回調管道將負責處理這個事件。

那么，問題就來了：每個數據中心計算的總支出只計算該數據中心接收到的事件，不包括其他數據中心的數據。由于廣告客戶的預算是跨數據中心的，這意味著每個數據中心的支出信息是不完整的，可能會少算了廣告客戶的實際支出。

為了解決這個問題，我們給回調事件隊列添加了跨數據中心復制功能，以便讓每個數據中心都能夠處理所有的事件。這確保了每個數據中心中的支出信息是完整和準確的。

單個數據中心的故障

盡管復制事件為我們帶來了更好的一致性和更準確的支出信息，但系統的容錯能力仍然不是很強。例如，每隔幾周，跨數據中心復制失敗就會導致支出緩存由于事件丟失或滯后而失效。通常，廣告回調管道會出現系統問題，例如垃圾收集停頓或數據中心的不可靠網絡連接導致的事件處理延遲。由于這些問題發生在數據中心本地，該數據中心中的 LSC 接收到的事件與延遲成正比，因此支出緩存的更新也將延遲，從而導致超支。

在過去，如果一個數據中心發生這些故障，我們會禁用這個數據中心的 LSC，并讓其他數據中心的 LSC 同時更新本地緩存和發生故障的數據中心的 LSC，直到出現滯后的廣告調管道和 LSC 重新追上來。

這種解決方法有效地避免了臨時性的超支問題，但仍然有幾個不足的地方：

手動切換：啟用跨數據中心寫入是一個手動執行的過程，需要按一定的順序進行多個設置更改。我們最終使用了腳本，但仍然需要一個待命工程師手動執行腳本。

手動選擇數據中心：需要一個包含多個步驟的手動執行過程來確定哪個數據中心是健康的以及啟用跨數據中心寫入是否安全。當故障恢復需要回到初始配置時，必須重復類似的過程。有時候，這個過程需要來自不同團隊的多個待命工程師共同努力。

高運維成本：由于管理工作區涉及了多個手動步驟，回調基礎設施問題會帶來很高的運維成本。

跨數據中心寫入方案

由于這種架構存在很多問題，我們重新設計了管道，讓它能更有彈性地應對故障，并減少運維人員的干預。這個解決方案有兩個主要組成部分：

跨數據中心寫入：LSC 總是同時更新“備用”數據中心的支出緩存和本地緩存。它還會寫入一些有關數據運行狀況的元數據。每個 LSC 實例維護兩個單獨的數據集，一個只計算本地的信息，另一個只計算來自遠程實例寫入的數據。

數據集健康檢查：在處理請求時，廣告服務器管道讀取兩個版本的數據，并根據哪個數據集更健康自動選擇使用哪個版本。

在正常情況下，新解決方案的工作原理與之前的設計完全一致。但是，如果本地支出緩存落后了，廣告服務器能夠檢測到，并自動切換到包含來自遠程寫入數據的數據集。當本地的問題解決之后，廣告服務器將自動切換回本地數據集。

我們怎么知道哪個數據集更健康

我們通過常見的故障場景來決定數據集的健康情況：

延遲：當廣告回調管道/LSC 無法及時處理大量的事件，就會出現延遲。事件是按照它們到達的順序處理的，所以我們更傾向于選擇包含最新事件的數據集。

丟失事件：在某些故障場景中，事件可能會完全丟失掉。例如，如果廣告回調管道的跨數據中心復制失敗，其中一個數據中心將丟失一些遠程事件。因為所有的數據中心都應該處理所有的事件，所以我們應該選擇處理了最多事件的那個數據集。

為了構建一個包含這兩個因素的健康檢查機制，我們引入了支出直方圖的概念。

支出直方圖

假設我們有一個滾動窗口，顯示每個數據中心的 LSC 在任意給定時刻正在處理的事件計數。滾動窗口包含最近 60 秒內每毫秒處理了多少事件的計數。當到達窗口的末尾，我們刪除頭部的計數，并計算后面 1 毫秒的計數。我們可以看到 LSC 在 60 秒內處理的“事件計數”的直方圖。直方圖如下圖所示：

為了能夠選擇最佳的數據集(在廣告服務端)，我們利用了這個直方圖和最近的事件時間戳。LSC 將這些元數據與支出數據一起寫入支出緩存。

LSC 在寫入時不會序列化/反序列化整個直方圖。在寫入之前，它會匯總窗口中所有計數器的計數，并寫入一個聚合值。這里使用事件的近似值就足夠了，近似值可以作為這個數據中心的 LSC 總體健康狀況的信號。這是由故障的本質決定的——如果故障足夠嚴重，我們將立即看到故障的影響，計數會顯著下降。如果不是很嚴重的話，數量幾乎是一樣的。

包含元數據的結構體是這樣的：

復制代碼

在處理請求時，廣告服務器同時讀取本地和遠程的數據集。它使用 SpendHistogram 根據下面描述的數據中心選擇邏輯來決定使用哪個數據集作為事實數據來源。

數據中心的選擇

選擇數據集的邏輯如下：

· 從兩個數據中心獲取 SpendHistogram。

· 首選具有最新時間戳和最高事件計數的數據集。

· 如果它們非常相近且都處于正常狀態，就首選本地數據集，這樣可以避免由于小的延遲而在兩個數據中心之間來回切換。

這可以總結成以下的真值表：

x = LocalTimeStamp RemoteTimeStamp

y = LocalApproxCount RemoteApproxCount

ts = ThresholdTimeStamp

tc = ThresholdApproxCountPercent

在切換到使用來自遠程數據中心的數據集之前，我們使用 ts 和 tc 來確定容忍度閾值。如果差值在閾值內，我們會更傾向于使用本地數據集。我們嘗試找到閾值，以便在不需要進行數據中心切換的情況下盡早檢測故障。廣告服務器在處理每個請求時都會發生這個選擇過程，因此我們會在本地進行緩存，每隔幾秒刷新一次，以防止頻繁的網絡訪問影響整體性能。

下面是切換使用數據中心數據的可視化表示。當 DC1 的 LSC 發生故障時，會導致 DC1 的廣告服務器自動選擇使用 DC2 的數據。

擴展到多個數據中心

到目前為止，我們討論的方法只涉及兩個數據中心。通過引入跨數據中心復制因子的概念，我們可以將設計擴展到“N”個數據中心。復制因子控制每個 LSC 服務寫入的遠程數據中心的數量。在讀取數據時，我們使用了相同的邏輯，并做了一些優化，比如一次讀取(批讀取)所有必要數據，而不是分多次讀取。

例如，假設 ReplicationFactor 設置為 2，DC1 中的 LSC 將寫入到 DC1、DC2 和 DC3 的支出緩存，DC2 中的 LSC 將寫入到 DC2、DC3 和 DC4 的支出緩存，DC3 中的 LSC 將寫入到 DC3、DC4 和 DC1 的支出緩存。下圖顯示了三個數據中心的復制原理圖。在每個數據中心中，廣告服務器將讀取三個支出直方圖，并從所有這些數據中心選擇首選的數據集。根據我們的網絡和存儲約束，我們選擇 2 作為復制因子。

結論

在推出這些變更之后，我們注意到團隊的運維成本發生了重大變化。之前每個季度由于系統問題會導致多次超支事件，而在過去的一年，都沒有發生此類事件。這節省了大量的工程時間，并避免了由于基礎設施問題而向廣告商發放補償。

通過識別系統健康關鍵指標，設計出最簡單的工程解決方案，并根據這些指標自動采取行動，我們解決了一個影響服務管道正確性的關鍵性問題。我們不僅構建了一個具有容錯能力和彈性的系統，而且釋放了工程資源，把它們用在更有價值的地方。

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發表后的30日內與ESG跨境電商聯系。