知乎Feed流的架构演进.docx
《知乎Feed流的架构演进.docx》由会员分享，可在线阅读，更多相关《知乎Feed流的架构演进.docx（7页珍藏版）》请在冰点文库上搜索。
知乎Feed流的架构演进
知乎Feed流的架构演进
知乎Feed流的架构演进
我们每天都在刷知乎、刷微博、刷Twitter，推文一条接一条地从你的指尖流过，信息就这样被你获取了。
可你有没有想过背后支撑着这信息流的技术是怎么样的呢？
什么是feed
什么是feed？
你现在手机上的知乎、微信、微博等App中就存在着feed。
不太严谨地划分，用户获取信息的方式可以分为Pull和Push，即“拉”／“推”。
再详细一些，用户主动去获取、并且明确指定自己希望获取的信息的过程是Pull，而在不明确表述自己的信息需求的情况下，被动接受信息的过程是Push。
举个例子：
一个人走到图书馆，按照字母表找到某一本书，获取这本书的内容，可以看作是主动寻找信息；当这个人坐到电视前，他并不知道可能会有什么内容出现，这可以看作是被动接受内容。
feed从英文翻译过来是【投喂；供给；满足】的意思，feed流产品形象地将用户等待接受信息的场景描绘为用户被信息“投喂”。
feed流在中文里可以翻译为“信息流”。
如果将feed描述为一个信息准备被投喂，那么feed流则是多个准备投喂的“信息”像流水线一样按照一定规则排列好。
feed的特点
现在，当大家讨论feed，一般来说会特指一列可以不断向下滑动不断加载的信息列表。
feed具备以下几个特点：
∙使用简单，主要操作只有点击、向下滑动加载。
∙信息量大，每个feed条目都是一个独立的信息。
∙兼容性好，可以在feed中展示文字、图片、视频、甚至是可操作的卡片。
……
它被大量地应用在不同领域的不同应用上，也成为了用户上网消费大量内容时，最熟悉的交互模式。
feed流产品的发展历史
feed流是一个非常笼统的说法。
在我看来，将一类信息按照一定规律进行排序就可以称为feed流产品。
由于其同时兼顾了大量信息下的展示与消费，如今feed流产品越来越被大多数互联网产品所使用。
早期互联网中，门户网站上一列列的文章标题，可以算作最早的feed。
由编辑筛选，每个人看到的都是一致的内容。
随着媒体式的中心化发声方式从线下纸媒，理所当然般继承到了互联网上，不论中美，在最初的互联网世界上都出现了许多门户巨头。
此时门户主页可以看作是最原始的feed，这个时候并没有后来流行的“订阅”及“个性化”等信息分发方式，所有人接受到的信息是相同的。
互联网上基于“订阅”的个性化feed开始被较大规模使用是从RSS（ReallySimpleSyndication，一个互联网信息来源格式规范）开始的。
在Web时代，每个站点会独立发布消息。
由于网站数量的爆发式增长，RSS协议开始被用户用来订阅独立站点发布的消息，这样，用户可以在一个RSS阅读器上看到所有订阅站点发布的消息，而不需要再去不同的网站接受信息。
从RSS阅读器开始，这种“持续更新不同来源的信息，并呈现给用户的信息组织形式”也就正式拥有了“feed流”的名字。
而接下来，随着互联网的发展，“订阅”行为已经不再局限于RSS协议这个媒介。
一系列产品的出现，开始允许用户以极低的成本发布信息，并非常容易的在一个产品中关注其他发布信息的人，比如：
Facebook、Twitter、微博、知乎、微信的朋友圈等。
由于feed流产品可以将所有订阅的信息源（信息创作者/信息类型/信息发布者等）发布的信息汇集到一个地方，同时按照一定的规则排序展示出来，大大提高了用户接受信息的效率，这也就成为了这些产品的主要消费场景。
随着互联网产品和技术的演进，将feed的使用成本再次降低。
之前主流的feed大都依赖“订阅”这一关注关系实现，而此时可以在取消了关注行为后，直接根据用户的信息消费历史，使用数据挖掘的手段，计算使用者可能对哪些内容感兴趣，从而进行feed生成。
这将feed的使用成本再次降低，使用者的门槛变得无比之低，越来越多的产品开始向此方向尝试，例如YouTube、Facebook、知乎。
总的来说，feed中的内容来源有以下几种：
帮助用户把最可能有价值的信息筛选出来则可以大大提高消费效率。
所以有人在feed排序中引入了“排序算法”。
排序算法在初期是非常简单且粗暴的：
∙认为来自某些高价值订阅源的信息更重要——提升排序中的权重；
∙认为带有图片的文章对用户更有吸引力——提升排序中的权重；
∙认为...提升排序中的权重。
……
也就是全靠主观判断，觉得哪些地方重要就提升权重。
第二阶段，会根据用户的行为动态地调整内容权重，不再是全靠产品运营者拍脑袋决定。
比如你经常点击某个订阅源生产的内容，给某些文章点赞，评论一些人的回答等等。
因为具体产品形态不同而产生不同的各种交互行为都在暴露你的喜好，甚至不点击任何内容也是一种反馈信号。
但即使是在第二阶段中引入了用户行为作为排序的依据，却依然有产品运营者在对各种行为下主观判断，这种主观判断是否和用户的真正需求匹配？
根本无从分析。
而随着产品复杂度的提高以及用户量及分发量的急剧扩大，越来越多的信息开始被收集到：
内容的长度、视频阅读时间、包含的链接、好友有没有读过、跟你比较相似的用户是否喜欢看、标题中的关键字等等，人类大脑没有办法为如此多的变量设定一个权重，将排序交给“机器学习”来进行则是一个必然的结果。
做好feed的关键要素是什么？
∙快：
新生产的内容能第一时间出现在feed流中
∙准：
尽量推荐和用户的兴趣、调性相关的内容
∙优：
保证内容优质，过滤掉谣言、反智、低俗的内容
∙多：
保证多样性，帮助用户发现更大的世界
知乎feed的发展过程与规划
知乎feed的发展经历了以下一系列过程：
第一阶段
2011年，知乎上线，在初期用户积累阶段，feed是基于用户间的关注关系，将每个用户的动态按照时间倒序的形式展示。
这是起步时采用的方式，简单易懂。
但随着用户量的上涨，刷屏、新内容量过多等问题很快就暴露出来。
技术架构上采用了推模型，当用户产生新的动态时会向他的每个关注者进行推送。
这种构架逻辑简单，实现容易，响应时间快。
但是随着用户量的增加，推送方式资源占用多的劣势随之显现出来，特别是对于关注了很多人的用户，动态推送需要占用大量的资源，推送的速度也随之变得非常慢。
第二阶段
2013年11月，知乎参考Facebook所提出的EdgeRank算法模型，上线了新的feed流产品。
此时的知乎feed流主要根据AffinityScore（用户与feed源的亲密度），EdgeWeight（权重），TimeDecay（时间衰减）来进行排序。
随着用户量的增加，技术构架上从“推”转换成了“推”/“拉”结合的方式，节省了大量资源占用。
但是由于feed的计算逻辑都放到了在线，响应时间急剧变慢。
为了解决这个问题，我们对用户按照活跃度进行分群，为每个用户计算活跃度，然后根据用户的活跃度离线提前计算，只有非活跃用户实时计算。
这样活跃用户访问的都是缓存，速度很快。
但是这种架构也存在问题：
∙用户产生的动态不能实时分发
∙算法策略不能实时调整
∙离线计算策略维护复杂
相比第一阶段，知乎feed的CTR（Click-Through-Rate）和Duration都有了20%左右的提升。
第三阶段
2017年初至今，知乎上线了基于机器学习的排序算法，采用GBDT算法，根据用户维度的特征、内容维度的特征、以及交叉特征来进行排序，更重要的是加入了内容质量的判断，质量高的内容会得到更好的分发。
技术构架上采用了计算接近存储的设计方案，使用RedisModule将部分固定的计算逻辑放到Redis中进行计算，去掉了所有的离线计算，使用户的动态能够快速分发，算法模型能够实时调整。
相比第二阶段，这次进化取得了较大的成果。
feed的响应时间的P95降低了45%，资源占用减少了40%，CTR和Duration分别有100%和40%的提升。
高质量内容分发占比提升10%。
未来规划
在算法角度正在基于深度学习搭建更加个性化的推荐模型。
技术构架上使用RedisModule后的Redis的动态扩容和比较多内存占用也是正在解决的问题。
产品上我们会在feed上做进一步升级，将会尝试将关注关系产生的feed内容和推荐引擎产生的feed内容做一些隔离，这样能更好地满足用户不同的需求。
升级会员 