Feed流之微博系统设计

本文主要阐述feed流的技术方案 ①relation存储 ②发帖订阅/推送

简介

1. 概念:Feed + 流(Feed流将用户主动订阅的若干消息源组合在一起,形成内容聚合器,帮助用户持续的获取最新的订阅内容,Feed流即持续更新并呈现给用户内容的信息流)

        Feed:投喂

        流:给用户呈现信息的形式       

2. 场景

        ① 社交互动类:微信、微博、Instagram、Facebook ...

        ② 新闻资讯类:今日头条、腾讯新闻 ...

        ③ 视频直播类:抖音、快手 ...

3. 主要模式

        1. 推模式:用户发帖,对所有粉丝推送该消息(不适合大V)

        2. 拉模式:主动拉取用户所有关注这的最近动态列表(不适合关注了很多用户的用户)

        3. 推拉模式结合

4. 排序方式

        1. TimeLine排序:按照发布时间顺序排序,先发布的先看到,后发布的排列在最顶端,类似于微信朋友圈(产品如果选择 Timeline 类型,那么就是认为 Feed 流中的 Feed 不多,但是每个 Feed 都很重要,都需要用户看到)

        2. Rank排序:按照非时间的因子排序,一般按照用户的喜爱好度排序(这种一般假定用户可能看到的 Feed 非常多,而用户花费在这里的时间有限,那么就为用户选择出用户最想看的 Top N 结果,场景的应用场景有微博、头条新闻推荐类、商品、视频推荐等)

        3. 智能排序:基于趋势 trending、热门 hot、编辑推荐 PGC 等因素综合考虑

微博系统设计

业务特点

海量数据、高访问量、非均匀

        1. 海量用户数据:亿级别的用户数量,每个用户千级别的帖子数量,平均千级别的follower/attention数量

        2. 高访问量:每秒十万量级的访问页面,每秒万量级别的帖子发布

        3. 用户分布非均匀:部分用户的帖子数量/follower数量,相关页面访问数量会超出其他用户几十个数量级

        4. 时间分布非均匀:某个用户在某个时间点成为热点用户,其follower可能徒增数个量级

核心问题1:“关注模型”的存储

最简单的是基于DB的存储,只需要两张表 relation_tab \ user_info_tab

user_info_tab 用户信息表:自增id、用户账号user_id、用户信息(头像、名称、注册时间、大v认证、手机号等)

relation_tab 关系表:自增id、关注者id、被关注者id

==> 所以,只需要查询2张表就可以查询出关注、粉丝、用户信息

// 查询所有“关注者”关注的人
select count(*) from relation_tab where 关注者id='xx'
// 查询“被关注者”所有的粉丝
select count(*) from relation_tab where 被关注者id='xx'
// 根据用户账号,查询user_info
select * from user_info_tab where user_id='xx'

        随着用户的增多,relation_tab \ user_info_tab表的行数增多。千万、亿级用户,每个用户相关关系百级,那么就需要水平拆分

user_info_tab 用户信息表拆分规则:水平拆分

        1. 上亿的数据量,拆分成10~20张表,每张表保存约500~1000万个用户:表名user_info_{idx}_tab

        2. 按照user_id,hash取模,得到idx,数据存放在user_info_{idx}_tab

relation_tab 关系表拆分规则:垂直拆分+水平拆分

根据2种业务场景进行水平拆分

        1. 根据follower进行水平拆分:查询follower关注的列表很简单,但是查询follower的粉丝很难

        2. 根据attention进行水平拆分:查询attention的粉丝列表很简单,但是查询attention关注的人很难

针对上述问题,进行垂直拆分,

        1. 分为follower表和attention表,分别记录了某个用户的关注者和被关注者。表字段

                - follower表:自增id、user_id、follower_id

                - attention表:自增id、user_id、attention_id

        2. 接下来对follower表和attention表分别基于user_id进行水平拆分

==> 此时,实现查询user_id的关注列表、粉丝列表的user_info

// 查询user_id关注列表、粉丝列表
select count(*) from follower_{idx}_tab where user_id='xx'
select count(*) from attention_{idx}_tab where user_id='xx'
// 查询用户信息
select * from user_info_{idx}_tab where user_id In ('xx', 'yy', ...)

        分析:前2步可以落在相同的mysql分片上,执行DB操作次数为2次,但是第3步仍然需要查询多个table(因为用户信息散落在不同的user_info_{idx}_tab表中,所以需要遍历各个分片查询)

        优化:将user_info_{idx}_tab表中的用户基本信息,全部加载到Redis缓存中。除此之外,可以将① 每个user_id的粉丝数和关注数,也存在用户信息中。②每个用户关注数量有上限,所以也可以将该用户关注列表存在Redis的list结构中。③但是用户的粉丝列表不可以全部存储在Redis的list中,会出现大key问题(根据业务场景分析,可以保存用户最近新增的100个粉丝列表,即将新增的用户放在list的最后面)。

核心问题2:帖子(post)的设计实现与优化

        一般存储帖子,通常都是在MySQL中进行存储,数据库字段:post_id、user_id、content、post_time,其中

        - post_id:帖子id

        - user_id:发帖人

        - content:发帖内容

        - post_time:发帖时间,精确到秒(同一个用户在1s之内发送的帖子数通常不多余1条)

        索引:对user_id+post_time建立联合级索引 ==> 查询某个用户按照时间排列的所有帖子

// 查询某个用户在post_time时间段内发的帖子
select * from post_tab where user_id=? and post_time between ? and ?
// 查询某个帖子
select * from post_tab where post_id=?

        

核心问题3:大V发帖了,应该如何设计?

业务场景:在微博平台,用户可以对喜欢的人进行关注,关注了之后,这些人发帖子了,用户就会看到,按照时间进行排序和分页。

核心问题:用户关注好友后,如何快速得到所有好友的最新发表的微博内容,即发表 / 订阅问题,是微博的核心业务问题!

       Feed流之微博系统设计_第1张图片

简介:每个用户都有一个“收件箱inBox”和“发件箱outBox”

        1. 用户刷微博时,查看自己的“收件箱inBox”

        2. 用户发微博时,将邮件插入到“发件箱outBox”

方式1:push模式(推模式是在用户发微博的时候推送给所有的粉丝/关注者)

业务场景

        1.用户发表的内容插入到所有粉丝的“收件箱inBox”里,粉丝拉取关注流从自己的“收件箱inBox”里拉取

        2.用户撤销发表,从每个粉丝的“收件箱inBox”里删除掉

        3.新粉丝新关注了此用户,将该用户的发表内容插入到新粉丝的“收件箱inBox”里

        4.新粉丝取消关注了此用户,将该用户的有关内容,从该粉丝的“收件箱inBox”里删除

        

       Feed流之微博系统设计_第2张图片

push模式过程:推模式需要把一篇微博推送给所有关注他的人(推给所有的粉丝

        ① 用户发微博后,push模式,会将该微博推送给所有的粉丝,即在每个粉丝的“收件箱inBox”中插入一条帖子记录

        ② 每当用户刷新微博时,只需要从收件箱inBox中,查询所有订阅的微博

分析

优点:消除了拉模式的IO集中点,每个用户都读自己的数据,高并发下锁竞争少

缺点:

        1.(写放大)极大消耗存储资源,数据会存储很多分,比如大V的粉丝有一百万,他每次发表一次,数据会冗余一百万份,同时,插入到一百万的粉丝的队列中也比较费时。 ==> 拥有千万粉丝的网红/大V发帖,会导致上千万次数据库的插入操作,直接导致系统崩溃

        2. 新增关注,取消关,发布,取消发布的业务流程复杂

方式2:pull模式(拉模式是在用户刷微博的时候拉取他关注的所有好友的最新微博)

业务场景

        1.用户发表的内容只插入到自己的“发件箱outBox”里去,粉丝拉取关注流里需要从每个关注人的“发件箱outBox”里各取几个,然后进行rank。

        2.用户撤销发表,只把自己的“发件箱outBox”对应的删掉即可。

        3.新粉丝新关注了此用户,因为是拉模式,不需要额外操作,刷新关注流的时候就会拉取。

        4.粉丝取消关注了此用户,因为是拉模式,不需要额外操作。

 Feed流之微博系统设计_第3张图片

        Feed流之微博系统设计_第4张图片

 pull模式过程:

① 拉模式只需要用户发表微博时,存储一条微博数据到自己的“发件箱outBox”

② 用户需要查询所有关注者的“发件箱outBox”,组成列表返回

分析:

优点:

        1.存储结构简单,数据存储量小,只存一份,无数据冗余。

        2.关注,取关,发布,取消发布的业务流程非常简单。

        3.存储结构,业务流程都比较容易理解,适合项目早期用户量、数据量、并发量不大时的快速实现。

缺点:

        1.拉取业务流程比较复杂:需要查找到关注列表,然后依次查询“发件箱outBox”

        2.(读放大):因为所有用户都是关注网红/大V,那么网红/大V的“发件箱outBox”就会被读放大,直接导致系统的崩溃

拉模式优化方案:时间分区

        1. 发帖表(feed表)可以按照时间区间分表,一天表、一周表、一个月表、总表等,简单来说就是做几份数据冗余

        2. 用户登录时,我们根据用户的上次登录的时间确定他适合查询那个区间表。

                举例:

                        每天都登录的用户定位到一周表

                        半个月登录一次的定位到一个月表

                        依次类推

Feed流之微博系统设计_第5张图片

方式3:push\pull模式结合

        推拉模式结合:实际上是根据用户是否为大V,进行区别对待(推拉结合虽然很全面,但实现复杂,同时业务量很大时才有用)

1.发帖

        Feed流之微博系统设计_第6张图片

        1).发表内容先进入一个队列服务(异步处理)

        2).从粉丝列表中读取到自己的粉丝列表,以及判断自己是否大V

        3).将发表内容写入个人的“发件箱inBox”(现在就是进入到动态发表库里),如果是大V,就结束了

        4)如果不是大V还需要将自己的发表数据插入到自己粉丝的“收件箱outBox”里去

2.拉取

        1).去关注表里拉取关注的人,并判断谁是大V

        2).去读自己的接收队列

        3).如果是大V,还要去遍历大v的发表队列

        4).进行rank

3.取消关注

        1)取消的如果是大v,见拉模式

        2)取消的如果不是大v,见推模式

4.取消发布

        同取消关注

5.增加新关注

        1)如果新关注的是大v,见拉模式

        2)如果关注的不是大v,见推模式。

----------------------------------------------------------------------

        除此之外,还要加上缓存对系统进行优化!这里就不再赘述

你可能感兴趣的:(设计,java,服务器,前端)