麻了，老板要求设计一个微博feed流

一. 背景

微博，微信朋友圈，抖音等都是典型的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;

1. 获取所有内容后根据timeline进行排序。

这样的方案解决了在推模式下存在的三个问题，但是却也引发了另外的性能问题。

假如，用户关注的博主非常多，要拉取所有内容并进行排序聚合，这样的操作必定会耗时很多，请求时延很高。

那么如何做到低耗时，完成快速响应呢？

单纯依靠数据库是无法达到要求的，所以我们要在中间引入缓存层（分片），通过缓存来降低磁盘IO。

1）流程为：

1. 关注列表缓存

将用户关注的所有博主ID存入缓存中。以用户ID为key，value为关注博主id集合

1. 微博内容缓存

以博主ID为key，value为微博内容集合。博主发布微博后，将微博内容存入集合中

1. 获取feed流时

根据关注的博主id集合，在所有缓存分片节点上拉取所有内容并进行排序聚合。

假如缓存分片集群为三主三从，也就是一共需要三次请求即可拉取到所有内容，然后进行时间倒排，响应给用户

2）存在的问题

1. 系统的读压力很大

假如用户关注了1000个博主，那么需要拉取这1000个博主的所有发布内容，进行排序聚合，对于缓存服务，以及带宽压力都很大。

可尝试的解决方案:

缓存节点一主多从，通过水平扩容，来分散读压力和带宽瓶颈

3）小结

对于大V用户，拉模式能够很好解决写扩散存在的问题，同时也会带来上述存在的问题。

三. 总结

分析完推模式和拉模式的优缺点，我们很容易发现

1. 推模式适合于粉丝量不大的场景。例如朋友圈，一对一聊天。

2. 拉模式适合粉丝量巨大的大V用户。例如微博大V。

所以在场景设计时，可以将推模式和拉模式结合使用。逻辑如下

1. 设定一个大V粉丝量阈值，达到阈值后触发打用户标签事件。

2. 对于未达到阈值的用户依然使用写扩散方式，这样冗余的数据量不会太大，也不存在即时性问题。

3. 当达到阈值的用户发微博的时候，将微博内容存入缓存（热数据），不进行写扩散，而是粉丝拉取数据与收件箱中的数据进行排序聚合。

PS：这里还可以通过用户行为去维护一个活跃粉丝列表，对于该列表中的粉丝，同样进行一个写扩散的行为，保证即时触达。

作者：盖茨狗

来源：https://juejin.cn/post/7025208419875291166

版权申明：内容来源网络，仅供分享学习，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!

END

架构师交流群

 「架构君」建立了读者架构师交流群，大家可以添加小编微信进行加群。欢迎有想法、乐于分享的朋友们一起交流学习。

扫描添加好友邀你进架构师群，加我时注明【姓名+公司+职位】

强势开源一款小程序！
2021-11-07
强力推荐一个完善的物流（WMS）管理项目（附代码）
2021-10-23
推荐一个 Spring Boot + MyBatis + Vue 音乐网站
2021-10-19
分享一套家庭理财系统（附源码）
2021-09-20
推荐一个互联网企业级别的开源支付系统
2021-09-04
推荐一套开源通用后台管理系统（附源码）
2021-08-21
一款神仙接私活儿软件，吊到不行！
2021-07-31
基于 SpringBoot 的仿豆瓣平台【源码分享】
2021-07-18
干掉 Wordpress！这个开源建站神器有点吊！
2021-06-18
从朋友那里搞了 20 个实战项目，速领！
2021-06-12

如有收获，点个在看，诚挚感谢