1 了解 Feed 流
2 了解 Feed 流模型的架构
3 总体设计
4 总结
了解 Feed 流
三种聚合逻辑,分别适用于信息探测,信息订阅和熟人社交场景中,各有各的优点。
而除了从信息源聚合依据出发进行分类以外,也可以从 Feed 流本身的展示逻辑出发进行分类,关系有两类:
两个分类是从两个维度对 Feed 流进行的划分,但是,不管是什么维度的分类,都是为了更好的贴近业务特点,进行建模开发。
信息源选择依据\排序依据 | 权重推荐 | 时间顺序 |
无需依赖关系(无强依赖关系) | 抖音推荐页 | - |
单向依赖关系(关注) | - | 微博关注页 |
双向依赖关系(好友) | - | 微信朋友圈 |
实际上,上述表格又可以进一步总结为两类:
分类 | 应用场景 |
依据隐含兴趣推荐信息,按权重排序展示的feed 流 | 抖音推荐页 |
依据用户关系拉取信息,按时间顺序展示的feed 流 | 微博关注页、微信朋友圈 |
Feed 流其实不是一开始就是这种形式。它起源于 RSS 系统。RSS 翻译过来就是简易信息聚合,它将用户主动订阅的若干消息源组合在一起形成内容(aggregator),帮助用户持续地获取最新的订阅源内容。对用户而言,聚合器是专门用来订阅网站的软件,一般称为 RSS 阅读器、Feed 阅读器等。用户选择订阅多个订阅源,网站提供 Feed 网址 ,用户将 Feed 网址登记到聚合器里,在聚合器里形成聚合页,用户便能持续地获取最新的订阅源内容。整个交互流程简而言之是:用户主动订阅感兴趣的多个订阅源,订阅器帮用户及时更新订阅源信息,然后按照 timeline 时间顺序展示出来。这样,用户可以通过订阅器获取即时信息,而不用每天都检查各个订阅源是否有更新。
可以看出,上述方式很像是在订购杂志,杂志一旦更新,就会寄到家中。但是那时候的的Rss系统,能订阅的只是新闻网站以及博客。直到后来,Facebook 宣布了一项新的首页形式「News Feed」,这一形式打破了传统 RSS 的订阅方式。News Feed 可以看做一个新型聚合器:订阅源由某个新闻网站变成了生产内容的人或者团体,而内容由网站输出的公告新闻,变成了好友(关注对象)的动态(发布的内容以及其他的社交行为)。这样一来,内容丰富程度直线提高,内容发布者和订阅者也由:人和网站变成了人和人,社交距离大大拉近。很快,这种信息获取模式就普及起来了。从此以后,RSS 被迫淡出历史舞台。
名称 | 说明 | 备注 |
Feed | Feed流中的每一条状态或者消息都是Feed,比如朋友圈中的一个状态就是一个Feed,微博中的一条微博就是一个Feed。 | - |
Feed 流 | Feed流本质上是数据流,核心逻辑是服务端系统将 “多个发布者的信息内容” 通过 “关注收藏屏蔽等关系” 推送给 “多个接收者”。常见的,比如微博上的超话,新版本的微信公众号订阅消息,抖音里的视频流等等 | 三大特点:少部分人发布;基于订阅行为关联关系;大多数人读取信息 |
Timeline | Timeline其实是一种Feed流的类型,微博,朋友圈都是Timeline类型的Feed流,但是由于Timeline类型出现最早,使用最广泛,最为人熟知,有时候也用Timeline来表示Feed流。 | 又叫时间轴 |
关注页Timeline | 展示其他人Feed消息的页面,比如朋友圈,微博的首页等。 | 又叫做收件箱,每个用户能看到的消息都会被存储到收件箱中 |
个人页Timeline | 展示自己发送过的Feed消息的页面,比如微信中的相册,微博的个人页等 | 又叫做发件箱,自己发布的消息都会被记录到自己的发件箱中。别人的收件箱内的消息,也是从他的各个关注人的发件箱内同步过来的。 |
写扩散 | 一种消息同步方式,用户发布消息后,消息被记录到用户的发件箱中,此时立刻将发件箱内的消息同步给所有用户。 | 又叫做推模式 |
读扩散 | 一种消息同步方式,用户发布消息后,消息被记录到用户的发件箱中。而消息的接收方此时没有收到消息。等到消息接收方需要查看收件箱的时候,才会去接收方关注的所有关注人发件箱中拉取消息,完成消息同步。 | 又叫做拉模式 |
了解 Feed 流模型的架构
通过上面的介绍,想必你对于将要开发的 Feed 流是什么已经足够了解了。那么,接下来我们从开发的角度切入,再次学习 Feed 流。
我们已经知道了 Feed 流可以分为两大类:基于兴趣推荐,和基于用户关系拉取。两种模式的 Feed 流底层的原理差别很大,所以要分别进行介绍。先介绍第一种:基于用户关系拉取的 Feed 流。
第一类 Feed 流是依赖用户关系的,按时间顺序进行整合展示的 Feed 流。在开发这个模型前,我们需要先了解这个模型主要面对的挑战在哪儿。
Feed 流模型面临的挑战
Feed是一种实时消息,由于消息是实时产生,实时消费,实时推送的,因此满足实时性是关键。(性能要求高)
消息来自于很多不同的消息源,消息的产生属于海量级别。(存储要求大)
性能考虑:从消息产生到消息消费产生巨大的读写比。(读写失衡模型,时间排序)
消息发布出去后,要求用户能够感知,起码满足最终一致性,不可以出现消息丢失。(原子性)
Feed 流模型需要的基本功能
用户发布消息:用户可以发布一条消息,他的订阅者都能感知到他发布了消息;(不仅是消息确保推送出去,而且要有红点提示)
用户删除发布的消息:用户可以删除一条已经发布的消息,他的订阅者都能实时感知到这条消息被删除了;
用户查看自己发布的消息:用户查看自己已经发布的所有消息; 用户订阅消息源:用户可以订阅感兴趣的人,关注的博主以后发送的消息都可以在用户的 Feed 流中查看到。需要注意的是,有的场景中要求用户 Feed 流中能看到博主在被关注之前发的消息,这就要求订阅的时候,还要主动同步一份博主的所有消息到用户的 Feed 流中。 用户取消消息源订阅:用户可以取消已经订阅的人,取关后,Feed 流中关于他的所有消息要除去。 用户查看订阅的消息流(Feed 流):用户可以以 timeline 的形式查看所有订阅的消息源发布的消息。消息的删除和更新,都会实时被用户感知到。Feed 流的翻页问题:用户翻页 Feed 流的时候,不管 Feed 流更新了多少内容,此时都是沿着最后一次看到的信息往下看。Feed 流前面的信息被删改不予理会。 额外功能:消息支持配置黑白名单,进行细粒度可见权限控制。 可扩展功能:信息可以支持被评论,评论本身也有增删改查
面临问题和解决方案
了解了上述 Feed 流需要开发的基本功能,我们进一步对功能实现中可能遇到的问题进行分析,并且给出处理方案:
发布者发布消息后,订阅者如何读取消息?
这里一般有三种方案:读扩散,写扩散和读写结合。
读扩散:订阅者读取最新收件箱消息的时候,订阅者主动去查询关注的人的发件箱,遍历所有的人,获取所有的消息,然后更新到自己的收件箱中。 写扩散:发布者发布消息后,立刻将自己的消息同步给他所有的粉丝的收件箱中。 读写结合:由于 Feed 流是读多写少的场景,所以一般情况下,我们采用写扩散,系统的性能会比读扩散要好。但是,当有大v发布者出现时,他每次发布消息,可能消息需要同步给1亿用户,这样写扩散的性能会被严重影响到。所以,在大 v 用户上,采用读写结合的方式进行处理。具体来说就是:大 v 用户发布消息,消息写扩散到活跃用户收件箱。而不活跃用户在登录的时候,会去主动拉取大 v 用户的发件箱,完成自身收件箱的更新。
采用软删除+懒删除机制 软删除是指:消息内容不进行实际删除,而是将消息置为删除状态即可,不扩散出去。如此一来,用户在自己的读取收件箱中消息的时候,是先获取了消息 id 后,再去数据库查出消息内容,而后判断状态进行过滤,把已经删除的状态剔除,不返回给前端。此时也需要重新进行捞数据,填充分页内容。懒删除是指:如果过滤了某个消息,此时才把消息从用户收件箱中真正删除。(redis 的 zset 中的对应 id 进行剔除,完成 Feed 流表的刷新)
软删除和懒删除的具体实现如下:采用读扩散回查方案。 本次需求,我们的写扩散只写了一个消息 id 到用户的收件箱中,所以,用户查询收件箱信息的时候,要进行一个回查将信息丰富(该方案相比直接把内容一起写入收件箱内会更加节约内存,减少冗余数据,同时消息删除无需扩散)。
关注他人时,用户的收件箱是否需要触发刷新:当用户关注了另一个用户后,他的收件箱需要获取到关注用户的发件箱内所有消息,然后刷新自己的收件箱。(写扩散)
取消关注他人时,用户的收件箱如何刷新:这里可以采用过滤的方式:我们从收件箱中获取到了消息 id,而后需要进行回查,但是回查前,判断该 id 的所属发送人是否还在自己关注列表中。不在则进行剔除消息,同时删除收件箱中的该消息 id。(读扩散+懒删除)
关注人删除或者修改自己消息时,用户的收件箱如何刷新:这里也可以采用回查的方式:由于我们收件箱只存储 id,消息内容需要回查发件人发件箱的具体消息,所以,回查的时候可以获取最新消息以此完成删除、修改的同步。
总结:收件箱刷新有两类,一类是添加,添加都采用写扩散;一类是删除和修改,删除、修改都采用读扩散。
上述就是我们 Feed 流模型会遇到的问题,已经给出的一个解决方案。当然,不同的业务场景会遇到不同的侧重点,上述方案仅仅是一个参考。
总体设计
上面我们 Feed 流的底层模型进行了详细的分析,综合考虑后,本次开发决定采用以下架构进行开发系统。
上图可以看出是一个消息发布的流程交互,通过经过的节点看出我们系统的一个架构。虽然前文讨论了很多问题,但其实底层落到 DB 就是几个表,每个表进行良好的设计后,就可以满足我们的基础的性能要求了。而后是我们的系统内部,核心难点是发布和拉取 Feed 流两个功能。对这些问题,下面我们也会具体分点介绍设计。
数据结构设计
消息:
属性:消息标题,消息内容,消息附件,消息类型,消息渠道
方法:丰富消息内容
消息发布处理器:
属性:发送用户,发布配置,消息id
方法:获取消息id,获取接受者,获取发布配置,同步消息,保存消息
用户(消息拉取器):
属性:用户uid,用户当前操作,用户当前页面渠道 方法:获取关注列表,获取粉丝列表,查询发件箱,查询收件箱(收件箱过滤,包括黑白名单,软删除等)
发布配置:
属性:发布渠道,发布方式 方法:获取发布方式,获取发布渠道
上述抽象类的类图参考示意图(非完整版)
1、消息表(消息发布表):
字段名称 | 字段说明 | 备注 |
msg_id | 消息id | |
oper_type | 操作类型 | 一般的 feed 流系统可以没有这个字段,该字段是和下面的发布配置表结合,用作后续扩展为消息推送系统的时候用的 |
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 的图示:
字段名称 | 字段说明 | 备注 |
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 消息先进入一个队列服务。 先从关注列表中读取到自己的粉丝列表,以及判断自己是否是大V。 将自己的 Feed 消息写入个人页 Timeline(发件箱)。 如果是大V,此时拉取活跃用户;如果是普通用户,则拉取自己的所有粉丝用户。然后将自己的 Feed 消息同步写给自己的粉丝,同步的内容为 Feed ID。 发布 Feed 的流程到此结束。
读取 Feed 流流程
判断自己是否是活跃用户,如果不是,去读取自己关注的大V 列表。
去读取自己的收件箱,范围起始位置是上次读取到的最新 Feed 的 ID,结束位置可以使当前时间,也可以是 MAX。然后通过查询出来的 FeesId 反查 Feed 内容,并且把已经软删除的数据剔除出去。 如果有拉取到关注的大V 列表,则再次并发读取每一个大V 的发件箱,如果关注了10个大V,那么则需要10次访问。
合并2和3步的结果,然后按时间排序,返回给用户。
至此,使用推拉结合,冷热分离方式的 Feed 流发布,读取 Feed 流的流程都结束了。
核心的发布 Feed、拉取 Feed 流的总体交互图如下:
总结
如喜欢本文,请点击右上角,把文章分享到朋友圈
如有想了解学习的技术点,请留言给若飞安排分享
因公众号更改推送规则,请点“在看”并加“星标”第一时间获取精彩技术分享
·END·
相关阅读:
作者:彭玉翔
来源:腾讯云开发者
版权申明:内容来源网络,仅供学习研究,版权归原创者所有。如有侵权烦请告知,我们会立即删除并表示歉意。谢谢!
我们都是架构师!
关注架构师(JiaGouX),添加“星标”
获取每天技术干货,一起成为牛逼架构师
技术群请加若飞:1321113940 进架构师群
投稿、合作、版权等邮箱:admin@137x.com