Twitter廣告平臺(tái)實(shí)時(shí)計(jì)費(fèi)系統(tǒng)的架構(gòu)增強(qiáng)之道,twitter廣告點(diǎn)擊費(fèi)用-ESG跨境

Twitter廣告平臺(tái)實(shí)時(shí)計(jì)費(fèi)系統(tǒng)的架構(gòu)增強(qiáng)之道,twitter廣告點(diǎn)擊費(fèi)用

Twitter廣告平臺(tái)實(shí)時(shí)計(jì)費(fèi)系統(tǒng)的架構(gòu)增強(qiáng)之道

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

背景簡(jiǎn)述

在深入研究超支是如何發(fā)生前，先來(lái)了解一下我們的廣告系統(tǒng)是如何提供廣告服務(wù)的。下面是我們廣告服務(wù)管道的高級(jí)架構(gòu)圖：

支出緩存（Spend Cache）——一個(gè)分布式緩存服務(wù)，可以跟蹤每個(gè)廣告活動(dòng)的當(dāng)前預(yù)算支出。

實(shí)時(shí)廣告支出計(jì)數(shù)器(Live Spend Counter，LSC)——一個(gè)基于 Apache Heron 的服務(wù)，負(fù)責(zé)聚合廣告活動(dòng)并更新支出緩存。

廣告回調(diào)（Ads Callback）——處理用戶(hù)瀏覽事件的管道，為事件添加上下文信息，并將它們發(fā)國(guó)際快遞 LSC。

廣告服務(wù)器（Ad Server）——在處理請(qǐng)求時(shí)，決定是否應(yīng)該從廣告支出緩存中獲取當(dāng)前活動(dòng)的支出。需要注意的是，這里所說(shuō)的廣告服務(wù)器包括了向用戶(hù)提供廣告的多種服務(wù)。

當(dāng)用戶(hù)在 Twitter 上瀏覽廣告時(shí)，我們會(huì)向廣告回調(diào)管道發(fā)快遞一個(gè)事件。一旦活動(dòng)支出計(jì)數(shù)器收到這個(gè)事件，它將計(jì)算活動(dòng)的總支出，并在支出緩存中更新活動(dòng)的支出。對(duì)于每個(gè)傳入的請(qǐng)求，廣告服務(wù)器管道都會(huì)查詢(xún)支出緩存，以便獲得活動(dòng)的當(dāng)前支出，并根據(jù)剩余的預(yù)算確定是否繼續(xù)提供服務(wù)。

廣告預(yù)算超支

因?yàn)槲覀兲幚淼膹V告活動(dòng)的規(guī)模比較大(數(shù)據(jù)中心每秒有數(shù)以百萬(wàn)計(jì)的廣告瀏覽事件)，所以延遲或硬件故障隨時(shí)都可能在我們的系統(tǒng)中發(fā)生。如果支出緩存沒(méi)有更新最新的活動(dòng)支出，廣告服務(wù)器就會(huì)獲取到陳舊的信息，并繼續(xù)為已經(jīng)達(dá)到預(yù)算上限的活動(dòng)提供廣告服務(wù)。我們將永遠(yuǎn)無(wú)法收取超出廣告預(yù)算的那部分費(fèi)用，導(dǎo)致 Twitter 的收入損失。

例如，假設(shè)有一個(gè)每天預(yù)算為 100 美元的廣告活動(dòng)，每一次點(diǎn)擊的價(jià)格為 0.01 美元。在沒(méi)有超支的情況下，這將為活動(dòng)創(chuàng)造每天 10000 次點(diǎn)擊的機(jī)會(huì)。

假設(shè)廣告回調(diào)管道或 LSC 出現(xiàn)故障，導(dǎo)致支出緩存沒(méi)有更新，丟失了價(jià)值 10 美元的事件，支出緩存只會(huì)報(bào)告支出為 90 美元，而實(shí)際上活動(dòng)已經(jīng)支出了 100 美元，那么該活動(dòng)將獲得額外的 1000 次免費(fèi)點(diǎn)擊機(jī)會(huì)。

跨數(shù)據(jù)中心一致性

Twitter 有多個(gè)數(shù)據(jù)中心，每個(gè)數(shù)據(jù)中心都部署了整個(gè)廣告服務(wù)管道的副本，包括廣告回調(diào)管道、實(shí)時(shí)支出計(jì)數(shù)器和支出緩存。當(dāng)用戶(hù)點(diǎn)擊廣告時(shí)，回調(diào)事件被路由到其中的一個(gè)數(shù)據(jù)中心，這個(gè)數(shù)據(jù)中心里的回調(diào)管道將負(fù)責(zé)處理這個(gè)事件。

那么，問(wèn)題就來(lái)了：每個(gè)數(shù)據(jù)中心計(jì)算的總支出只計(jì)算該數(shù)據(jù)中心接收到的事件，不包括其他數(shù)據(jù)中心的數(shù)據(jù)。由于廣告客戶(hù)的預(yù)算是跨數(shù)據(jù)中心的，這意味著每個(gè)數(shù)據(jù)中心的支出信息是不完整的，可能會(huì)少算了廣告客戶(hù)的實(shí)際支出。

為了解決這個(gè)問(wèn)題，我們給回調(diào)事件隊(duì)列添加了跨數(shù)據(jù)中心復(fù)制功能，以便讓每個(gè)數(shù)據(jù)中心都能夠處理所有的事件。這確保了每個(gè)數(shù)據(jù)中心中的支出信息是完整和準(zhǔn)確的。

單個(gè)數(shù)據(jù)中心的故障

盡管復(fù)制事件為我們帶來(lái)了更好的一致性和更準(zhǔn)確的支出信息，但系統(tǒng)的容錯(cuò)能力仍然不是很強(qiáng)。例如，每隔幾周，跨數(shù)據(jù)中心復(fù)制失敗就會(huì)導(dǎo)致支出緩存由于事件丟失或滯后而失效。通常，廣告回調(diào)管道會(huì)出現(xiàn)系統(tǒng)問(wèn)題，例如垃圾收集停頓或數(shù)據(jù)中心的不可靠網(wǎng)絡(luò)連接導(dǎo)致的事件處理延遲。由于這些問(wèn)題發(fā)生在數(shù)據(jù)中心本地，該數(shù)據(jù)中心中的 LSC 接收到的事件與延遲成正比，因此支出緩存的更新也將延遲，從而導(dǎo)致超支。

在過(guò)去，如果一個(gè)數(shù)據(jù)中心發(fā)生這些故障，我們會(huì)禁用這個(gè)數(shù)據(jù)中心的 LSC，并讓其他數(shù)據(jù)中心的 LSC 同時(shí)更新本地緩存和發(fā)生故障的數(shù)據(jù)中心的 LSC，直到出現(xiàn)滯后的廣告調(diào)管道和 LSC 重新追上來(lái)。

這種解決方法有效地避免了臨時(shí)性的超支問(wèn)題，但仍然有幾個(gè)不足的地方：

手動(dòng)切換：?jiǎn)⒂每鐢?shù)據(jù)中心寫(xiě)入是一個(gè)手動(dòng)執(zhí)行的過(guò)程，需要按一定的順序進(jìn)行多個(gè)設(shè)置更改。我們最終使用了腳本，但仍然需要一個(gè)待命工程師手動(dòng)執(zhí)行腳本。

手動(dòng)選擇數(shù)據(jù)中心：需要一個(gè)包含多個(gè)步驟的手動(dòng)執(zhí)行過(guò)程來(lái)確定哪個(gè)數(shù)據(jù)中心是健康的以及啟用跨數(shù)據(jù)中心寫(xiě)入是否安全。當(dāng)故障恢復(fù)需要回到初始配置時(shí)，必須重復(fù)類(lèi)似的過(guò)程。有時(shí)候，這個(gè)過(guò)程需要來(lái)自不同團(tuán)隊(duì)的多個(gè)待命工程師共同努力。

高運(yùn)維成本：由于管理工作區(qū)涉及了多個(gè)手動(dòng)步驟，回調(diào)基礎(chǔ)設(shè)施問(wèn)題會(huì)帶來(lái)很高的運(yùn)維成本。

跨數(shù)據(jù)中心寫(xiě)入方案

由于這種架構(gòu)存在很多問(wèn)題，我們重新設(shè)計(jì)了管道，讓它能更有彈性地應(yīng)對(duì)故障，并減少運(yùn)維人員的干預(yù)。這個(gè)解決方案有兩個(gè)主要組成部分：

跨數(shù)據(jù)中心寫(xiě)入：LSC 總是同時(shí)更新“備用”數(shù)據(jù)中心的支出緩存和本地緩存。它還會(huì)寫(xiě)入一些有關(guān)數(shù)據(jù)運(yùn)行狀況的元數(shù)據(jù)。每個(gè) LSC 實(shí)例維護(hù)兩個(gè)單獨(dú)的數(shù)據(jù)集，一個(gè)只計(jì)算本地的信息，另一個(gè)只計(jì)算來(lái)自遠(yuǎn)程實(shí)例寫(xiě)入的數(shù)據(jù)。

數(shù)據(jù)集健康檢查：在處理請(qǐng)求時(shí)，廣告服務(wù)器管道讀取兩個(gè)版本的數(shù)據(jù)，并根據(jù)哪個(gè)數(shù)據(jù)集更健康自動(dòng)選擇使用哪個(gè)版本。

在正常情況下，新解決方案的工作原理與之前的設(shè)計(jì)完全一致。但是，如果本地支出緩存落后了，廣告服務(wù)器能夠檢測(cè)到，并自動(dòng)切換到包含來(lái)自遠(yuǎn)程寫(xiě)入數(shù)據(jù)的數(shù)據(jù)集。當(dāng)本地的問(wèn)題解決之后，廣告服務(wù)器將自動(dòng)切換回本地?cái)?shù)據(jù)集。

我們?cè)趺粗滥膫€(gè)數(shù)據(jù)集更健康

我們通過(guò)常見(jiàn)的故障場(chǎng)景來(lái)決定數(shù)據(jù)集的健康情況：

延遲：當(dāng)廣告回調(diào)管道/LSC 無(wú)法及時(shí)處理大量的事件，就會(huì)出現(xiàn)延遲。事件是按照它們到達(dá)的順序處理的，所以我們更傾向于選擇包含最新事件的數(shù)據(jù)集。

丟失事件：在某些故障場(chǎng)景中，事件可能會(huì)完全丟失掉。例如，如果廣告回調(diào)管道的跨數(shù)據(jù)中心復(fù)制失敗，其中一個(gè)數(shù)據(jù)中心將丟失一些遠(yuǎn)程事件。因?yàn)樗械臄?shù)據(jù)中心都應(yīng)該處理所有的事件，所以我們應(yīng)該選擇處理了最多事件的那個(gè)數(shù)據(jù)集。

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

支出直方圖

假設(shè)我們有一個(gè)滾動(dòng)窗口，顯示每個(gè)數(shù)據(jù)中心的 LSC 在任意給定時(shí)刻正在處理的事件計(jì)數(shù)。滾動(dòng)窗口包含最近 60 秒內(nèi)每毫秒處理了多少事件的計(jì)數(shù)。當(dāng)?shù)竭_(dá)窗口的末尾，我們刪除頭部的計(jì)數(shù)，并計(jì)算后面 1 毫秒的計(jì)數(shù)。我們可以看到 LSC 在 60 秒內(nèi)處理的“事件計(jì)數(shù)”的直方圖。直方圖如下圖所示：

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

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

包含元數(shù)據(jù)的結(jié)構(gòu)體是這樣的：

復(fù)制代碼

在處理請(qǐng)求時(shí)，廣告服務(wù)器同時(shí)讀取本地和遠(yuǎn)程的數(shù)據(jù)集。它使用 SpendHistogram 根據(jù)下面描述的數(shù)據(jù)中心選擇邏輯來(lái)決定使用哪個(gè)數(shù)據(jù)集作為事實(shí)數(shù)據(jù)來(lái)源。

數(shù)據(jù)中心的選擇

選擇數(shù)據(jù)集的邏輯如下：

· 從兩個(gè)數(shù)據(jù)中心獲取 SpendHistogram。

· 首選具有最新時(shí)間戳和最高事件計(jì)數(shù)的數(shù)據(jù)集。

· 如果它們非常相近且都處于正常狀態(tài)，就首選本地?cái)?shù)據(jù)集，這樣可以避免由于小的延遲而在兩個(gè)數(shù)據(jù)中心之間來(lái)回切換。

這可以總結(jié)成以下的真值表：

x = LocalTimeStamp RemoteTimeStamp

y = LocalApproxCount RemoteApproxCount

ts = ThresholdTimeStamp

tc = ThresholdApproxCountPercent

在切換到使用來(lái)自遠(yuǎn)程數(shù)據(jù)中心的數(shù)據(jù)集之前，我們使用 ts 和 tc 來(lái)確定容忍度閾值。如果差值在閾值內(nèi)，我們會(huì)更傾向于使用本地?cái)?shù)據(jù)集。我們嘗試找到閾值，以便在不需要進(jìn)行數(shù)據(jù)中心切換的情況下盡早檢測(cè)故障。廣告服務(wù)器在處理每個(gè)請(qǐng)求時(shí)都會(huì)發(fā)生這個(gè)選擇過(guò)程，因此我們會(huì)在本地進(jìn)行緩存，每隔幾秒刷新一次，以防止頻繁的網(wǎng)絡(luò)訪問(wèn)影響整體性能。

下面是切換使用數(shù)據(jù)中心數(shù)據(jù)的可視化表示。當(dāng) DC1 的 LSC 發(fā)生故障時(shí)，會(huì)導(dǎo)致 DC1 的廣告服務(wù)器自動(dòng)選擇使用 DC2 的數(shù)據(jù)。

擴(kuò)展到多個(gè)數(shù)據(jù)中心

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

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

結(jié)論

在推出這些變更之后，我們注意到團(tuán)隊(duì)的運(yùn)維成本發(fā)生了重大變化。之前每個(gè)季度由于系統(tǒng)問(wèn)題會(huì)導(dǎo)致多次超支事件，而在過(guò)去的一年，都沒(méi)有發(fā)生此類(lèi)事件。這節(jié)省了大量的工程時(shí)間，并避免了由于基礎(chǔ)設(shè)施問(wèn)題而向廣告商發(fā)放補(bǔ)償。

通過(guò)識(shí)別系統(tǒng)健康關(guān)鍵指標(biāo)，設(shè)計(jì)出最簡(jiǎn)單的工程解決方案，并根據(jù)這些指標(biāo)自動(dòng)采取行動(dòng)，我們解決了一個(gè)影響服務(wù)管道正確性的關(guān)鍵性問(wèn)題。我們不僅構(gòu)建了一個(gè)具有容錯(cuò)能力和彈性的系統(tǒng)，而且釋放了工程資源，把它們用在更有價(jià)值的地方。

特別聲明：以上文章內(nèi)容僅代表作者本人觀點(diǎn)，不代表ESG跨境電商觀點(diǎn)或立場(chǎng)。如有關(guān)于作品內(nèi)容、版權(quán)或其它問(wèn)題請(qǐng)于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。