转自 作者 | JiaGouX
一. 背景
微博,微信朋友圈,抖音等都是典型的feed流产品,也就是我们的浏览内容都是由他人发的feed组成。
本篇文章尝试进行微博feed流的设计解析,如有问题欢迎大家指正。
二. 如何设计一个微博feed流
1. 存储设计在数据存储上主要分三个部分
1)feed存储
是用户发布的内容存储,这部分内容需要永久存储,用户在查看个人主页的时候不论多久的都要可以看到
数据结构简化如下,根据userId进行水平分表
create table `t_feed`(
`feedId` bigint not null PRIMARY KEY,
`userId` bigint not null COMMENT '创建人ID'
`content` text,
`recordStatus` tinyint not null default 0 comment '记录状态'
)ENGINE=InnoDB;
2)关注关系存储
是用户之间关系的一个存储,也是控制用户能够看到feed范围的依赖,同样需要永久存储。
数据结构简化如下(待优化)根据userId进行水平分表:
CREATE TABLE `t_like`(
`id` int(11) NOT NULL PRIMARY KEY,
`userId` int(11) NOT NULL,
`likerId` int(11) NOT NULL,
KEY `userId` (`userId`),
KEY `userId` (`likerId`),
)ENGINE=InnoDB;
3)feed同步存储
用于feed流展示,可以理解为是一个收件箱,关注的人发布了feed,就要向其中投递。
可以根据业务场景保存一段时间内的内容,冷的数据可以进行归档也可以直接删除。
数据结构简化如下,根据userId进行水平分表:
create table `t_inbox`(
`id` bigint not null PRIMARY KEY,
`userId` bigint not null comment '收件人ID',
`feedId` bigint not null comment '内容ID',
`createTime` datetime not null
)ENGINE=InnoDB;
2. 场景特点
1) 读多写少
读写比例差距巨大,典型的读多写少场景。
2) 有序展示
需要根据timeline或者feed的打分值来进行排序处理展示。
3. 使用推模式实现推模式也称写扩散模式,当被关注人发布内容后,主动将内容推送给关注,写入关注人的收件箱中。
1)方案
1、当被关注人发布一条内容以后,获取所有关注该人的用户,然后进行遍历数据,将内容插入这些用户的收件箱中,示例如下:
/** 插入一条feed数据 **/
insert into t_feed (`feedId`,`userId`,`content`,`createTime`) values (10001,4,'内容','2021-10-31 17:00:00');
/** 查询所有粉丝 **/
select userId from t_like where liker = 4;
/** 将feed插入粉丝的收件箱中 **/
insert into t_inbox (`userId`,`feedId`,`createTime`) values (1,10001,'2021-10-31 17:00:00');
insert into t_inbox (`userId`,`feedId`,`createTime`) values (2,10001,'2021-10-31 17:00:00');
insert into t_inbox (`userId`,`feedId`,`createTime`) values (3,10001,'2021-10-31 17:00:00');
2、当用户ID为1的用户进行查看feed流时,就将收件箱表中的所有数据进行查出,示例如下:
select feedId from t_inbox where userId = 1 ;
3、对数据进行聚合排序处理
2)存在的问题
1、即时性较差
当大V被很多很多用户关注的时候,遍历进行粉丝进行插入数据非常耗时,用户不能及时收到内容
可尝试的解决方法:
1. 可将任务推入消息队列中,消费端多线程并行消费。
2. 使用插入性能高、数据压缩率高的数据库
2、存储成本很高
每个粉丝都要存储一份关注人的微博数据,大V粉丝量很高的时候,插入数据量成指数级上升。
并且微博可以将关注的博主进行分组,所以数据不仅要在全部收件箱中插入,也要在分组的收件箱中插入。
可尝试的解决方法:
数据冷热分离,热库仅保存短时间内的数据,冷库多保留一段时间的数据,冷热库均定时清理数据。
用户量不断上涨,使用这种设计方案,终究还是会遇到瓶颈
3、数据状态同步
当被关注用户删除微博或取关某博主时,需要将所有粉丝的收件箱中的内容都删除,依然存在一个写扩散的即时性问题
可尝试的解决方案:
在拉取数据的时候对微博的状态进行判断,过滤已删除/已取关的微博过滤
以上解决方案可以在一定程度上提升效率,但是不能根源上解决问题。
3)小结
推模式仅适用于粉丝量不会太多的情况,例如微信朋友圈,这样能够比较好的控制好即时触达性、以及数据存储的成本。
对于微博大V这种粉丝量很大的场景并不适合。
4. 使用拉模式拉模式也称读扩散模式,当我们使用拉数据的方式后,用户获取数据流程如下:
1、获取所有关注的博主ID。
select liker from t_like where userId = 1;
2、根据博主ID进行内容拉取。
select * from t_feed where userId in (4,5,6) and recordStatus = 0;
3、获取所有内容后根据timeline进行排序。
这样的方案解决了在推模式下存在的三个问题,但是却也引发了另外的性能问题。
假如,用户关注的博主非常多,要拉取所有内容并进行排序聚合,这样的操作必定会耗时很多,请求时延很高。
那么如何做到低耗时,完成快速响应呢?
单纯依靠数据库是无法达到要求的,所以我们要在中间引入缓存层(分片),通过缓存来降低磁盘IO。
1)流程为:
1、关注列表缓存
将用户关注的所有博主ID存入缓存中。以用户ID为key,value为关注博主id集合
2、微博内容缓存
以博主ID为key,value为微博内容集合。博主发布微博后,将微博内容存入集合中
3、获取feed流时
根据关注的博主id集合,在所有缓存分片节点上拉取所有内容并进行排序聚合。
假如缓存分片集群为三主三从,也就是一共需要三次请求即可拉取到所有内容,然后进行时间倒排,响应给用户
2)存在的问题
1、系统的读压力很大
假如用户关注了1000个博主,那么需要拉取这1000个博主的所有发布内容,进行排序聚合,对于缓存服务,以及带宽压力都很大。
可尝试的解决方案:
缓存节点一主多从,通过水平扩容,来分散读压力和带宽瓶颈
3)小结
对于大V用户,拉模式能够很好解决写扩散存在的问题,同时也会带来上述存在的问题。
三. 总结
分析完推模式和拉模式的优缺点,我们很容易发现
所以在场景设计时,可以将推模式和拉模式结合使用。逻辑如下
PS:这里还可以通过用户行为去维护一个活跃粉丝列表,对于该列表中的粉丝,同样进行一个写扩散的行为,保证即时触达。
,Copyright © 2008-2022 秒下下载站
m.down10s.com .All Rights Reserved