如何實現廣告彈窗觸達頻率的控制？

如何實現廣告彈窗觸達頻率的控制？

今天咱們聊聊實際工做中遇到的一個問題：

產品提出想在咱們的產品的首頁作個彈窗廣告，可是又不但願用戶每次進來都給用戶彈窗，每一個用戶天天進來只彈一次就行了。

這個如何實現？

方法一（暴力破解）

或許有些人會以爲這個挺簡單的，這個問題抽象出來不就是要記錄用戶的行爲麼，這個將用戶的每一次行爲都存在redis或數據庫中，每次訪問的時候都查一下數據庫或redis判斷一下，有沒有。

以redis舉例， 若是用戶今天訪問過一次，就在Redis裏面設置一個以用戶爲維度的key。

真爽，這麼簡單，而後咱們就高高興興的玩去了，忽然某一天，運維找到你，告訴你Redis服務被擠爆了，內存不足。什麼鬼？你擡起腦殼，暗暗一想，大家的用戶有1個億用戶。

打算一個用戶佔用14個字節，14B*100000000/1024/1024=1335MB，我去，這麼一個小功能，都佔用至少1G的內存了。

方法二（Bitmap數據結構）

爲了實現這樣的小的效果，花費了1G的寶貴的Redis內存空間，顯然是划不來的。有沒有一種辦法或數據結構能夠即實現想要達到的一天一次彈窗效果，又能佔用內存最小。

這個時候，你忽然想到用戶的惟一標識符(uid),是一個從0到1個億遞增的整數。一天一次彈窗對應一個01二進制值。那可否分配一個大的數組，數組的值是boolean值，這個時候你忽然想到了Redis的Bitmap數據結構。

擡起頭算了算，一個用戶uid爲1bit位，1億用戶，大概：100000000b/8/1024/1024=11MB。到這裏，須要1個G的內存的功能如今只須要11MB就能存儲下來。

方法三(布隆過濾器)

覺得到使用bitmap解決問題就完了麼？若是如今不止有一個彈層呢，好比1000個？亦或者用戶的惟一標識符並非一個自增的整數。這個時候如何處理呢？

若是咱們願意犧牲少了的準確度，達到比較大的存儲量的話，你可能會考慮到布隆過濾器（Bloom Filter）。

在方案二中的分配一大片的bitmap基礎上，將要保存的uid或key經過若干個哈希函數映射到不一樣的bit上保存。

這種方案有個好處就幾十MB內存能夠存儲幾十億的數據去重判斷。固然壞處就是會犧牲掉少許的準確性。

方案四（前端存儲）

在上面三種方案的基礎上，咱們會發現想這些控制內存的方法，咱們想得老細胞都要死掉好多。有沒有一種簡單有效的方式呢？

若是產品不須要強制要求必須用戶一天只彈一次，那能不能將這個控制任務交給前端來控制呢，好比存儲在cookie或locolstorage中?,這樣就徹底不用擔憂存儲內存的問題了。

可是這樣有個缺點就是若是用戶在不一樣的客戶端（H5或APP）中打開，會出現一天彈屢次的狀況，控制可能沒那麼精準。

沒有完美的技術方案，只有最合適的技術方案。

到這裏，如何控制頻率的方法介紹完畢。但願對你有所幫助。

都看到這裏了，關注個公衆號吧