当前位置: 首页 >  关注  >  正文

布隆过滤器在短视频 feeds 系统中的妙用
2023-03-12 05:20:33 腾讯云

大家平时刷抖音、视频号、快手时,几乎总能刷到最新的视频。那这里是怎么实现的呢?

上述场景,可以简单抽象为曝光去重,就是用户看过的 feeds1、feeds2、feeds3 ...... 等,如何保证在用户下次进入系统时不会再次出现呢?今天,我们就来探讨下几种实现方案吧。

方案一 :Set

这个方案简单粗暴,就是每个用户用一个集合,存储看过的所有 feedsid。每次推荐系统要出新的 feeds 时,去 set 中 check 一下是否存在,如果存在的话,就过滤掉这条 feeds。


(资料图片仅供参考)

一般来说,像是短视频推荐的场景下,对 feeds 的实时性要求相对较高,一般会使用 Redis 作为曝光打击的载体。

不了解 Redis Set 的同学可以参考下:https://redis.io/commands/set/,简而言之就是一个字典。

这种方案的问题是,在海量用户的场景下,1是成本会很高(像 Redis 是纯内存数据库);2是随着 feeds 数量越来越多,set 查询会随之变慢(像短视频的场景下,1晚上刷个上百条还是不成问题的)。

我们来简单试算一下,假设国民级 App 的日活跃用户在 3kw,每人每天平均刷 200 条视频 feeds,每条 feeds 的 id 长度为 32B。

如果以 Redis Set 的方案来计算:3kw * 200 * 32 * 1.5(Redis 数据结构自身存储) ~ 288G,每天需要消耗存储 288G,1个月呢?8.6T,1年呢?103T。以腾讯云 keewiDB 的持久内存来估计 64元/GB/月,1月成本大约 55w,有钱也不能这么造啊。

那有没有更优惠的实现方案呢?这就要说到本文的主角,布隆过滤器了。

方案二:Bloom Filter

布隆过滤器,本质上是一个高阶 Bitmap,最适合的场景就是海量数据的过滤了。

不了解 Bitmap 的同学可以参考 https://www.cnblogs.com/dragonsuc/p/10993938.html。

布隆过滤器介绍

布隆过滤器的结构如下图示:

bloom filter

简单说下它的使用:

1. 写入:对数据 data 进行 k 次 hash 运算(hash 函数可选择,本文不具体较少),得到结果后,对 bit 数组相应位置置1。

2. 检查:对数据 data 同样进行 k 次 hash 运算,得到结果后,检测 bloom bit 数组中相应位置是否全为1,如全是1,则表示该 data 存在于 bloom 中;否则,表示该数据不在 bloom 中。

结合上述描述,我们可以得出如下结论:

1. bloom 中存的摘要,而不是原始数据 data,所以空间占用远远低于 set 的占用。

2. bloom 无法删除数据,如上图示 x、y 都对 bit 数组中 bits[2] 置1了,如果删除 x,则 bits[2]为0,y判定时,也判定失败了。

3. bloom 无法动态扩展大小,如上图示,bit 数组是固定的,如果 bits 数组长度调整了,那么同样的 x、y hash 后的 bits 索引也会发生变化。

4. bloom 存在误判的可能,例如 x、y hash 后得到的 bits 数组索引都是 1、3、5,那么即使 bloom 中只添加了 x,当 y 来判定时,也会判定为存在。

误判率计算公式

这里不细究它的推导过程了,感兴趣的同学可以自行研究。

布隆过滤器实现曝光打击

由上述布隆过滤器的特性所知:必须合理选择 bloom 过滤器的规格,bloom bit 数组太小,则误判率过高;bloom bit 数组太大,则过于浪费存储。

还是以相同的条件来试算,

假设国民级 App 的日活跃用户在 3kw,每人每天平均刷 200 条视频 feeds,每条 feeds 的 id 长度为 32B。

如果以 Redis bloom 的方案来计算:400B * 3kw ~ 12G,相比 set 方案的 288G,节约了 96% 的存储成本。1月可以节约 52.8w 成本,降本增效杠杠的。

当设置 bloom 容量为 200 时,每人每天1个key,可以保证当天看到不重复的 feeds,BF 规格如下:

采用 Redis Bloom 插件计算,https://redis.io/docs/stack/bloom/。

bloom filter 规格

进一步优化

上述场景下,Bloom 大小按照 200 计算,那活跃用户呢?总有一些高活用户,每天会刷大几百条视频,这部分用户不做特殊处理的话,体验会非常差,后面总是看到重复的视频。还有就是一些特殊场景,例如业务希望用户1月内都不要看到重复的 feeds。这种,如果仅仅以每天每人作为 bloom 的 key,那么实现1个月内不重复,1个用户要查询30个 bloom,有点夸张。

Redis 虽然能抗,但假设用户刷视频的频率是 10w/s,扩散后,对 Redis 的压力就是300w/s

怎么优化呢?有几种思路。

1. 最简单,让 Redis 抗,单机扛不住,分片还扛不住吗?分片扛不住,读写分离还扛不住吗?反正肯定能抗住。

2. 记录1个总数量的 bloom key,分级,递增设置容量。例如起始 bf0 容量是 1000,当 bf0 满了,新建一个 bf1,容量是 10000,bf1 满了,再新建一个 bf2,容量是 10w。这种方案有两个好处,1是递进的增加 bf 容量,减少 Redis 的 key 访问次数,减轻 Redis 的压力;2是不浪费存储,大部分用户都是非活跃用户,可能看到的 feeds 量在 1w 以内,只有真正活跃的用户才会分配 10w 以上的大 bf,精准的占用存储。

分级 BF

至此,本文就大体结束了,后面有时间了再开一篇布谷鸟过滤器的说明,先鸽一下。

热门推荐