​![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10178976/64bd070efdd1f6bc89d11fab4ec037c6.jpg)

## 写在前面

做互联网开发这么多年，Feed流这个东西几乎无处不在。朋友圈是Feed流，微博首页是Feed流，抖音刷到的那些视频也是Feed流。甚至很多App里那个叫"动态"或者"发现"的tab，本质上都是Feed流。

但真要让你从零设计一个Feed流系统，可能很多人会犯怵。不是因为技术多难，而是因为Feed流涉及的东西太杂了——存储、缓存、消息队列、分发策略、分页方案，每一块都有坑。所以我想花几篇文章的篇幅，把Feed流系统从头到尾捋一遍。不是那种泛泛而谈的概述，而是真正能落地的设计方案。

这一篇先不急着写代码，我们把Feed流到底是什么、怎么分类、有哪些核心概念搞清楚。磨刀不误砍柴工，后面真正做架构设计的时候会顺畅很多。

## 1. 什么是Feed流

Feed流说白了就是一个持续更新并展示给用户的信息流。它把用户主动订阅的多个消息源组合在一起，形成一个内容聚合器，帮助用户持续地获取最新的内容。

听起来有点抽象，举个具体的例子。你关注了20个博主，这20个博主每天会发各种内容。如果没有Feed流，你得挨个点进他们的主页去看有没有更新。但有了Feed流，系统会自动把这20个博主最新发布的内容聚合到一起，你只需要在一个页面里不断往下划就能看完。

所以Feed流最核心的能力就是两个字：聚合。

微博通过你的关注列表聚合信息源，然后按时间轴的形式推给你。抖音不需要你手动关注，而是根据你的观看时长、点赞行为生成用户画像，聚合你可能感兴趣的内容。微信朋友圈则是根据你的好友关系，聚合你朋友们发布的动态。

虽然表现形式不同，但本质都是一样的——根据某种规则把信息聚合起来，然后以流的方式呈现给用户。

## 2. Feed流是怎么来的

在聊怎么设计之前，先花点时间聊聊Feed流的前世今生。了解它的来龙去脉，有助于理解为什么Feed流会演变成现在这个样子。

Feed流的前身是RSS系统。RSS的全称是Really Simple Syndication，翻译过来就是"简易信息聚合"。在Web 2.0时代早期，RSS是非常主流的信息获取方式。用户可以选择订阅多个网站，比如科技博客、新闻站点，然后通过一个RSS阅读器统一查看这些网站的最新内容。

整个过程有点像订杂志——你选好了想看的杂志，杂志一出新一期就自动寄到你家。只不过RSS订阅的是网站，内容是网页上的文章。

RSS的问题在于，它能订阅的只是新闻网站和博客，而且内容形式比较单一，就是文字和图片。真正让Feed流走向大众的，是Facebook。

2006年，Facebook推出了一个叫News Feed的功能。这个功能彻底改变了信息分发的方式——订阅源从"网站"变成了"人"，内容从"新闻公告"变成了"好友动态"。你可以看到朋友发了什么状态、传了什么照片、加了什么好友。内容丰富程度直线上升，而且人与人之间的社交距离被大大拉近了。

这个模式很快就被验证了，Twitter、微博、微信朋友圈纷纷跟进。从此RSS逐渐淡出历史舞台，Feed流成为了移动互联网时代最主流的信息获取方式。

## 3. Feed流的分类

搞清楚了Feed流是什么，接下来要做的就是对它进行分类。为什么要分类？因为不同类型的Feed流，底层的设计思路差别很大。用错方案，轻则性能拉胯，重则架构要推倒重来。

### 3.1 按信息聚合依据分类

Feed流的信息聚合依据主要有三种：

**第一种是无关系依赖的。** 最典型的就是抖音的推荐页。你不需要关注任何人，系统根据你的行为数据（看了什么视频、看了多久、点了什么赞）生成用户画像，然后从海量内容池里匹配你可能感兴趣的内容推给你。这种方式的核心是算法和推荐引擎，用户关系反而是次要的。

**第二种是单向关系依赖的。** 微博的关注页就是这种。你关注了一个博主，就能看到他发布的内容。这种关系是单向的——你关注他，他不需要关注你。信息聚合的依据就是"我关注了谁"。

**第三种是双向关系依赖的。** 微信朋友圈是典型代表。只有两个人互相加了好友，才能看到对方的朋友圈内容。信息聚合的依据是"谁是我的好友"。

这三种聚合逻辑分别适用于不同的场景：无关系依赖适合信息探测（发现新内容），单向关系适合信息订阅（主动追踪感兴趣的人），双向关系适合熟人社交。

### 3.2 按内容排序方式分类

除了按聚合依据分，还可以按内容的排序方式来分：

**时间顺序排序。** 这是最常见的形式，先发布的排在前面，后发布的排在后面（或者反过来，最新的在最上面）。微信朋友圈、微博关注页都是这种。产品选择这种排序方式，隐含的假设是：Feed流中的每条内容都很重要，都需要用户看到。

**权重排序。** 这种方式不按时间排，而是按照某个权重因子排序，用户最可能感兴趣的排在最前面。抖音推荐页、今日头条的信息流就是这种。产品选择这种排序方式，隐含的假设是：内容太多了，用户时间有限，需要帮他筛选出最想看的Top N。

把这两个维度组合起来，可以得到一个更清晰的分类：

| 信息源选择依据 | 权重排序 | 时间顺序 |
|---|---|---|
| 无需依赖关系 | 抖音推荐页 | - |
| 单向依赖关系 | - | 微博关注页 |
| 双向依赖关系 | - | 微信朋友圈 |

实际上可以进一步归纳为两大类：一类是依据隐含兴趣推荐信息、按权重排序展示的Feed流（如抖音推荐页）；另一类是依据用户关系拉取信息、按时间顺序展示的Feed流（如微博关注页、微信朋友圈）。

这两种Feed流的底层实现原理差别非常大。本系列文章主要聚焦第二种——基于用户关系的Timeline类型Feed流，因为它是更基础、更通用的形式。推荐类型的Feed流涉及大量算法相关的内容，会在最后一篇中简要介绍思路。

## 4. Feed流的核心特征

在正式进入架构设计之前，有必要先了解一下Feed流系统有哪些典型的特征。这些特征直接决定了我们在做技术选型和架构设计时要关注什么。

**多账号内容流。** Feed流系统中存在成千上万的账号，账号之间可以关注、取关、加好友、拉黑。系统需要维护这些复杂的关系网络，并且在关系发生变化时及时更新内容分发策略。

**非稳定的账号关系。** 用户可以随时关注、随时取关，关系是在不断变化的。这意味着系统不能只做一次性的数据同步，而是要能持续处理关系的动态变更。

**读写比例严重失衡。** Feed流是典型的读多写少场景。一条消息发布出去，可能会被成百上千甚至上千万的用户读取。读写比通常在10:1以上，极端情况下能达到100:1甚至更高。这就要求系统在读性能上做足功夫。

**消息必达性要求高。** 用户发了条朋友圈，结果女朋友没看到——这种事情在产品层面是不可接受的。消息发布出去后，必须保证所有关注者都能感知到，至少要满足最终一致性，不能出现消息丢失的情况。

理解了这些特征，后面讨论架构方案的时候就会更有针对性。

## 5. 几个关键术语

在深入设计之前，先把Feed流领域常用的几个术语统一一下，免得后面沟通时产生歧义。

**Feed**：Feed流中的每一条状态或消息都叫Feed。朋友圈里的一条状态是一个Feed，微博里的一条微博也是一个Feed。

**Feed流**：本质上是数据流，核心逻辑是服务端将"多个发布者的信息内容"通过"关注、收藏、屏蔽等关系"推送给"多个接收者"。它有三个特点：少部分人发布，基于订阅行为关联关系，大多数人读取信息。

**Timeline**：Timeline是一种Feed流的类型，微博和朋友圈都是Timeline类型的Feed流。由于Timeline出现最早、使用最广泛，有时候人们也直接用Timeline来指代Feed流。

**关注页Timeline**：展示其他人Feed消息的页面，比如朋友圈、微博首页。它还有一个名字叫"收件箱"——每个用户能看到的消息都会被存储到他的收件箱中。

**个人页Timeline**：展示自己发送过的Feed消息的页面，比如微信的相册、微博的个人主页。它也叫"发件箱"——自己发布的消息都会记录在自己的发件箱中。别人的收件箱里的消息，就是从各个关注人的发件箱同步过来的。

**写扩散**：也叫推模式。用户发布消息后，消息被记录到发件箱中，然后立刻同步给所有粉丝的收件箱。

**读扩散**：也叫拉模式。用户发布消息后，消息只记录到发件箱中。粉丝不会立刻收到，而是等到粉丝查看Feed流的时候，主动去所有关注人的发件箱里拉取消息。

这几个术语后面会反复出现，搞清楚它们的含义很重要。

## 6. 小结

这篇文章主要聊了Feed流的基本概念。从RSS到Facebook News Feed的演变，从三种聚合方式到两种排序策略，这些内容看似偏理论，但实际上直接决定了后续的架构选型。

如果用一句话总结这一篇：Feed流的核心是信息聚合，不同的聚合逻辑和排序方式对应不同的技术方案。搞清楚你要做的是哪种类型的Feed流，才能选对架构。

下一篇我们会进入正题——聊一聊Feed流系统的架构设计，重点分析推模式、拉模式和推拉结合这三种数据分发策略各自的优缺点和适用场景。这也是Feed流系统设计中最核心的决策点之一。


做互联网开发这么多年，Feed流这个东西几乎无处不在。朋友圈是Feed流，微博首页是Feed流，抖音刷到的那些视频也是Feed流。甚至很多App里那个叫"动态"或者"发现"的tab，本质上都是Feed流。

Feed流系统设计（一）：从RSS到信息流，理解Feed流的本质

软件开发工程师

架构设计

后端

网络与通信

Feed流系统是互联网开发中的核心组件，涵盖朋友圈、微博、抖音等应用。本文详解Feed流的概念、分类及核心特征，包括时间排序与权重排序的区别，以及推拉模式的应用场景。适合开发者了解Feed流设计原理，为后续架构选型提供理论基础。

消息队列

数据同步

数据流

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Feed流系统设计（一）：从RSS到信息流，理解Feed流的本质-腾讯云开发者社区-腾讯云

Feed流系统设计（一）：从RSS到信息流，理解Feed流的本质

Feed流系统设计（一）：从RSS到信息流，理解Feed流的本质

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐