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

来源：juejin.cn/post/7208559891605438521

👉 欢迎加入小哈的星球，你将获得: 专属的项目实战/ Java 学习路线 / 一对一提问 / 学习打卡/赠书福利

目前, 正在星球内部带小伙伴做第一个项目：全栈前后端分离博客，手摸手，后端 + 前端全栈开发，从 0 到 1 讲解每个功能点开发步骤，1v1 答疑，直到项目上线。目前已更新了125小节，累计17w+字，讲解图：805张，还在持续爆肝中.. 后续还会上新更多项目，目标是将Java领域典型的项目都整一波，如秒杀系统, 在线商城, IM即时通讯，Spring Cloud Alibaba 等等，戳我加入学习，已有380+小伙伴加入(早鸟价超低)

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

上述场景，可以简单抽象为曝光去重，就是用户看过的 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]

图片

布隆过滤器不是银弹

在小业务场景下，例如每天用户可能就看10条 feeds 左右，直接用 Set，可能会更方便。

进一步优化

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

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

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

最简单，让 Redis 抗，单机扛不住，分片还扛不住吗？分片扛不住，读写分离还扛不住吗？反正肯定能抗住。
记录1个总数量的 bloom key，分级，递增设置容量。例如起始 bf0 容量是 1000，当 bf0 满了，新建一个 bf1，容量是 10000，bf1 满了，再新建一个 bf2，容量是 10w。这种方案有两个好处，1是递进的增加 bf 容量，减少 Redis 的 key 访问次数，减轻 Redis 的压力；2是不浪费存储，大部分用户都是非活跃用户，可能看到的 feeds 量在 1w 以内，只有真正活跃的用户才会分配 10w 以上的大 bf，精准的占用存储。

图片

至此，本文就大体结束了

参考资料

[1]https://www.cnblogs.com/dragonsuc/p/10993938.html: https://www.cnblogs.com/dragonsuc/p/10993938.html[2]https://redis.io/docs/stack/bloom/%E3%80%82: https://redis.io/docs/stack/bloom/%E3%80%82

👉 欢迎加入小哈的星球，你将获得: 专属的项目实战/ Java 学习路线 / 一对一提问 / 学习打卡/赠书福利

目前, 正在星球内部带小伙伴做第一个项目：全栈前后端分离博客，手摸手，后端 + 前端全栈开发，从 0 到 1 讲解每个功能点开发步骤，1v1 答疑，直到项目上线。目前已更新了125小节，累计17w+字，讲解图：805张，还在持续爆肝中.. 后续还会上新更多项目，目标是将Java领域典型的项目都整一波，如秒杀系统, 在线商城, IM即时通讯，Spring Cloud Alibaba 等等，戳我加入学习，已有380+小伙伴加入(早鸟价超低)

1. 我的私密学习小圈子~

2. 面试官：一台服务器最大能支持多少条 TCP 连接？问倒一大片。。。

3. 阿里开源的一套国际化全流程解决方案，很不错！

4. 阿里终面：10亿数据如何快速插入MySQL？

最近面试BAT，整理一份面试资料《Java面试BATJ通关手册》，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。
获取方式：点“在看”，关注公众号并回复 Java 领取，更多内容陆续奉上。

PS：因公众号平台更改了推送规则，如果不想错过内容，记得读完点一下“在看”，加个“星标”，这样每次新文章推