江苏龙网

  1. 主页 > 生活百科 > >

如何设计一个微博feed流

feed流

官方网站 www.itilzj.com 文档资料: wenku.itilzj.com
一. 背景
微博 ， 微信朋友圈 ， 抖音等都是典型的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. 使用推模式实现
推模式也称写扩散模式 ， 当被关注人发布内容后 ， 主动将内容推送给关注 ， 写入关注人的收件箱中 。
【如何设计一个微博feed流】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粉丝量很高的时候 ， 插入数据量成指数级上升 。
并且微博可以将关注的博主进行分组 ， 所以数据不仅要在全部收件箱中插入 ， 也要在分组的收件箱中插入 。
可尝试的解决方法：
数据冷热分离 ， 热库仅保存短时间内的数据 ， 冷库多保留一段时间的数据 ， 冷热库均定时清理数据 。
 
用户量不断上涨 ， 使用这种设计方案 ， 终究还是会遇到瓶颈


推荐阅读


上一篇：Android中各种Exception错误小结

下一篇：火树银花|早春野钓水库全攻略，个体大聚窝快，水底地形很重要