如何實現廣告彈窗觸達頻率的控制？
今天我們聊聊實際工作中遇到的一個問題：
產品提出想在我們的產品的首頁做個彈窗廣告，但是又不希望使用者每次進來都給使用者彈窗，每個使用者每天進來只彈一次就好了。
這個如何實現？
方法一（暴力破解）
或許有些人會覺得這個挺簡單的，這個問題抽象出來不就是要記錄使用者的行為麼，這個將使用者的每一次行為都存在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）中開啟，會出現一天彈多次的情況，控制可能沒那麼精準。
沒有完美的技術方案，只有最合適的技術方案。
到這裡，如何控制頻率的方法介紹完畢。希望對你有所幫助。
都看到這裡了，關注個公眾號吧