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