常用Feed流架构实现

来源：武汉UI设计培训学校时间：2021/7/1 11:44:11

　　业务中很多需求都会用到类似feed流的架构。

　　例如

　　微信朋友圈

　　微博

　　动态

　　1对N消息。

　　一般feed流的架构实现有下面几种。

　　假如现在的业务场景是微博，然后当前的数据情况是：

　　用户A关注了用户B和C，用户D关注了用户B

　　用户B发了微博A，B，用户C发了微博C，D

　　1. 拉

　　数据表

　　微博表(字段有：微博ID，微博内容，发布人)

　　代码逻辑：

　　用户 B发布微博接口，插入记录到微博表，只有一行记录

　　用户A获取我关注的用户的微博接口：

　　获取当前登录用户关注的用户，例如A关注的用户B和C

　　获取B和C发布的所有微博，

　　按时间倒序排列，分页，返回

　　优缺点：

　　实现简单

　　空间占用较少，一条微博只用一条数据库记录

　　数据量大的情况下， 第2个接口查询较慢(需要用临时表，而且查询数据较多)

　　2.推

　　数据表

　　微博表(字段有：微博ID，微博内容，发布人)

　　feed流表(字段有：微博ID，发布时间，接收人)

　　代码逻辑：

　　发布微博接口

　　插入记录到微博表

　　获取当前用户粉丝用户列表，假如当前用户是B，那就是获取A和D

　　插入2行记录到feed流表

　　接收人=A，微博ID=刚才的微博表ID

　　接收人=B，微博ID=刚才的微博表ID

　　用户A获取我关注的用户的微博接口：

　　查询feed流表，找到接收人=A的记录，按发布时间倒序排，分页，返回

　　优缺点：

　　实现较复杂

　　空间占用较多，一条微博需要插入1+N条记录(N是粉丝用户数)。如果N是几十w或者几百w，对数据库压力非常大，包括空间占用，插入或删除耗时，索引建立等。

　　第2个接口可以用索引，所以查询很快，。

　　3.推+拉

　　上面两种方案都有优缺点，当对读的要求很高，同时用户粉丝数很大，就要想办法优化，推+拉是其中一种方案。

　　具体方法是区分用户：

　　对于经常读取的用户，采用推方案，增加读取的性能

　　对于不常读取的用户，采用拉方案，降低存储压力

　　从产品的角度看，有很多种方法可以区分用户是否属于经常读，这里提供其中一个可行的方案：

　　4. 区分活跃用户的推+拉

　　数据表

　　微博表(字段有：微博ID，微博内容，发布人)

　　feed流表(字段有：微博ID，发布时间，接收人)

　　活跃用户表(字段有：用户ID，是否活跃，较新登录时间)

　　代码逻辑：

　　发布微博接口

　　插入记录到微博表

　　获取当前用户活跃粉丝用户列表，假如当前用户是B，那就是获取A和D，其中A是活跃用户，D是非活跃，那就只获取A。SQL可以用exists，例如：select * from fans where exists (select * from 活跃表 where 是否活跃=1)

　　插入1行记录到feed流表(D不是活跃用户，就不插入了)

　　接收人=A，微博ID=刚才的微博表ID

　　用户A获取我关注的用户的微博接口：

　　查询feed流表，找到接收人=A的记录，按发布时间倒序排，分页，返回

　　APP启动接口(每次APP启动，发送一个请求到后端)

　　如果用户是活跃用户，更新用户较新登录时间

　　如果不是，通过拉方式为用户补发feed流：

　　获取用户所有关注的用户

　　获取这些用户发的微博

　　把这些微博ID插入到用户的feed流表(要避免重复插入)

　　定时任务

　　每天把较新登录时间小于1天前的用户，设置为非活跃

　　优缺点：

　　第2个接口可以用索引，所以查询很快。

　　数据库压力降低。因为一般粉丝中活跃用户只有小部分，同时补发的时候，可以只补发较新的N条微博，进一步节省空间，当然这些要和产品经理制定好规则。

　　逻辑较复杂

　　因为补发feed流需要一定时间，所以这期间用户只能拉到旧的微博

　　5.总结

　　如果想简单做，而且对读取要求不高，用拉方式就可以了

　　如果对读取要求高，同时粉丝数不多，例如朋友圈，较多就几千个朋友，建议用推方式

　　如果粉丝数很多，例如微博，动辄几十万到几千万粉丝的，建议用推+拉方式

尊重原创文章，转载请注明出处与链接：http://www.peixun360.com/478/news/376887/违者必究！ 以上就是武汉UI设计培训学校 小编为您整理 常用Feed流架构实现的全部内容。