廣告主數(shù)量多，訂單量大，訂單平均預(yù)算較小，并且訂單設(shè)置會頻繁變化。
系統(tǒng)架構(gòu)
愛奇藝效果廣告于 2016 年正式上線。起步伊始，業(yè)務(wù)邏輯簡單，廣告和訂單數(shù)量較少，整體架構(gòu)相對比較簡單。為了快速完成系統(tǒng)的搭建和上線應(yīng)用，復(fù)用了品牌廣告投放平臺的架構(gòu)，并做了剪裁，系統(tǒng)架構(gòu)圖如下：
愛奇藝廣告平臺的架構(gòu)設(shè)計與演進之路
接入層 包括 QLB（iQiYi Load Balance）、Nginx 前端機，主要做流量的反向代理和整體的限流與降級功能。
流量分發(fā)層：包括策略服務(wù)和流量平臺服務(wù)；策略服務(wù)支持公司層面的策略控制和日常的運營需求；流量平臺服務(wù)主要控制流量在各投放平臺上的分配和請求邏輯，投放平臺包括品牌廣告投放平臺，效果廣告投放平臺和外部 DSP。
投放服務(wù)：前文介紹的業(yè)務(wù)邏輯都包含在這里，由單一的模塊來實現(xiàn)。
日志收集：接收曝光點擊等日志，主要完成計費、頻控和去重等業(yè)務(wù)邏輯，也是由單一的模塊來實現(xiàn)。
計費系統(tǒng)：利用 Redis 主從同步機制把訂單的實時消耗數(shù)據(jù)同步到投放服務(wù)。
頻次系統(tǒng)：使用 Couchbase 機群來做用戶數(shù)據(jù)存儲。
數(shù)據(jù)同步層：這一層涉及的數(shù)據(jù)種類很多，其中相對較重要的有兩種：業(yè)務(wù)數(shù)據(jù)和日志數(shù)據(jù)，業(yè)務(wù)數(shù)據(jù)主要包括廣告的定向、排期和預(yù)算等內(nèi)容。
我們利用業(yè)務(wù)數(shù)據(jù)做了兩方面的優(yōu)化工作：
通過業(yè)務(wù)數(shù)據(jù)分發(fā)一些對時效性要求不高的數(shù)據(jù)給到投放服務(wù)，避免了一些網(wǎng)絡(luò) IO；
在業(yè)務(wù)數(shù)據(jù)中進行空間換時間的優(yōu)化，包括生成索引及一些投放服務(wù)所需要的數(shù)據(jù)的預(yù)計算，譬如提前計算計費系統(tǒng)中的 key 值。
隨著業(yè)務(wù)增長，架構(gòu)也遇到了一些挑戰(zhàn)。
流量增長：系統(tǒng)上線之后很好地滿足了廣告主對轉(zhuǎn)化效果的要求，這個正向的效果激發(fā)了廣告主對流量的需求，為此產(chǎn)品和運營團隊不斷地開辟新的廣告位，同時愛奇藝的用戶數(shù)和流量也在持續(xù)增長，這些原因共同為效果廣告平臺帶來了巨大的流量。
廣告主數(shù)量和訂單數(shù)量增長：這個增長包括兩方面，一方面與流量增長相輔相成，相互促進；愛奇藝的優(yōu)質(zhì)流量和良好的轉(zhuǎn)化效果吸引了更多的廣告主；另一方面，由于商務(wù)政策上的原因，廣告主和訂單量在季度末會有階段性的增長。
性能問題：流量和訂單量的增長使得系統(tǒng)的負載快速增加，因為訂單是全量召回的，當訂單量增長到一定數(shù)量之后，會使得長尾請求增多，影響整體服務(wù)性能，無法通過水平擴容解決。
超投問題：由于曝光和點擊的延遲，以及投放計費環(huán)路的延遲，不可避免的存在超投問題，這也是廣告系統(tǒng)的固有問題；品牌廣告是先簽訂合同，投放量達到即可按照合同收款，超出部分不會對廣告主收費，品牌廣告預(yù)定量都很大，超投比率較小；和品牌廣告不同，效果廣告實時扣費，如果沿用品牌思路的話，超投部分會造成多余的扣費，而中小廣告主對此非常敏感，也會增加技術(shù)團隊問題分析排查工作，同時因為效果廣告的預(yù)算少，預(yù)算調(diào)整變化很快，使得超投比率要比品牌廣告大；針對效果廣告的超投問題，技術(shù)團隊要做的事情分成兩個層面，一是保證超投的部分不會計費，不給廣告主帶來損失，二是從根本上減少超投，即減少我們自己的收入損失；分別稱為 超投不計費 和 減少超投；
上篇：
下篇：
甘公網(wǎng)安備 62010002000030號
