刷抖音总能刷到新视频，技术如何实现？

最新推荐文章于 2024-12-05 19:58:12 发布

程序员的成长之路

最新推荐文章于 2024-12-05 19:58:12 发布

阅读量304

点赞数

文章标签： mybatis

原文链接：https://mp.weixin.qq.com/s?__biz=MzUyNDkzNzczNQ==&mid=2247544115&idx=1&sn=15a3ae83757eb76fdb662e7473885ab7&chksm=fa27d25bcd505b4dd1a38bbb50987da8d6617e0a642fa007e14964f70be0de53a1b611f9b492&scene=126&sessionid=0

版权

本文讨论了短视频推荐中如何实现曝光去重，介绍了Set方案的成本问题和BloomFilter的高效替代方案，分析了不同方法下的存储成本并指出BloomFilter在节省存储方面的优势。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

程序员的成长之路

互联网/程序员/技术/资料共享

关注

阅读本文大概需要 2.8 分钟。

来自：juejin.cn/post/7208559891605438521

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

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

1方案一：Set

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

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

不了解 Redis Set 的同学可以参考下：https://redis.io/commands/set/

这种方案的问题是，在海量用户的场景下，一是成本会很高(像 Redis 是纯内存数据库)；二是随着 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，有钱也不能这么造啊。

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

2方案二：Bloom Filter

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

不了解 Bitmap 的同学可以参考 www.cnblogs.com/dragonsuc/p…[1]

布隆过滤器介绍

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

图片

简单说下它的使用：

写入：对数据 data 进行 k 次 hash 运算(hash 函数可选择，本文不具体较少)，得到结果后，对 bit 数组相应位置置1。
检查：对数据 data 同样进行 k 次 hash 运算，得到结果后，检测 bloom bit 数组中相应位置是否全为1，如全是1，则表示该 data 存在于 bloom 中；否则，表示该数据不在 bloom 中。

结合上述描述，我们可以得出如下结论：

bloom 中存的摘要，而不是原始数据 data，所以空间占用远远低于 set 的占用。
bloom 无法删除数据，如上图示 x、y 都对 bit 数组中 bits[2] 置1了，如果删除 x，则 bits[2]为0，y判定时，也判定失败了。
bloom 无法动态扩展大小，如上图示，bit 数组是固定的，如果 bits 数组长度调整了，那么同样的 x、y hash 后的 bits 索引也会发生变化。
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 插件计算，redis.io/docs/stack/…[2]

<END>

推荐阅读：

牛逼，国产开源的远程桌面火了，只有9MB！

面试必问：为什么 String 是不可变的？

互联网初中高级大厂面试题(9个G)
内容包含Java基础、JavaWeb、MySQL性能优化、JVM、锁、百万并发、消息队列、高性能缓存、反射、Spring全家桶原理、微服务、Zookeeper......等技术栈！
⬇戳阅读原文领取！                                  朕已阅