方案 2：數(shù)據(jù)不分片，所有的計費請求都匯聚到唯一的主 Redis，同時只讀從 Redis 可以下沉到投放服務(wù)節(jié)點上，可以減少網(wǎng)絡(luò) IO，架構(gòu)更加簡潔；但主 Redis 很容易成為性能的瓶頸；
愛奇藝廣告平臺的架構(gòu)設(shè)計與演進(jìn)之路
在實踐中我們采用了第二種 不分片 的方案。主要基于以下考慮：
在業(yè)務(wù)層面，效果廣告中有很大比率的是 CPC 廣告，而點擊日志的數(shù)量相對較少，基本不會對系統(tǒng)帶來性能壓力；對于剩下的 CPM 計費的廣告，系統(tǒng)會對計費日志進(jìn)行聚合以降低主 Redis 的壓力；因為從 Redis 是下沉到投放上的，可以不做特殊的高可用設(shè)計；主 Redis 的高可用采用 Redis Sentinel 的方案可以實現(xiàn)自動的主從切換，日志收集服務(wù)通過 Sentinel 接口獲取最新的主 Redis 節(jié)點。
在串行計費的情形下，最后一個計費請求累加之后還是可能會超出預(yù)算，這里有一個小的優(yōu)化技巧，調(diào)整最后一個計費請求的實際計費值使得消耗與預(yù)算剛好吻合。
關(guān)于超投的第二個問題 減少超投，這個問題不能徹底解決，但可以得到緩解，即降低超投不計費的比率，把庫存損失降到最低；我們的解決方案是在廣告的計費消耗接近廣告預(yù)算時執(zhí)行按概率投放，消耗越接近預(yù)算投放的概率越�。辉摲椒ㄓ幸粋�弊端，就是沒有考慮到廣告的差異性，有些廣告的 ECPM 較低，本身的投放概率就很小，曝光（或點擊）延遲的影響也就很��；針對這一點，我們又做了一次優(yōu)化：基于歷史數(shù)據(jù)估算廣告的預(yù)算消耗速度和計費延遲的情況，再利用這兩個數(shù)據(jù)來修正投放概率值。
這個方案的最大特點是實現(xiàn)簡單，在現(xiàn)有的系統(tǒng)中做簡單的開發(fā)即可實現(xiàn)，不需要增加額外的系統(tǒng)支持，不依賴于準(zhǔn)確的業(yè)務(wù)場景預(yù)測（譬如曝光率，點擊率等），而且效果也還不錯；我們還在嘗試不同的方式繼續(xù)進(jìn)行優(yōu)化超投比率，因為隨著收入的日漸增長，超投引起的收入損失還是很可觀的。
關(guān)注我：私信回復(fù)“架構(gòu)資料”獲取往期Java高級架構(gòu)資料、源碼、筆記、視頻Dubbo、Redis、設(shè)計模式、Netty、zookeeper、Spring cloud、分布式、高并發(fā)等架構(gòu)技術(shù)
關(guān)于微服務(wù)架構(gòu)改造的思考
微服務(wù)架構(gòu)現(xiàn)在已經(jīng)被業(yè)界廣泛接受和推廣實踐，我們從最初就對這個架構(gòu)思想有很強(qiáng)的認(rèn)同感； 廣告在線服務(wù)在 2014 年完成了第一版主要架構(gòu)的搭建，那時的微觀架構(gòu)（虛框表示一臺服務(wù)器）是這樣的：
愛奇藝廣告平臺的架構(gòu)設(shè)計與演進(jìn)之路
上篇：
下篇：
甘公網(wǎng)安備 62010002000030號
