主要观点总结

本文主要介绍了Feed流的设计和实现过程，包括其定义、分类、面临的挑战、功能需求、架构设计和核心业务流程。作者详细解释了Feed流模型中的术语，如Feed、Timeline、发件箱和收件箱，以及它们的作用。文章还讨论了开发Feed流系统时可能遇到的问题，如实时性、海量消息处理、消息感知和翻页问题等，并给出了相应的解决方案。在总体设计部分，作者介绍了系统的架构、数据结构设计、存储和缓存设计，以及核心业务流程。

关键观点总结

关键观点1:

关键观点2:

关键观点3:

关键观点4:

关键观点5:

正文

请到「今天看啥」查看全文

Feed 流其实不是一开始就是这种形式。它起源于 RSS 系统。RSS 翻译过来就是简易信息聚合，它将用户主动订阅的若干消息源组合在一起形成内容（aggregator），帮助用户持续地获取最新的订阅源内容。对用户而言，聚合器是专门用来订阅网站的软件，一般称为 RSS 阅读器、Feed 阅读器等。用户选择订阅多个订阅源，网站提供 Feed 网址 ，用户将 Feed 网址登记到聚合器里，在聚合器里形成聚合页，用户便能持续地获取最新的订阅源内容。整个交互流程简而言之是：用户主动订阅感兴趣的多个订阅源，订阅器帮用户及时更新订阅源信息，然后按照 timeline 时间顺序展示出来。这样，用户可以通过订阅器获取即时信息，而不用每天都检查各个订阅源是否有更新。

可以看出，上述方式很像是在订购杂志，杂志一旦更新，就会寄到家中。但是那时候的的Rss系统，能订阅的只是新闻网站以及博客。直到后来，Facebook 宣布了一项新的首页形式「News Feed」，这一形式打破了传统 RSS 的订阅方式。News Feed 可以看做一个新型聚合器：订阅源由某个新闻网站变成了生产内容的人或者团体，而内容由网站输出的公告新闻，变成了好友（关注对象）的动态（发布的内容以及其他的社交行为）。这样一来，内容丰富程度直线提高，内容发布者和订阅者也由：人和网站变成了人和人，社交距离大大拉近。很快，这种信息获取模式就普及起来了。从此以后，RSS 被迫淡出历史舞台。

1.5 Feed 流模型中的术语

名称	说明	备注
Feed	Feed流中的每一条状态或者消息都是Feed，比如朋友圈中的一个状态就是一个Feed，微博中的一条微博就是一个Feed。	-
Feed 流	Feed流本质上是数据流，核心逻辑是服务端系统将 “多个发布者的信息内容” 通过 “关注收藏屏蔽等关系” 推送给 “多个接收者”。常见的，比如微博上的超话，新版本的微信公众号订阅消息，抖音里的视频流等等	三大特点：少部分人发布；基于订阅行为关联关系；大多数人读取信息
Timeline	Timeline其实是一种Feed流的类型，微博，朋友圈都是Timeline类型的Feed流，但是由于Timeline类型出现最早，使用最广泛，最为人熟知，有时候也用Timeline来表示Feed流。	又叫时间轴
关注页Timeline	展示其他人Feed消息的页面，比如朋友圈，微博的首页等。	又叫做收件箱，每个用户能看到的消息都会被存储到收件箱中
个人页Timeline	展示自己发送过的Feed消息的页面，比如微信中的相册，微博的个人页等	又叫做发件箱，自己发布的消息都会被记录到自己的发件箱中。别人的收件箱内的消息，也是从他的各个关注人的发件箱内同步过来的。
写扩散	一种消息同步方式，用户发布消息后，消息被记录到用户的发件箱中，此时立刻将发件箱内的消息同步给所有用户。	又叫做推模式
读扩散	一种消息同步方式，用户发布消息后，消息被记录到用户的发件箱中。而消息的接收方此时没有收到消息。等到消息接收方需要查看收件箱的时候，才会去接收方关注的所有关注人发件箱中拉取消息，完成消息同步。	又叫做拉模式

02

了解 Feed 流模型的架构

通过上面的介绍，想必你对于将要开发的 Feed 流是什么已经足够了解了。那么，接下来我们从开发的角度切入，再次学习 Feed 流。

我们已经知道了 Feed 流可以分为两大类：基于兴趣推荐，和基于用户关系拉取。两种模式的 Feed 流底层的原理差别很大，所以要分别进行介绍。先介绍第一种：基于用户关系拉取的 Feed 流。

2.1 依赖用户关系的时间顺序 Feed 流

第一类 Feed 流是依赖用户关系的，按时间顺序进行整合展示的 Feed 流。在开发这个模型前，我们需要先了解这个模型主要面对的挑战在哪儿。

• Feed 流模型面临的挑战

1. Feed是一种实时消息，由于消息是实时产生，实时消费，实时推送的，因此满足实时性是关键。（性能要求高）

2. 消息来自于很多不同的消息源，消息的产生属于海量级别。（存储要求大）

3. 性能考虑：从消息产生到消息消费产生巨大的读写比。（读写失衡模型，时间排序）

4. 消息发布出去后，要求用户能够感知，起码满足最终一致性，不可以出现消息丢失。（原子性）

• Feed 流模型需要的基本功能

了解了 Feed 流的面对的挑战后，我们先不着急去处理问题，而是进入具体的功能中去分析 Feed 流模型需要开发的功能。包括如下：

1. 用户发布消息：用户可以发布一条消息，他的订阅者都能感知到他发布了消息；（不仅是消息确保推送出去，而且要有红点提示）

2. 用户删除发布的消息：用户可以删除一条已经发布的消息，他的订阅者都能实时感知到这条消息被删除了；

3. 用户查看自己发布的消息：用户查看自己已经发布的所有消息；
4. 用户订阅消息源：用户可以订阅感兴趣的人，关注的博主以后发送的消息都可以在用户的 Feed 流中查看到。需要注意的是，有的场景中要求用户 Feed 流中能看到博主在被关注之前发的消息，这就要求订阅的时候，还要主动同步一份博主的所有消息到用户的 Feed 流中。
5. 用户取消消息源订阅：用户可以取消已经订阅的人，取关后，Feed 流中关于他的所有消息要除去。
6. 用户查看订阅的消息流（Feed 流）：用户可以以 timeline 的形式查看所有订阅的消息源发布的消息。消息的删除和更新，都会实时被用户感知到。Feed 流的翻页问题：用户翻页 Feed 流的时候，不管 Feed 流更新了多少内容，此时都是沿着最后一次看到的信息往下看。Feed 流前面的信息被删改不予理会。
7. 额外功能：消息支持配置黑白名单，进行细粒度可见权限控制。
8. 可扩展功能：信息可以支持被评论，评论本身也有增删改查

• 面临问题和解决方案

了解了上述 Feed 流需要开发的基本功能，我们进一步对功能实现中可能遇到的问题进行分析，并且给出处理方案：

1. 发布者发布消息后，订阅者如何读取消息？

这里一般有三种方案：读扩散，写扩散和读写结合。

• 读扩散：订阅者读取最新收件箱消息的时候，订阅者主动去查询关注的人的发件箱，遍历所有的人，获取所有的消息，然后更新到自己的收件箱中。
• 写扩散：发布者发布消息后，立刻将自己的消息同步给他所有的粉丝的收件箱中。

请到「今天看啥」查看全文