Feed流使用详解

欧克小奥

已于 2024-01-06 13:33:49 修改

阅读量990

点赞数 7

分类专栏：系统设计文章标签： java

于 2024-01-05 22:17:07 首次发布

本文链接：https://blog.csdn.net/qq_52805594/article/details/135418992

版权

系统设计专栏收录该内容

3 篇文章

订阅专栏

本文探讨了Feed流的概念，包括其工作原理、分类（按时间与排名）、实现模式（推、拉及推拉结合），以及如何优化千万级Feed流系统，如使用Redis存储、分页器和深度分页策略，以及阿里云的相关实践案例。

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

☆* o(≧▽≦)o *☆嗨~我是小奥🍹
📄📄📄个人博客：小奥的博客
📙📙📙Github：传送门
📅📅📅面经分享（牛客主页）：传送门
🍹文章作者技术和水平有限，如果文中出现错误，希望大家多多指正！
📜 如果觉得内容还不错，欢迎点赞收藏关注哟！ ❤️

Feed流概念

Feed流是一个目前非常常见的功能，在众多产品中都有展现，比如微博，朋友圈，消息广场，通知，IM等。通过Feed流可以把动态实时的传播给订阅者，是用户获取信息流的一种有效方式。

Feed：Feed流中的每一条状态或者消息都是Feed，比如朋友圈中的一个状态就是一个Feed，微博中的一条微博就是一个Feed。
Feed流：持续更新并呈现给用户内容的信息流。每个人的朋友圈，微博关注页等等都是一个Feed流。
Timeline：Timeline其实是一种Feed流的类型，微博，朋友圈都是Timeline类型的Feed流，但是由于Timeline类型出现最早，使用最广泛，最为人熟知，有时候也用Timeline来表示Feed流。
关注页Timeline：展示其他人Feed消息的页面，比如朋友圈，微博的首页等。
个人页Timeline：展示自己发送过的Feed消息的页面，比如微信中的相册，微博的个人页等。

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

Feed分类

Feed的常见分类有两种：

TimeLine：按发布的时间顺序排序，先发布的先看到，后发布的排列在最顶端。
Rank：按某个非时间的银子排序，一般是按照用户的喜好度排序等，适用于推荐场景。

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

推模式：当新的 Feed 发布后，将这条内容插入到发布者所有粉丝的 Feed 流中。
拉模式：收到用户拉取Feed流请求后遍历他的关注列表，并拉取关注的人发布的内容实时聚合成 Feed 流。
推拉结合：也叫做读写混合，兼具推和拉两种模式的优点。

两种实现方式各有优缺：

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

Feed流的初始化

Feed流的初始化是指当用户的Feed流还不存在的时候，为该用户创建一个属于自己的Feed流，其实就是遍历一遍关注列表，取出所有的Feed，将FeedId存放到Redis的SortedSet中，score的值如果是TimeLine类型，就取Feed创建的时间戳，如果是rank类型，就把对应权重设置进去。

Feed流的推送

Feed的推送就是更新（这里使用推拉结合模式）。更新分为两类情况：

关注的用户发布、删除新的Feed
用户新增、取消关注

Feed流的存储

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

作者发布的Feed列表：这些数据需要可靠的持久化存储，通常采用MySQL等关系型数据库即可。
用户和作者之间的关注关系：同样需要持久化存储。
用户的Feed流：Feed流可以根据Feed数据库和关注关系构建，因此不需要持久化存储。

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

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

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

持久化存储

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

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

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

Feed流优化

(1) 推拉结合

① 在线推离线拉

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

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

② 定时推离线拉

一个拥有 10 万粉丝的大V在发布微博时，以常驻进程的方式定时推送到粉丝的动态列表。

(2) 分页器

由于 Feed 流通常比较大，不可能一次性将所有内容拉取到本地，所以一般需要支持分页查询。

若在用户浏览过程中他关注的人发布了新的内容，导致原来在第 1 页最后一位的 Feed A 被挤到了第 2 页首位。在使用 Limit + Offset 分页器拉取第 2 页时就会再次拉到 Feed A。于是客户端上显示了两条相同的内容，这个问题非常影响用户体验。

解决重复问题最简单的方法是使用 LastId + Limit 式的分页器。客户端加载下一页时使用本地最后一个 Feed 的 ID 作为游标，服务端使用 ZRangeByScore 命令获得发布时间比它更早的 Feed 作为下一页。无论浏览过程中 Feed 流内被插入了多少新内容，只要 Feed 的时间戳唯一就不会下发重复的 Feed。

一个简单实用的避免时间戳重复的方法是：以发布时间作为 score 的整数部分，Feed ID 作为小数部分。这样 Feed ID 不会干扰排序，此外 Feed ID 不会重复所以 score 也不会重复。

(3) 深度分页

由于 Feed 流比较大而用户大多数时候只浏览最新的内容，所以通常不需要缓存全部 Feed 流只需要缓存最新的部分即可。但是我们无法阻止用户继续向下浏览未缓存的内容，所以还是得想办法支持深度分页。

我们在实践中采用的解决方案是：默认缓存最近一个月的数据，当用户快浏览完缓存内容时则异步地采用拉模式构建最近一年的 Feed 流缓存起来。当用户快读完最近一年的内容时继续缓存更旧的 Feed 流，直至缓存了完整 Feed 流。在追加 Feed 流缓存的同时减少它的 TTL，以避免过大的 Feed 流长期占据内存。