敞开生长之旅!这是我参与「日新计划 12 月更文挑战」的第16天,点击检查活动详情

在学习怎样开发Feeds流运用前,咱们需求先了解什么是Feeds流。

一、什么是Feeds流

Feeds流是一个继续更新并展现给用户的信息流。它将用户自动订阅的若干音讯源组合在一同构成内容聚合器,协助用户继续地获取最新的订阅源内容。所以它通常具有千人千面的个性化特色。举例来说,咱们在各类手机App中能看到的猜你喜欢,你的重视和老友动态等功用,都是Feeds流的一种表现办法。某种意义上来说,你能够一向向下滑动,然后获取到信息的运用,都是归于Feeds流。

二、为什么会有Feeds流

了解了什么是Feeds流后,咱们能够从产品视点考虑一下,为什么会有Feeds流。

咱们能够和传统的信息获取途径,电视,报纸,杂志进行比照。以前咱们获取的信息,通常是自动前往某个信息聚合的途径,如:电视的新闻台,去买一份报纸,订货一本杂志。然后,咱们从中许多阅读,然后才能获取到咱们感爱好的信息。上述流程咱们能够知道,咱们想要获取丰富的信息可不容易。

所以,这就有了Feeds流的呈现了,它的主要作用是:信息聚合。也便是它能够根据你的行为去聚合你想要的信息,然后再将它们以轻松易得的办法供给给你。这个办法便是信息流的办法,你只需求不断的滑动,就能够再各种信息中穿梭,而不需求自己去寻觅,被动接收信息。当然,仅仅是流的办法还不以让它成为如今干流的新闻媒体传达途径。因为传统的电视节目,当你不感爱好的时分,你也能够换台进行切换,也是一种简略易得,可自由挑选的办法。Feeds最中心的能力在于聚合。他会根据你的行为聚合出你想要的信息,例如:微博是经过你的重视列表了解你或许想要的信息源,然后以时刻轴的办法聚合各种信息推给你。后来又呈现了抖音的猜你喜欢,它不需求你的手动重视,而是根据你的阅读时长,点赞等信息生成你的用户画像,然后聚合你或许感爱好的信息。朋友圈的Feeds流则是根据你的老友联系,然后聚合了你或许想要的信息。

正是有了这种五光十色的信息聚合能力,用户在运用Feeds流获取信息的时分,就容易取得他们感爱好的内容。然后有一个很好的运用体会。

三、Feeds流的分类

上面提到了几种Feeds流的运用场景,有:微信朋友圈,微博的重视页,抖音的引荐页。这几个例子其实信息聚合的视点都不相同,为此,咱们能够对Feeds流进行分类,了解不同类型的Feeds流,才知道开发过程中,怎样针对不同的运用场景,去规划最合适的架构,完结Feeds流功用。

开发一个Feeds流系统——写扩散模式

首先,咱们能够从Feeds流的信息源聚合根据进行分类,联系有三种:

从上图咱们能够知道,抖音引荐页能够从你的操作行为中生成你的用户画像,再去匹配聚合信息。而微博则是单向依靠联系,即:我重视了某个大v,就能够获取他发布的信息。这儿的信息聚合根据是单向的重视联系。而微信朋友圈则是双向联系,需求两个人相互经过老友,才会聚合对方的信息到自己的朋友圈中。

三种聚合逻辑,别离适用于信息勘探,信息订阅和熟人交际场景中,各有各的优点。

而除了从信息源聚合根据动身进行分类以外,也能够从Feed流自身的展现逻辑动身进行分类,联系有两类:

开发一个Feeds流系统——写扩散模式

留意:微博热榜许多人也算成了Feeds流,可是严厉意义上来说,他是一个信息流。一切人看到的热榜数据都是相同的,这缺失了信息聚合的特征。所以,本质上热榜的底层模型应该是排行榜,而非feeds流。这儿不将它归为一类。

两个分类是从两个维度对Feeds流进行的划分,可是,不论是什么维度的分类,都是为了更好的靠近事务特色,进行建模开发。

信息源挑选根据\排序根据

权重引荐

时刻次序

无需依靠联系(无强依靠联系)

抖音引荐页

单向依靠联系(重视)

微博重视页

双向依靠联系(老友)

微信朋友圈

实践上,上述表格又能够进一步总结为两类:

分类

运用场景

根据隐含爱好引荐信息,按权重排序展现的feeds流

抖音引荐页

根据用户联系拉取信息,按时刻次序展现的feeds流

微博重视页、微信朋友圈

四、了解Feeds流的宿世今生

经过上面的介绍,想必你对Feeds流现已有了必定的了解。那么再说一下它的前身。

Feeds流其实不是一开始便是这种办法。它起源于RSS体系。RSS 翻译过来便是简易信息聚合,它将用户自动订阅的若干音讯源组合在一同构成内容(aggregator),协助用户继续地获取最新的订阅源内容。对用户而言,聚合器是专门用来订阅网站的软件,一般称为 RSS 阅读器、Feed 阅读器等。用户挑选订阅多个订阅源,网站供给 Feed 网址 ,用户将 Feed 网址登记到聚合器里,在聚合器里构成聚合页,用户便能继续地获取最新的订阅源内容。整个交互流程简而言之是:用户自动订阅感爱好的多个订阅源,订阅器帮用户及时更新订阅源信息,然后按照 timeline 时刻次序展现出来。这样,用户能够经过订阅器获取即时信息,而不必每天都检查各个订阅源是否有更新。

能够看出,上述办法很像是在订货杂志,杂志一旦更新,就会寄到家中。可是那时分的的Rss体系,能订阅的仅仅新闻网站以及博客。直到后来,Facebook 宣告了一项新的首页办法「News Feed」,这一办法打破了传统 RSS 的订阅办法。News Feed 能够看做一个新式聚合器:订阅源由某个新闻网站变成了出产内容的人或许团体,而内容由网站输出的公告新闻,变成了老友(重视目标)的动态(发布的内容以及其他的交际行为)。这样一来,内容丰富程度直线提高,内容发布者和订阅者也由:人和网站变成了人和人,交际距离大大拉近。很快,这种信息获取办法就普及起来了。从此以后,RSS 被逼淡出历史舞台。

五、Feeds流模型中的术语

称号

阐明

补白

Feed

Feed流中的每一条状况或许音讯都是Feed,比方朋友圈中的一个状况便是一个Feed,微博中的一条微博便是一个Feed。

Feeds流

Feed流本质上是数据流,中心逻辑是服务端体系将 “多个发布者的信息内容” 经过 “重视收藏屏蔽等联系” 推送给 “多个接收者”。常见的,比方微博上的超话,新版别的微信公众号订阅音讯,抖音里的视频流等等

三大特色:少部分人发布;根据订阅行为关联联系;大多数人读取信息

Timeline

Timeline其实是一种Feed流的类型,微博,朋友圈都是Timeline类型的Feed流,可是因为Timeline类型呈现最早,运用最广泛,最为人熟知,有时分也用Timeline来表示Feed流。

又叫时刻轴

重视页Timeline

展现其他人Feed音讯的页面,比方朋友圈,微博的首页等。

又叫做收件箱,每个用户能看到的音讯都会被存储到收件箱中

个人页Timeline

展现自己发送过的Feed音讯的页面,比方微信中的相册,微博的个人页等

又叫做发件箱,自己发布的音讯都会被记载到自己的发件箱中。别人的收件箱内的音讯,也是从他的各个重视人的发件箱内同步过来的。

写分散

一种音讯同步办法,用户发布音讯后,音讯被记载到用户的发件箱中,此刻马上将发件箱内的音讯同步给一切用户。

又叫做推办法

读分散

一种音讯同步办法,用户发布音讯后,音讯被记载到用户的发件箱中。而音讯的接收方此刻没有收到音讯。比及音讯接收方需求检查收件箱的时分,才会去接收方重视的一切重视人发件箱中拉取音讯,完结音讯同步。

又叫做拉办法

开发一个Feeds流系统——写扩散模式

了解Feeds流模型的架构

经过上面的介绍,想必你关于即将开发的Feeds流是什么现已满意了解了。那么,接下来咱们从开发的视点切入,再次学习Feeds流。

咱们现已知道了Feeds流能够分为两大类:根据爱好引荐,和根据用户联系拉取。两种办法的Feeds流底层的原理差别很大,所以要别离进行介绍。先介绍第一种:根据用户联系拉取的Feeds流。

一、依靠用户联系的时刻次序Feeds流

第一类Feeds流是依靠用户联系的,按时刻次序进行整合展现的Feeds流。在开发这个模型前,咱们需求先了解这个模型主要面对的挑战在哪儿。

  • Feeds流模型面对的挑战

1.Feed是一种实时音讯,因为音讯是实时发生,实时消费,实时推送的,因此满意实时性是要害。(功用要求高)

2.音讯来自于许多不同的音讯源,音讯的发生归于海量级别。(存储要求大)

3.功用考虑:从音讯发生到音讯消费发生巨大的读写比。(读写失衡模型,时刻排序)

4.音讯发布出去后,要求用户能够感知,起码满意终究一致性,不能够呈现音讯丢失。(原子性)

  • Feeds流模型需求的基本功用

了解了Feeds流的面对的挑战后,咱们先不着急去处理问题,而是进入具体的功用中去剖析Feeds流模型需求开发的功用。包含如下:

1.用户发布音讯:用户能够发布一条音讯,他的订阅者都能感知到他发布了音讯;(不仅是音讯确保推送出去,而且要有红点提示)

2.用户删去发布的音讯:用户能够删去一条现已发布的音讯,他的订阅者都能实时感知到这条音讯被删去了;

3.用户检查自己发布的音讯:用户检查自己现已发布的一切音讯;

4.用户订阅音讯源:用户能够订阅感爱好的人,重视的博主以后发送的音讯都能够在用户的feeds流中检查到。需求留意的是,有的场景中要求用户Feeds流中能看到博主在被重视之前发的音讯,这就要求订阅的时分,还要自动同步一份博主的一切音讯到用户的Feeds流中。

5.用户撤销音讯源订阅:用户能够撤销现已订阅的人,取关后,Feeds流中关于他的一切音讯要除掉。

6.用户检查订阅的音讯流(Feeds流):用户能够以timeline的办法检查一切订阅的音讯源发布的音讯。音讯的删去和更新,都会实时被用户感知到。Feeds流的翻页问题:用户翻页Feeds流的时分,不论Feeds流更新了多少内容,此刻都是沿着最终一次看到的信息往下看。Feeds流前面的信息被修正不予理会。

7.额外功用:音讯支撑装备黑白名单,进行细粒度可见权限控制。‘=

8.可扩展功用:信息能够支撑被谈论,谈论自身也有增修正查

  • 面对问题和解决计划

了解了上述Feeds流需求开发的基本功用,咱们进一步对功用完结中或许遇到的问题进行剖析,而且给出处理计划:

1.发布者发布音讯后,订阅者怎样读取音讯?

这儿一般有三种计划:读分散,写分散和读写结合。

  • 读分散:订阅者读取最新收件箱音讯的时分,订阅者自动去查询重视的人的发件箱,遍历一切的人,获取一切的音讯,然后更新到自己的收件箱中。

  • 写分散:发布者发布音讯后,马上将自己的音讯同步给他一切的粉丝的收件箱中。

  • 读写结合:因为Feeds流是读多写少的场景,所以一般状况下,咱们选用写分散,体系的功用会比读分散要好。可是,当有大v发布者呈现时,他每次发布音讯,或许音讯需求同步给1亿用户,这样写分散的功用会被严峻影响到。所以,在大v用户上,选用读写结合的办法进行处理。具体来说便是:大v用户发布音讯,音讯写分散到活泼用户收件箱。而不活泼用户在登录的时分,会去自动拉取大v用户的发件箱,完结自身收件箱的更新。

因为Feeds流模型是一种读多写少的场景,所以一般选用写分散更好。

当呈现大v的时分,写分散也太慢了,则选用冷热别离计划。热粉丝则写分散同步,冷粉丝(僵尸粉)则读分散。冷热粉丝能够记载登录次数,时长进行分类。也能够选用session池计划,判别在线的粉丝才进行写分散。

2.Feeds流是怎样翻页的?

Feed流的分页入参不会运用page_size和page_num,而是运用last_id来记载上一页最终一条内容的id。前端读取下一页的时分,必须将last_id作为入参,后台直接找到last_id对应数据,再往后偏移page_size条数据,回来给前端,这样就防止了错位问题。留意:选用该last_id办法要求数据不能被删去,不然前端持有这个id,就又或许找不到对应的记载。为此,删去都选用标志位表示删去。当拉出的数据存在删去的时分,进行再次查询补充。

Feeds流是一个动态列表,每时每刻都或许在更新,所以传统的运用page_size和page_num来分页就不能满意运用了。因为凡是两页之间呈现内容的增加或删去,都会导致错位问题。

写分散下的翻页:因为用户收件箱是提早排序准备好的,所以last_id直接往后读取即可。

读分散下的翻页:因为读分散下,用户的收件箱是实时计算出来的,他翻页的时分,需求去一切重视人的发件箱中拉取必定量的数据。拉取后,需求记载当时拉取到了写信箱的write_last_id1,多少个重视就要记载了多少个write_last_id。然后翻页的时分,需求用这些write_last_id往后拉取新的必定量(比方page_size个)的数据。再用这些数据组成的新收件箱列表,挑选page_size条回来前端。一同,还需求更新他实践拉取了音讯的写信箱中的write_last_id,而且存储。当下一次翻页的时分,这批write_last_id将作为下次的翻页时定位的根据。

比照下来看得出:读分散的翻页比写分散复杂许多。

3.写分散办法下,用户发布音讯能够慢慢分散出去,可是删去,修正都要分散出去,速度过慢会呈现时效性问题。而且,假如真的是删去了数据,或许会影响Feeds流的分页功用(第二点现已介绍)。这种状况怎样处理?

  • 选用软删去+懒删去机制

软删去是指:音讯内容不进行实践删去,而是将音讯置为删去状况即可,不分散出去。如此一来,用户在自己的读取收件箱中音讯的时分,是先获取了音讯Id后,再去数据库查出音讯内容,然后判别状况进行过滤,把现已删去的状况除掉,不回来给前端。此刻也需求重新进行捞数据,填充分页内容。懒删去是指:假如过滤了某个音讯,此刻才把音讯从用户收件箱中真实删去。(redis的zset中的对应id进行除掉,完结Feeds流表的改写)

  • 软删去和懒删去的具体完结如下:选用读分散回查计划。

本次需求,咱们的写分散只写了一个音讯id到用户的收件箱中,所以,用户查询收件箱信息的时分,要进行一个回查将信息丰富(该计划比较直接把内容一同写入收件箱内会更加节约内存,减少冗余数据,一同音讯删去无需分散)。

4.用户的收件箱改写时机问题:用户收件箱是音讯同步库,缓存的仅仅音讯id而已,所以能够全量存储一切的重视人发布信息的id。可是,音讯同步库内的音讯实践上变化很大,假如全部选用写分散办法,则会导致实时性问题很大。所以对不同的触发改写操作,咱们需求进行不同处理,各操作如下:

  • 重视他人时,用户的收件箱是否需求触发改写:当用户重视了另一个用户后,他的收件箱需求获取到重视用户的发件箱内一切音讯,然后改写自己的收件箱。(写分散)

  • 撤销重视他人时,用户的收件箱怎样改写:这儿能够选用过滤的办法:咱们从收件箱中获取到了音讯id,然后需求进行回查,可是回查前,判别该id的所属发送人是否还在自己重视列表中。不在则进行除掉音讯,一同删去收件箱中的该音讯id。(读分散+懒删去)

  • 重视人删去或许修正自己音讯时,用户的收件箱怎样改写:这儿也能够选用回查的办法:因为咱们收件箱只存储id,音讯内容需求回查发件人发件箱的具体音讯,所以,回查的时分能够获取最新音讯以此完结删去、修正的同步。

  • 总结:收件箱改写有两类,一类是增加,增加都选用写分散;一类是删去和修正,删去、修正都选用读分散。

上述便是咱们Feeds流模型会遇到的问题,现已给出的一个解决计划。当然,不同的事务场景会遇到不同的侧重点,上述计划仅仅是一个参阅。

开发一个Feeds流系统——写扩散模式

整体规划

一、架构规划

上面咱们Feeds流的底层模型进行了具体的剖析,归纳考虑后,本次开发决议选用以下架构进行开发体系。

开发一个Feeds流系统——写扩散模式

上图能够看出是一个音讯发布的流程交互,经过经过的节点看出咱们体系的一个架构。虽然前文评论了许多问题,但其实底层落到DB便是几个表,每个表进行良好的规划后,就能够满意咱们的根底的功用要求了。然后是咱们的体系内部,中心难点是发布和拉取Feeds流两个功用。对这些问题,下面咱们也会具体分点介绍规划。

数据结构规划阐明:本次体系以面向目标思想进行开发,对Feeds流中需求的功用进行笼统,笼统了以下数据结构(简略版别):

1.音讯:

特点:音讯标题,音讯内容,音讯附件,音讯类型,音讯途径

办法:丰富音讯内容

2.音讯发布处理器:

特点:发送用户,发布装备,音讯id

办法:获取音讯id,获取接受者,获取发布装备,同步音讯,保存音讯

3.用户(音讯拉取器):

特点:用户uid,用户当时操作,用户当时页面途径

办法:获取重视列表,获取粉丝列表,查询发件箱,查询收件箱(收件箱过滤,包含黑白名单,软删去等)

4.发布装备:

特点:发布途径,发布办法

办法:获取发布办法,获取发布途径

上述笼统类的类图参阅示意图(非完整版)

开发一个Feeds流系统——写扩散模式

二、存储和缓存规划

完结音讯推送逻辑,需求将信息进行存储,下面是存储表的规划:

1.音讯表(音讯发布表):

字段称号

字段阐明

补白

msg_id

音讯id

oper_type

操作类型

一般的feeds流体系能够没有这个字段,该字段是和下面的发布装备表结合,用作后续扩展为音讯推送体系的时分用的

msg_title

音讯标题

msg_content

音讯内容

存储json

msg_type

音讯类型:文字,视频等

用于扩展

msg_status

音讯状况:用于标记软删去

用于扩展

msg_channel

音讯所属途径

用于扩展,将来能够接入多个体系

extra_info

额外信息

存储json,用于扩展

sender_id

发布者

ctime

发布时刻

utime

修正时刻

uuid

修正人

2.收件箱:选用redis的zset进行存储,key是“接收者uid+channelid”,value为“值:发件人uid+音讯id,score:发布时刻戳” 。这样规划,能够将计算下沉,每次收件箱呈现音讯的改写的时分,都会自行排序。下面的redis的zset的图示:

开发一个Feeds流系统——写扩散模式

3.发布装备表(一般的feeds流能够不考虑这个,我这是后期计划扩展做成音讯推送体系,这儿也能够供给给我们参阅。):

字段称号

字段阐明

补白

send_id

发布id

send_type

发布类型:立即发布,守时发布,周期发布

send_crontab

发布规矩

守时发布的时分存储crontab

send_msg_channel

发布途径,如邮件,短信,站内信等

指定推送音讯的途径

channel

装备所属途径

用于扩展,将来能够接入多个体系

send_rule

发布规矩:确定在什么操作的时分,会触发发布

如:经过审核的时分,会推送音讯;或许装备发布活动时,会触发推送

extra_info

额外信息

存储json,用于扩展

cuid

创立者

ctime

创立时刻

utime

修正时刻

uuid

修正人

4.重视联系表:

字段称号

字段阐明

补白

main_uid

博主uid

follower_uid

粉丝uid

status

两者状况,主要记载是否拉黑联系

扩展预留

hot_follower

该粉丝是否是热数据

当对大v选用冷热别离的时分,热粉丝假如独自存储,需求进行粉丝和热用户的大规模取交集。所以将每个人的粉丝联系进行标记,查询热数据的时分就能够防止取交集。粉丝冷热状况改变选用写分散即可

extra_info

额外信息

存储json,用于扩展

cuid

创立者

ctime

创立时刻

utime

修正时刻

uuid

修正人

三、中心事务流程

  • 发布Feed流程

当你发布一条Feed音讯的时分,流程是这样的:

1.Feed音讯先进入一个队列服务。

2.先从重视列表中读取到自己的粉丝列表,以及判别自己是否是大V。

3.将自己的Feed音讯写入个人页Timeline(发件箱)。

4.假如是大V,此刻拉取活泼用户;假如是普通用户,则拉取自己的一切粉丝用户。然后将自己的Feed音讯同步写给自己的粉丝,同步的内容为Feed ID。

5.发布Feed的流程到此完毕。

  • 读取Feed流流程

当改写自己的Feed流的时分,流程是这样的:

1.判别自己是否是活泼用户,假如不是,去读取自己重视的大V列表。

2.去读取自己的收件箱,规模起始方位是前次读取到的最新Feed的ID,完毕方位能够使当时时刻,也能够是MAX。然后经过查询出来的FeesId反查Feeds内容,而且把现已软删去的数据除掉出去。

3.假如有拉取到重视的大V列表,则再次并发读取每一个大V的发件箱,假如重视了10个大V,那么则需求10次访问。

4.合并2和3步的结果,然后按时刻排序,回来给用户。

至此,运用推拉结合,冷热别离办法的Feeds流发布,读取Feeds流的流程都完毕了。

中心的发布Feed、拉取Feeds流的整体交互图如下:

开发一个Feeds流系统——写扩散模式

总结

相信看了本文以后,关于怎样完结一个较为牢靠,功用相对有确保的Feeds流体系,你现已有了必定的了解。那么,本次Feeds流的小结到此为止。