如何实现广告弹窗触达频率的控制？

如何实现广告弹窗触达频率的控制？

今天咱们聊聊实际工做中遇到的一个问题：

产品提出想在咱们的产品的首页作个弹窗广告，可是又不但愿用户每次进来都给用户弹窗，每一个用户天天进来只弹一次就行了。

这个如何实现？

方法一（暴力破解）

或许有些人会以为这个挺简单的，这个问题抽象出来不就是要记录用户的行为么，这个将用户的每一次行为都存在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）中打开，会出现一天弹屡次的状况，控制可能没那么精准。

没有完美的技术方案，只有最合适的技术方案。

到这里，如何控制频率的方法介绍完毕。但愿对你有所帮助。

都看到这里了，关注个公众号吧