Feed 流系统杂谈

点击上方“芋道源码”，选择“设为星标”

管她前浪，还是后浪？

能浪的浪，才是好浪！

每天 10:33 更新文章，每天掉亿点点头发...

源码精品专栏

原创 | Java 2021 超神之路，很肝~
中文详细注释的开源项目
RPC 框架 Dubbo 源码解析
网络应用框架 Netty 源码解析
消息中间件 RocketMQ 源码解析
数据库中间件 Sharding-JDBC 和 MyCAT 源码解析
作业调度中间件 Elastic-Job 源码解析
分布式事务中间件 TCC-Transaction 源码解析
Eureka 和 Hystrix 源码解析
Java 并发源码

来源：www.cnblogs.com/Finley/

p/15391173.html

什么是 Feed 流
Feed 流的存储
持久化存储
Feed 流系统优化
- 在线推离线拉
- 分页器
- 深度分页

什么是 Feed 流

Feed 流是社交和资讯类应用中常见的一种形态，比如微博知乎的关注页、微信的订阅号和朋友圈等。Feed 流源于 RSS 订阅，用户将自己感兴趣的网站的 RSS 地址登记到 RSS 阅读器中，在阅读器里聚合成的列表就是 Feed 流。

Feed 流的本质是 M 个用户订阅了 N 个信息源形成的多对多关系，Feed 流系统需要聚合用户订阅的 N 个信息源产生的信息单元(Feed)，并按照一定顺序排列后推送给用户。

接下来我们以关注页场景为例来介绍 Feed 流的实现。

Feed 流有两种基本实现模式：

推模式：当新的 Feed 发布后，将这条内容插入到发布者所有粉丝的 Feed 流中。
拉模式：收到用户拉取Feed流请求后遍历他的关注关系，并拉取关注的人发布的内容实时聚合成 Feed 流。

两种实现方式各有优缺：

推模式的优点在于可以迅速响应用户拉取 Feed 流的请求。但是在粉丝数较多的大V发布内容时需要在他每个粉丝的Feed流中一一进行插入，会产生较大的峰值负载。由于 Feed 发布后的插入操作较多，通常需要使用 MQ 来异步地进行。
拉模式的优点在于大V发布内容时不会产生峰值负载，但是实时构建 Feed 流操作需要用户等待较多时间。

在实际应用中我们通常采取推拉结合的实现方式。在具体介绍推拉结合之前，我们先来讨论一下 Feed 流系统的存储。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro

视频教程：https://doc.iocoder.cn/video/

Feed 流的存储

Feed 流系统中需要存储的数据有 3 部分：

作者发布的 Feed 列表：这些数据需要可靠的持久化存储，通常采用 MySQL 等关系型数据库即可。因为很可能需要按照发布时间排序，若要使用 NoSQL 最好使用支持有序存储的数据库。
用户和作者之间的关注关系：同样需要可靠的持久化存储，采用 MySQL 等关系型数据库或者 KV 结构的 NoSQL 数据库均可。
用户的 Feed 流：Feed 流可以根据 Feed 数据库和关注关系构建，因此可以不做持久化存储。

最轻量的解决方案是使用 Redis 存储 Feed 流。在数据量较大 Redis 内存不够用时，也可以采用一些持久化的存储方案。

Redis 的 SortedSet 是非常适合存储 Feed 流的数据结构。一般以 Feed 的 ID 作为 SortedSet 的 member，时间戳或者热度值、推荐值作为 score 进行排序。SortedSet 保证了 Feed 不会重复，且插入过程线程安全，无论是推拉模式实现起来都非常方便。

为了避免 Redis 中缓存的 Feed 流占用过多内存，通常需要给 Feed 流设置 TTL.

Feed 的具体内容存储可以在 MySQL 中，同时在 Redis 中做一层缓存。关注关系可以存储在 MySQL 中，因为有些大V的粉丝数较多所以不推荐用 Redis 缓存。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://gitee.com/zhijiantianya/yudao-cloud

视频教程：https://doc.iocoder.cn/video/

持久化存储

一个用户的 Feed 流大小是他所有关注者发布的 Feed 数总和。在用户量较大的系统中 Feed 流数据量巨大且增长迅速，将所有 Feed 流存储在 Redis 中需要消耗巨量的内存。

在必要的时候可以利用持久化存储作多级缓存，比如：将当日活跃用户的 Feed 流数据存储在 Redis 中，当月活跃用户的 Feed 流持久化到数据库中，长期未活跃的用户则在他重新登录后使用 MySQL 中存储的关注关系重新构建 Feed 流。

因为持久化存储 Feed 流的数据库需要有较大的数据容量、较高吞吐量并且需要支持排序，所以不建议使用数据容量较小的 MySQL 或者不支持排序的 KV 数据库来存储 Feed 流数据。

作者推荐使用 Cassandra 来持久化存储 Feed 流：使用用户的 UID 作为 Partition Key, Feed 时间戳在前 Feed ID 在后，共同作为 Clustering Key 用于排序和去重。Cassandra 支持 TTL 可以用来自动清除冷数据。

另外，由于Feed 流数据属于只追加不修改与 Cassandra 使用的 LSM 结构非常契合，可以有效减少 Cassandra 进行 Compaction 的负担。

Feed 流系统优化

在线推离线拉

一个拥有 10 万粉丝的大V在发布微博时，他的粉丝中可能只有 1 千人在线。因此我们常用的优化策略是：对于在线的粉丝采用推模式，将新的 Feed 直接插入到粉丝的信息流中；对于离线的粉丝采用拉模式，在粉丝登录时遍历他的关注关系重新构建 Feed 流。

在线推的部分需要计算粉丝和在线用户的交集，然后进行插入操作。因为在线用户数和粉丝数都比较大，所以计算交集的过程需要分批进行。比如说每次查询 100 个粉丝，然后去查询这 100 个用户中有多少在线（取交集），直到遍历完粉丝列表。这个过程类似于将两个表做 join, 同样适用小表驱动大表的原则以减少取交集操作的次数, 大多数情况下使用数量较少的粉丝表作为驱动表。（不要问我什么情况下用在线用户表做驱动表