如何實(shí)現(xiàn)廣告彈窗觸達(dá)頻率的控制戒努？
今天我們聊聊實(shí)際工作中遇到的一個(gè)問題：
產(chǎn)品提出想在我們的產(chǎn)品的首頁做個(gè)彈窗廣告剔交，但是又不希望用戶每次進(jìn)來都給用戶彈窗肆饶，每個(gè)用戶每天進(jìn)來只彈一次就好了。
這個(gè)如何實(shí)現(xiàn)省容？
方法一（暴力破解）
或許有些人會(huì)覺得這個(gè)挺簡單的抖拴，這個(gè)問題抽象出來不就是要記錄用戶的行為么，這個(gè)將用戶的每一次行為都存在redis或數(shù)據(jù)庫中腥椒，每次訪問的時(shí)候都查一下數(shù)據(jù)庫或redis判斷一下，有沒有候衍。
以redis舉例笼蛛， 如果用戶今天訪問過一次，就在Redis里面設(shè)置一個(gè)以用戶為維度的key蛉鹿。
真爽滨砍，這么簡單，然后我們就高高興興的玩去了妖异，突然某一天惋戏，運(yùn)維找到你，告訴你Redis服務(wù)被擠爆了他膳，內(nèi)存不足响逢。什么鬼？你抬起腦袋棕孙，暗暗一想舔亭，你們的用戶有1個(gè)億用戶些膨。
打算一個(gè)用戶占用14個(gè)字節(jié)，14B*100000000/1024/1024=1335MB钦铺，我去订雾，這么一個(gè)小功能，都占用至少1G的內(nèi)存了矛洞。
方法二（Bitmap數(shù)據(jù)結(jié)構(gòu)）
為了實(shí)現(xiàn)這樣的小的效果洼哎，花費(fèi)了1G的寶貴的Redis內(nèi)存空間，顯然是劃不來的沼本。有沒有一種辦法或數(shù)據(jù)結(jié)構(gòu)可以即實(shí)現(xiàn)想要達(dá)到的一天一次彈窗效果谱净，又能占用內(nèi)存最小。
這個(gè)時(shí)候擅威，你突然想到用戶的唯一標(biāo)識(shí)符(uid),是一個(gè)從0到1個(gè)億遞增的整數(shù)壕探。一天一次彈窗對應(yīng)一個(gè)01二進(jìn)制值。那能否分配一個(gè)大的數(shù)組郊丛，數(shù)組的值是boolean值李请，這個(gè)時(shí)候你突然想到了Redis的Bitmap數(shù)據(jù)結(jié)構(gòu)。
抬起頭算了算厉熟，一個(gè)用戶uid為1bit位导盅，1億用戶，大概：100000000b/8/1024/1024=11MB揍瑟。到這里白翻，需要1個(gè)G的內(nèi)存的功能現(xiàn)在只需要11MB就能存儲(chǔ)下來。
方法三(布隆過濾器)
以為到使用bitmap解決問題就完了么绢片？如果現(xiàn)在不止有一個(gè)彈層呢滤馍，比如1000個(gè)？亦或者用戶的唯一標(biāo)識(shí)符并不是一個(gè)自增的整數(shù)底循。這個(gè)時(shí)候如何處理呢巢株？
如果我們愿意犧牲少了的準(zhǔn)確度，達(dá)到比較大的存儲(chǔ)量的話熙涤，你可能會(huì)考慮到布隆過濾器（Bloom Filter）阁苞。
在方案二中的分配一大片的bitmap基礎(chǔ)上，將要保存的uid或key通過若干個(gè)哈希函數(shù)映射到不同的bit上保存祠挫。
這種方案有個(gè)好處就幾十MB內(nèi)存可以存儲(chǔ)幾十億的數(shù)據(jù)去重判斷那槽。當(dāng)然壞處就是會(huì)犧牲掉少量的準(zhǔn)確性。
方案四（前端存儲(chǔ)）
在上面三種方案的基礎(chǔ)上等舔，我們會(huì)發(fā)現(xiàn)想這些控制內(nèi)存的方法骚灸，我們想得老細(xì)胞都要死掉好多。有沒有一種簡單有效的方式呢软瞎？
如果產(chǎn)品不需要強(qiáng)制要求必須用戶一天只彈一次逢唤，那能不能將這個(gè)控制任務(wù)交給前端來控制呢拉讯，比如存儲(chǔ)在cookie或locolstorage中?,這樣就完全不用擔(dān)心存儲(chǔ)內(nèi)存的問題了。
但是這樣有個(gè)缺點(diǎn)就是如果用戶在不同的客戶端（H5或APP）中打開鳖藕，會(huì)出現(xiàn)一天彈多次的情況魔慷，控制可能沒那么精準(zhǔn)。
沒有完美的技術(shù)方案著恩，只有最合適的技術(shù)方案院尔。
到這里，如何控制頻率的方法介紹完畢喉誊。希望對你有所幫助邀摆。
都看到這里了，關(guān)注個(gè)公眾號(hào)吧
