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

写在前面做互联网开发这么多年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流领域常用的几个术语统一一下免得后面沟通时产生歧义。FeedFeed流中的每一条状态或消息都叫Feed。朋友圈里的一条状态是一个Feed微博里的一条微博也是一个Feed。Feed流本质上是数据流核心逻辑是服务端将多个发布者的信息内容通过关注、收藏、屏蔽等关系推送给多个接收者。它有三个特点少部分人发布基于订阅行为关联关系大多数人读取信息。TimelineTimeline是一种Feed流的类型微博和朋友圈都是Timeline类型的Feed流。由于Timeline出现最早、使用最广泛有时候人们也直接用Timeline来指代Feed流。关注页Timeline展示其他人Feed消息的页面比如朋友圈、微博首页。它还有一个名字叫收件箱——每个用户能看到的消息都会被存储到他的收件箱中。个人页Timeline展示自己发送过的Feed消息的页面比如微信的相册、微博的个人主页。它也叫发件箱——自己发布的消息都会记录在自己的发件箱中。别人的收件箱里的消息就是从各个关注人的发件箱同步过来的。写扩散也叫推模式。用户发布消息后消息被记录到发件箱中然后立刻同步给所有粉丝的收件箱。读扩散也叫拉模式。用户发布消息后消息只记录到发件箱中。粉丝不会立刻收到而是等到粉丝查看Feed流的时候主动去所有关注人的发件箱里拉取消息。这几个术语后面会反复出现搞清楚它们的含义很重要。6. 小结这篇文章主要聊了Feed流的基本概念。从RSS到Facebook News Feed的演变从三种聚合方式到两种排序策略这些内容看似偏理论但实际上直接决定了后续的架构选型。如果用一句话总结这一篇Feed流的核心是信息聚合不同的聚合逻辑和排序方式对应不同的技术方案。搞清楚你要做的是哪种类型的Feed流才能选对架构。下一篇我们会进入正题——聊一聊Feed流系统的架构设计重点分析推模式、拉模式和推拉结合这三种数据分发策略各自的优缺点和适用场景。这也是Feed流系统设计中最核心的决策点之一。